From rdobbins at arbor.net  Tue Nov  1 00:19:15 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 1 Nov 2011 05:19:15 +0000
Subject: Manage an enterprise network? Please fill out my survey - for
 Science! :-)
In-Reply-To: <CAD6AjGQxQ_BteTs8yYiiuf-1tXpTNAL2yGeWrfO7Q4npUvTM=Q@mail.gmail.com>
References: <CAGoufOAhtXYjeDomsfaBKbf7VWOn4Qo+dSS5EcskHigPQ-YV4A@mail.gmail.com>
 <5948995898631926267@unknownmsgid>
 <CAGoufOBUHQsM5Y0Tmy8YwtdMNi9-8Vw-dRJDE5ZWic9=7CL3Bg@mail.gmail.com>
 <4EAF6EFA.5000702@gmail.com> <4EAF71E3.7030406@brightok.net>
 <CAD6AjGQxQ_BteTs8yYiiuf-1tXpTNAL2yGeWrfO7Q4npUvTM=Q@mail.gmail.com>
Message-ID: <4B2F33DF-5B04-4B73-943A-8A818E5C7507@arbor.net>


On Nov 1, 2011, at 11:44 AM, Cameron Byrne wrote:

> Unfotunately ISPs are deploying many middle boxen, frequently in series, for various reasons...cough cough cgn.

This AusNOG presentation touches upon the topic:

<http://www.ausnog.net/images/ausnog-05/presentations/7-2-stateofdanger.pdf>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From jbates at brightok.net  Tue Nov  1 01:28:53 2011
From: jbates at brightok.net (Jack Bates)
Date: Tue, 01 Nov 2011 01:28:53 -0500
Subject: Manage an enterprise network? Please fill out my survey - for
 Science! :-)
In-Reply-To: <4B2F33DF-5B04-4B73-943A-8A818E5C7507@arbor.net>
References: <CAGoufOAhtXYjeDomsfaBKbf7VWOn4Qo+dSS5EcskHigPQ-YV4A@mail.gmail.com>
 <5948995898631926267@unknownmsgid>
 <CAGoufOBUHQsM5Y0Tmy8YwtdMNi9-8Vw-dRJDE5ZWic9=7CL3Bg@mail.gmail.com>
 <4EAF6EFA.5000702@gmail.com> <4EAF71E3.7030406@brightok.net>
 <CAD6AjGQxQ_BteTs8yYiiuf-1tXpTNAL2yGeWrfO7Q4npUvTM=Q@mail.gmail.com>
 <4B2F33DF-5B04-4B73-943A-8A818E5C7507@arbor.net>
Message-ID: <4EAF91A5.2040505@brightok.net>

On 11/1/2011 12:19 AM, Dobbins, Roland wrote:
> On Nov 1, 2011, at 11:44 AM, Cameron Byrne wrote:
>
>> Unfotunately ISPs are deploying many middle boxen, frequently in series, for various reasons...cough cough cgn.
> This AusNOG presentation touches upon the topic:
>
> <http://www.ausnog.net/images/ausnog-05/presentations/7-2-stateofdanger.pdf>
>
>
heh, Until IPv6 is a mainstream, I don't think wireless companies (and 
soon wireline) have much choice on CGN. I believe there are plenty of 
CGN products that handle as much or more pps than my Juniper MX960 does. 
My last DDOS killed the egress pps on 2 of my NSP transits. Neither 
could send 2Mpps of traffic to me (ie, neither was line rate at 43bytes).

I'm confused as to the 6to4 gateway state. Last I checked, all my 6to4 
is stateless.

My load balancers are also stateless.

IPS can be deployed sidelined with hardware packet mirroring and remote 
updates to router ACLs.

I recognize that ISPs may not keep DDOS in mind and reduce state when 
possible, but there is current tech that can limit state and still 
deploy the same services. CGN is the exception to the rule, and I've yet 
to see a way around it in a depleted IPv4 Internet (but as stated, most 
CGN is designed to handle state to the same performance levels as 
current router tech).


Jack



From rdobbins at arbor.net  Tue Nov  1 01:41:05 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 1 Nov 2011 06:41:05 +0000
Subject: Manage an enterprise network? Please fill out my survey - for
 Science! :-)
In-Reply-To: <4EAF91A5.2040505@brightok.net>
References: <CAGoufOAhtXYjeDomsfaBKbf7VWOn4Qo+dSS5EcskHigPQ-YV4A@mail.gmail.com>
 <5948995898631926267@unknownmsgid>
 <CAGoufOBUHQsM5Y0Tmy8YwtdMNi9-8Vw-dRJDE5ZWic9=7CL3Bg@mail.gmail.com>
 <4EAF6EFA.5000702@gmail.com> <4EAF71E3.7030406@brightok.net>
 <CAD6AjGQxQ_BteTs8yYiiuf-1tXpTNAL2yGeWrfO7Q4npUvTM=Q@mail.gmail.com>
 <4B2F33DF-5B04-4B73-943A-8A818E5C7507@arbor.net>
 <4EAF91A5.2040505@brightok.net>
Message-ID: <18FE168D-5D42-40B9-B3DB-27F58781DD95@arbor.net>


On Nov 1, 2011, at 1:28 PM, Jack Bates wrote:

> I'm confused as to the 6to4 gateway state. Last I checked, all my 6to4 is stateless.

Depends upon the technology being used.  I probably should've used a different term.

> My load balancers are also stateless.

Most are not, or aren't configured to be so (i.e., most seem to be set up to handle the outbound server-to-client comms, too).  I see them go down like tenpins in trivial DDoS attacks all the time.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From me at payam124.com  Tue Nov  1 01:59:58 2011
From: me at payam124.com (Payam Poursaied)
Date: Tue, 1 Nov 2011 10:29:58 +0330
Subject: Network Asset/Service Track/Management
Message-ID: <08f701cc9863$e03d74d0$a0b85e70$@com>

Hi all

I'm looking for a system to keep track of network assets and also periodic services in each pop site. Currently we have
about 500 pop-sites. In each site we have DSLAMs, Linecards and also some passive equipments including terminals, racks
and ..

Also each site may have some recurring fees/services. Something like transit link, power, rental space and .

 

Could you please share your experience with me

 

Best Regards

Payam Poursaied

 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5605 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111101/b2aa1c43/attachment.bin>

From babak at farrokhi.net  Tue Nov  1 02:38:36 2011
From: babak at farrokhi.net (Babak Farrokhi)
Date: Tue, 1 Nov 2011 11:08:36 +0330
Subject: Network Asset/Service Track/Management
In-Reply-To: <08f701cc9863$e03d74d0$a0b85e70$@com>
References: <08f701cc9863$e03d74d0$a0b85e70$@com>
Message-ID: <560B6E25-3AF2-4945-8505-FE2FA38B8BED@farrokhi.net>

Hi,

I would suggest you use the element management software provided by your vendor. But you may want to take a look at www.ziptie.org for an alternative.

Regards,

On Nov 1, 2011, at 10:29 AM, Payam Poursaied wrote:

> Hi all
> 
> I'm looking for a system to keep track of network assets and also periodic services in each pop site. Currently we have
> about 500 pop-sites. In each site we have DSLAMs, Linecards and also some passive equipments including terminals, racks
> and ..
> 
> Also each site may have some recurring fees/services. Something like transit link, power, rental space and .
> 
> 
> 
> Could you please share your experience with me
> 
> 
> 
> Best Regards
> 
> Payam Poursaied
> 
> 
> 

-- 
Babak Farrokhi
Network Expert / Unix SA / Security Analyst



From mikereedwt at gmail.com  Tue Nov  1 04:03:14 2011
From: mikereedwt at gmail.com (Mike Reed)
Date: Tue, 1 Nov 2011 09:03:14 +0000
Subject: consumer DSL problems
Message-ID: <CACwkm_Odxi4-kSx43xppjUd3osaFAXz1tAAg1=-BPuUO9T0gnw@mail.gmail.com>

Hi folks,

It would seem that my home broadband provider (Orange, formerly known
as Wanadoo/Freeserve) have made some networking changes at the
weekend. The first I knew of it was when my DSL router refused to
connect. It's a vendor-supplied Siemens Gigaset SE572. While it's
probably not the best router in the world (most consumer routers are
risible), it was generally fine. On complaint, they tell me it's
'old'. Closer inspection reveals it's picking up the DSL carrier
signal fine, but failing during LCP negotation

Is there a common policy on rendering vendor-supplied CPEs unusable?
As a network operator to residential users, would you notify any
potentially affected users before making such a change? I am grateful
for any insight.

Kind regards,
Mike


From charles at knownelement.com  Tue Nov  1 04:22:13 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Tue, 01 Nov 2011 04:22:13 -0500
Subject: Network Asset/Service Track/Management
In-Reply-To: <560B6E25-3AF2-4945-8505-FE2FA38B8BED@farrokhi.net>
References: <08f701cc9863$e03d74d0$a0b85e70$@com>
 <560B6E25-3AF2-4945-8505-FE2FA38B8BED@farrokhi.net>
Message-ID: <4EAFBA45.3070700@knownelement.com>

On 11/01/2011 02:38 AM, Babak Farrokhi wrote:
> Hi,
>
> I would suggest you use the element management software provided by your vendor. But you may want to take a look at www.ziptie.org for an alternative.

Also nocproject.org



From regnauld at nsrc.org  Tue Nov  1 04:29:37 2011
From: regnauld at nsrc.org (Phil Regnauld)
Date: Tue, 1 Nov 2011 10:29:37 +0100
Subject: Network Asset/Service Track/Management
In-Reply-To: <08f701cc9863$e03d74d0$a0b85e70$@com>
References: <08f701cc9863$e03d74d0$a0b85e70$@com>
Message-ID: <20111101092937.GG10684@macbook.bluepipe.net>

Payam Poursaied (me) writes:
> Hi all
> 
> I'm looking for a system to keep track of network assets and also periodic services in each pop site. Currently we have
> about 500 pop-sites. In each site we have DSLAMs, Linecards and also some passive equipments including terminals, racks
> and ..
> 
> Also each site may have some recurring fees/services. Something like transit link, power, rental space and .
> 
> Could you please share your experience with me

	Hi Payam,

	Some of what you mention can be handled with Netdot (https://netdot.uoregon.edu).

	There is built-in support for maintenance contract definitions, but some
	customization might be required. The good part about netdot is that it
	will automate some of the inventory management if it has SNMP access to
	your devices. Asset mgmt support is rather good for Cisco equipment, but
	would have to be tested for other vendors.

	Cheers,
	Phil


From doctorchd at gmail.com  Tue Nov  1 04:52:49 2011
From: doctorchd at gmail.com (Dmitry Cherkasov)
Date: Tue, 1 Nov 2011 11:52:49 +0200
Subject: using IPv6 address block across multiple locations
In-Reply-To: <op.v38ql81etfhldh@rbeam.xactional.com>
References: <CAP5kh1B9SbeA0T7EYtC2=PakUucyLk2WkxjwYaE470=jHGeMVA@mail.gmail.com>
 <alpine.DEB.2.00.1110310936370.11931@uplift.swm.pp.se>
 <CACB24MuXv2vArqULsPFc18mzCixL_56t5PS94itfkCXMm_qJ6w@mail.gmail.com>
 <op.v38ql81etfhldh@rbeam.xactional.com>
Message-ID: <CAP5kh1COWwmDSNPy9CUDGHxfKq_Y=7XceuXpPa7Nw8D=OwJQ+A@mail.gmail.com>

Thanks to everybody who responded.

To summarize it all, these are the guides for non-ISP company to use
PI IPv6 addresses:

case 1: single POP, no plans to have more
- get single /48 from your RIR, announce it to one or multiple ISPs
that POP is connected to

case 1a: multiple separate POPs (no VPN interconnections)
- the same as for case 1 but for each POP independently; each POP has
individual AS, btw

case 2: extranet like multiple POPs interconnected with VPNs
- get greater then /48 block (like /44) so each POP gets its /48 part
- each POP announces its corresponding /48 prefix to their local ISPs
- decide if you wish that traffic from Internet to some POP passes
through some other of your POPs (security or other considerations); if
this is desirable you may announce the whole aggregate (like /44)
additionally to /48 from all or some of the POPs; optionally you may
wish to announce /44 with community 'no-export'


As for /48 IPv6 blocks being like /24 for IPv4.
It really seems that /48 may be the most popular PI block and this may
lead to overcrowding of DFZ. Probably, this is logical consequence of
getting bigger address space. We needed more IP addresses and we get
them. Anyway getting greater then /48 just because you do not want to
pollute DFZ is not justified.

Thank you.

Dmitry Cherkasov



2011/11/1 Ricky Beam <jfbeam at gmail.com>:
> On Mon, 31 Oct 2011 05:39:57 -0400, Richard Barnes
> <richard.barnes at gmail.com> wrote:
>>
>> Couldn't you also advertise the /48 from all the sites, if you're
>> willing to sort things out over the inter-site VPNs?
>
> If we're talking about a site-to-site IPsec VPN "over the internet", then
> that's a very bad idea. ?Even if "the internet" in this case is entirely
> within the same provider's network. (and it doesn't sound like it is.)
>
> --Ricky
>
>


From streiner at cluebyfour.org  Tue Nov  1 06:10:19 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 1 Nov 2011 07:10:19 -0400 (EDT)
Subject: using IPv6 address block across multiple locations
In-Reply-To: <CAP5kh1COWwmDSNPy9CUDGHxfKq_Y=7XceuXpPa7Nw8D=OwJQ+A@mail.gmail.com>
References: <CAP5kh1B9SbeA0T7EYtC2=PakUucyLk2WkxjwYaE470=jHGeMVA@mail.gmail.com>
 <alpine.DEB.2.00.1110310936370.11931@uplift.swm.pp.se>
 <CACB24MuXv2vArqULsPFc18mzCixL_56t5PS94itfkCXMm_qJ6w@mail.gmail.com>
 <op.v38ql81etfhldh@rbeam.xactional.com>
 <CAP5kh1COWwmDSNPy9CUDGHxfKq_Y=7XceuXpPa7Nw8D=OwJQ+A@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1111010703300.8660@whammy.cluebyfour.org>

On Tue, 1 Nov 2011, Dmitry Cherkasov wrote:

> case 2: extranet like multiple POPs interconnected with VPNs
> - get greater then /48 block (like /44) so each POP gets its /48 part
> - each POP announces its corresponding /48 prefix to their local ISPs
> - decide if you wish that traffic from Internet to some POP passes
> through some other of your POPs (security or other considerations); if
> this is desirable you may announce the whole aggregate (like /44)
> additionally to /48 from all or some of the POPs; optionally you may
> wish to announce /44 with community 'no-export'

You really don't need to tag the larger block with no-export.  In fact,
if the POPs are suitably interconnected on the back end, you really
don't need to advertise the /48s all, and just advertise the /44. 
Depending on your upstreams, you might be able to tag your advertisements 
with certain BGP communities (will vary from provider to provider) to give 
you some degree of conrol over traffic distribution.

Getting back to the original point, unless someone does something odd 
with their BGP views, the /48s will be preferred because they're smaller 
(more specific), and the /44 would only be used if a corresponding /48 
prefix doesn't exist in their BGP view.

jms


From bclark at spectraaccess.com  Tue Nov  1 07:05:42 2011
From: bclark at spectraaccess.com (Bret Clark)
Date: Tue, 01 Nov 2011 08:05:42 -0400
Subject: consumer DSL problems
In-Reply-To: <CACwkm_Odxi4-kSx43xppjUd3osaFAXz1tAAg1=-BPuUO9T0gnw@mail.gmail.com>
References: <CACwkm_Odxi4-kSx43xppjUd3osaFAXz1tAAg1=-BPuUO9T0gnw@mail.gmail.com>
Message-ID: <4EAFE096.6090401@spectraaccess.com>

On 11/01/2011 05:03 AM, Mike Reed wrote:
>
> Is there a common policy on rendering vendor-supplied CPEs unusable?
Yes if they are old.
> As a network operator to residential users, would you notify any
> potentially affected users before making such a change?
Any responsible provider would make sure to notify users before making 
the change and then not make the change until all users had been 
upgraded to a new modem...within reason of course...some customer are 
hard to reach and never respond, so at some point you just have to make 
the switch.

Regards,
Bret


From paulooi at takizo.com  Tue Nov  1 09:25:37 2011
From: paulooi at takizo.com (takizo)
Date: Tue, 1 Nov 2011 22:25:37 +0800
Subject: Network Asset/Service Track/Management
In-Reply-To: <20111101092937.GG10684@macbook.bluepipe.net>
References: <08f701cc9863$e03d74d0$a0b85e70$@com>
 <20111101092937.GG10684@macbook.bluepipe.net>
Message-ID: <0D0E7EDE-E090-409A-AD41-FD22C1C8C0A9@takizo.com>


On Nov 1, 2011, at 5:29 PM, Phil Regnauld wrote:

> Payam Poursaied (me) writes:
>> Hi all
>> 
>> I'm looking for a system to keep track of network assets and also periodic services in each pop site. Currently we have
>> about 500 pop-sites. In each site we have DSLAMs, Linecards and also some passive equipments including terminals, racks
>> and ..
>> 
>> Also each site may have some recurring fees/services. Something like transit link, power, rental space and .
>> 
>> Could you please share your experience with me
> 
> 	Hi Payam,
> 
> 	Some of what you mention can be handled with Netdot (https://netdot.uoregon.edu).
> 
> 	There is built-in support for maintenance contract definitions, but some
> 	customization might be required. The good part about netdot is that it
> 	will automate some of the inventory management if it has SNMP access to
> 	your devices. Asset mgmt support is rather good for Cisco equipment, but
> 	would have to be tested for other vendors.
> 
> 	Cheers,
> 	Phil
> 

+1 on Netdot, it's good stuff ;)

From chip.gwyn at gmail.com  Tue Nov  1 09:35:52 2011
From: chip.gwyn at gmail.com (chip)
Date: Tue, 1 Nov 2011 10:35:52 -0400
Subject: Network Asset/Service Track/Management
In-Reply-To: <08f701cc9863$e03d74d0$a0b85e70$@com>
References: <08f701cc9863$e03d74d0$a0b85e70$@com>
Message-ID: <CABGzhducHd0WjE8ohhCmVC7nk5x5i8e7RGMKbPVWDnUNCQMJrg@mail.gmail.com>

For tracking gear, space, racks, power, assets, etc... Might want to
take a look at NetZoomDC by Altima Technologies.  They're doing some
neat stuff.  For the recurring fees and such, not quite sure it will
meet your needs but there are customizable categories, elements, and
what not you can apply to things and create customer reports and
stuff.  It all runs on top of Microsoft's SQL server, with Excel and
Word for reporting functions.  I assume anything you can do in an
Excel sheet can be hooked into it.

--chip

On Tue, Nov 1, 2011 at 2:59 AM, Payam Poursaied <me at payam124.com> wrote:
> Hi all
>
> I'm looking for a system to keep track of network assets and also periodic services in each pop site. Currently we have
> about 500 pop-sites. In each site we have DSLAMs, Linecards and also some passive equipments including terminals, racks
> and ..
>
> Also each site may have some recurring fees/services. Something like transit link, power, rental space and .
>
>
>
> Could you please share your experience with me
>
>
>
> Best Regards
>
> Payam Poursaied
>
>
>
>



-- 
Just my $.02, your mileage may vary,? batteries not included, etc....


From owen at delong.com  Tue Nov  1 10:13:32 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 1 Nov 2011 08:13:32 -0700
Subject: using IPv6 address block across multiple locations
In-Reply-To: <CAP5kh1COWwmDSNPy9CUDGHxfKq_Y=7XceuXpPa7Nw8D=OwJQ+A@mail.gmail.com>
References: <CAP5kh1B9SbeA0T7EYtC2=PakUucyLk2WkxjwYaE470=jHGeMVA@mail.gmail.com>
 <alpine.DEB.2.00.1110310936370.11931@uplift.swm.pp.se>
 <CACB24MuXv2vArqULsPFc18mzCixL_56t5PS94itfkCXMm_qJ6w@mail.gmail.com>
 <op.v38ql81etfhldh@rbeam.xactional.com>
 <CAP5kh1COWwmDSNPy9CUDGHxfKq_Y=7XceuXpPa7Nw8D=OwJQ+A@mail.gmail.com>
Message-ID: <386FD22B-CD9D-4944-BBAE-2C9BAA1CFF11@delong.com>

> 
> As for /48 IPv6 blocks being like /24 for IPv4.
> It really seems that /48 may be the most popular PI block and this may
> lead to overcrowding of DFZ. Probably, this is logical consequence of
> getting bigger address space. We needed more IP addresses and we get
> them. Anyway getting greater then /48 just because you do not want to
> pollute DFZ is not justified.
> 

I agree with you except this last statement.

If you have a need for more than a /48 and you can announce the aggregate
and not the more specifics, it is perfectly valid to get more than a /48 and
you should do so in a way that allows you to announce only the aggregate
so as to avoid polluting the DFZ.

DFZ pollution is not about prefix size, it is about the number of prefixes.

In all cases, one should attempt to implement the minimum number of prefixes
necessary to effect your desired (or needed) routing policy.

Prefix size, OTOH, should relate to the number of end-sites served where
each end-site gets a /48.

Owen



From owen at delong.com  Tue Nov  1 10:20:40 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 1 Nov 2011 08:20:40 -0700
Subject: using IPv6 address block across multiple locations
In-Reply-To: <Pine.LNX.4.64.1111010703300.8660@whammy.cluebyfour.org>
References: <CAP5kh1B9SbeA0T7EYtC2=PakUucyLk2WkxjwYaE470=jHGeMVA@mail.gmail.com>
 <alpine.DEB.2.00.1110310936370.11931@uplift.swm.pp.se>
 <CACB24MuXv2vArqULsPFc18mzCixL_56t5PS94itfkCXMm_qJ6w@mail.gmail.com>
 <op.v38ql81etfhldh@rbeam.xactional.com>
 <CAP5kh1COWwmDSNPy9CUDGHxfKq_Y=7XceuXpPa7Nw8D=OwJQ+A@mail.gmail.com>
 <Pine.LNX.4.64.1111010703300.8660@whammy.cluebyfour.org>
Message-ID: <E1628AFA-A3ED-411A-8F30-84EB6F62D117@delong.com>


On Nov 1, 2011, at 4:10 AM, Justin M. Streiner wrote:

> On Tue, 1 Nov 2011, Dmitry Cherkasov wrote:
> 
>> case 2: extranet like multiple POPs interconnected with VPNs
>> - get greater then /48 block (like /44) so each POP gets its /48 part
>> - each POP announces its corresponding /48 prefix to their local ISPs
>> - decide if you wish that traffic from Internet to some POP passes
>> through some other of your POPs (security or other considerations); if
>> this is desirable you may announce the whole aggregate (like /44)
>> additionally to /48 from all or some of the POPs; optionally you may
>> wish to announce /44 with community 'no-export'
> 
> You really don't need to tag the larger block with no-export.  In fact,
> if the POPs are suitably interconnected on the back end, you really
> don't need to advertise the /48s all, and just advertise the /44. Depending on your upstreams, you might be able to tag your advertisements with certain BGP communities (will vary from provider to provider) to give you some degree of conrol over traffic distribution.
> 
> Getting back to the original point, unless someone does something odd with their BGP views, the /48s will be preferred because they're smaller (more specific), and the /44 would only be used if a corresponding /48 prefix doesn't exist in their BGP view.
> 
> jms

In fact, if you have one or more providers which, in common, serve
multiple POPs, it may be desirable to tag the more specifics (/48s)
as no-export and leave the /44s exportable.

In this way, you can avoid unnecessary DFZ pollution.

Owen



From lists at mtin.net  Tue Nov  1 10:39:46 2011
From: lists at mtin.net (Justin Wilson)
Date: Tue, 01 Nov 2011 11:39:46 -0400
Subject: OT:Hotmail mail Admin
Message-ID: <CAD58B02.1F23E%lists@mtin.net>

Hi all,
Sorry for the offtopic post.  I have a need to talk to a real person at
Hotmail regarding a user account. The normal channels aren't getting me what
I need.

Thanks,
Justin



From jmaimon at ttec.com  Tue Nov  1 11:59:47 2011
From: jmaimon at ttec.com (Joe Maimon)
Date: Tue, 01 Nov 2011 12:59:47 -0400
Subject: Verizon ISP mailing list / ATM ports
Message-ID: <4EB02583.7050004@ttec.com>

Hey All,

I am looking for verizon ATM/DSL wholesale DSL ports for NY/NJ latas, 
and I found some verizon-isp mailing lists, but nothing seems current.

Off-list replies are welcome.

Thanks,

Joe



From kloch at kl.net  Tue Nov  1 13:22:31 2011
From: kloch at kl.net (Kevin Loch)
Date: Tue, 01 Nov 2011 14:22:31 -0400
Subject: Colocation providers and ACL requests
In-Reply-To: <B671B0C8-45EA-40A6-A7C9-0EB2C217B1C7@0x1.net>
References: <B671B0C8-45EA-40A6-A7C9-0EB2C217B1C7@0x1.net>
Message-ID: <4EB038E7.4070703@kl.net>

Christopher Pilkington wrote:
> Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as:
> 
>   deny udp any a.b.c.d/24 eq 80
> 
> ?to refuse and tell us we must subscribe to their managed DDOS product?

We have always accommodated temporary ACL's for active DDOS attacks.  I
think that is fairly standard across the ISP/hosting industry.

I do feel it is bad practice to regularly implement customer specific
ACL's on routers.  If a customer wants a managed firewall we have a
full range of those services available.

- Kevin


From carlosm3011 at gmail.com  Tue Nov  1 14:20:23 2011
From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo)
Date: Tue, 1 Nov 2011 17:20:23 -0200
Subject: using IPv6 address block across multiple locations
In-Reply-To: <CAP5kh1B9SbeA0T7EYtC2=PakUucyLk2WkxjwYaE470=jHGeMVA@mail.gmail.com>
References: <CAP5kh1B9SbeA0T7EYtC2=PakUucyLk2WkxjwYaE470=jHGeMVA@mail.gmail.com>
Message-ID: <CA+z-_EUAhUzZao32htY+6+AswgbjOVZbF2Tdck3eekOnHDhxWw@mail.gmail.com>

My take on the issue is that your providers are wise in not wanting to
accept prefixes longer than /48s.

You should get multiple prefixes, from the same or different RIRs. If
there are policies in place which do not allow you to do so, I think
it's a good time to discuss them.

regards

Carlos

On Mon, Oct 31, 2011 at 5:56 AM, Dmitry Cherkasov <doctorchd at gmail.com> wrote:
> Hello,
>
> Please advice what is the best practice to use IPv6 address block
> across distributed locations.
>
> Recently we obtained our PI /48 from RIPE. The idea was to assign
> partial slices from this block to different locations (we have
> currently 3 offices in Europe and 2 in USA). All locations are
> interconnected with static VPNs. Each location is supposed to
> establish BGP session with local ISP. Partial prefix /56 + aggregate
> /48 (with long AS PATH) are to be announced by each office.
>
> The problem we ran across is that ISP in US does not wish to accept
> prefixes longer then /48 from us.
> Need your advice: is this normal to distribute /48 by /56 parts across
> locations or should we obtain separate /48 for each of them? Or maybe
> we need /32 that can be split into multiple /48? Anyway we are not ISP
> so /48 looks quite reasonable and sufficient for all our needs.
>
> Thank you.
>
> Dmitry Cherkasov
>
>



-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================


From carlosm3011 at gmail.com  Tue Nov  1 14:23:20 2011
From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo)
Date: Tue, 1 Nov 2011 17:23:20 -0200
Subject: Mexico?
In-Reply-To: <00c401cc9521$2ad65250$8082f6f0$@gmail.com>
References: <00c401cc9521$2ad65250$8082f6f0$@gmail.com>
Message-ID: <CA+z-_EUTP7m07=cY_Pherhvn_fkg-bJ+hYn7qZ98Y1wo1_FhJg@mail.gmail.com>

Mexico-based networks get their IP blocks (v4 and v6) from NIC Mexico
(http://www.nic.mx). NIC Mexico and NIC Brasil are the two NIRs within
LACNIC's service area.

regards

Carlos


On Fri, Oct 28, 2011 at 1:24 AM, Ryan Finnesey <rfinnesey at gmail.com> wrote:
> If I want to get a block of IP's issued for a network within Mexico who do I
> talk with? ?I have been told arin does not cover Mexico. ?It was my
> understand arin covers North America.
>
>
>
> Cheers
>
> Ryan
>
>
>
>



-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================


From cjp at 0x1.net  Tue Nov  1 14:51:04 2011
From: cjp at 0x1.net (Christopher J. Pilkington)
Date: Tue, 1 Nov 2011 15:51:04 -0400
Subject: Random five character string added to URLs?
Message-ID: <CAOMUSPZYVAnGN+a2VBQ11UyT3bpK2rRPhZZjwZz_HCA3saoGwg@mail.gmail.com>

This might be off-topic, my apologies if so.

I seeing requests against a server with initial GET requests in the form:

     GET /[a-zA-Z]{5}/pagename.html

pagename.html being optional. The 5 character string seems to be
random. This GET always results in a 404, as our servers don't have
these paths.  The second request seems to always the same without the
modified path, which results in a 20.

I initially suspected this was something from an attack or DOS tool,
but the traffic doesn't fit such a pattern.

Is anyone familiar with what device/service behaves in this fashion?
Clearly something layer 7 is between the clients and the server.
Provider is without clue regarding this. Google results in many
GoDaddy users complaining of same; the server in question is not
hosted with them, but I suspect they may be doing something similar.

Thanks,
-cjp


From carlosm3011 at gmail.com  Tue Nov  1 14:54:05 2011
From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo)
Date: Tue, 1 Nov 2011 17:54:05 -0200
Subject: Outgoing SMTP Servers
In-Reply-To: <5F2E5817-06E1-4822-9405-431098D7902A@drtel.com>
References: <4EAED155.8040604@mtcc.com>
 <201110312119.p9VLJEck099196@mail.r-bonomi.com>
 <5F2E5817-06E1-4822-9405-431098D7902A@drtel.com>
Message-ID: <CA+z-_EWddM0rmSngr7odQs-UgZSu-hBLs__VD=sG6z+qDO3aDQ@mail.gmail.com>

The point to make here is:

- if an ISP takes the path of blocking tcp/25, then they MUST
communicate this appropiately to customers and other users
- they also MUST provide alternatives: SMTP over SSL should be allowed
(tcp/465), authenticated relay, but *something*.

IMO blocking 25/tcp is a side-effect of the failure of the whole ISP
system to decisively deal with spammers. It's easier to blind-block
25/tcp than to do proper investigations and to collaborate with law
enforcement. I have tried to hand reports with *static* IP addresses,
contract identifiers and even home, mobile and work phone numbers of
known spammers in Uruguay (I happen to have my personal feud with one
that sells dog food), only to be shelved by management on the fears of
legal action.

I have also trouble swallowing the argument of "blocking 25/tcp is
great because it avoids us getting into black lists and reduces spam".
Yes, sure, but that doesn't prove it's the right approach in the long
run, as you are dealing with symptoms and not causes/sources.

It's the same thing as having tons of aspirines each time you have a
headache. Even if the pain subsides, you might still have other
underlying conditions that in fact are being masqueraded by your
"solution".

So, as it is often the case in society, we all pay the price.



On Mon, Oct 31, 2011 at 11:17 PM, Brian Johnson <bjohnson at drtel.com> wrote:
>
>
> Sent from my iPad
>
> On Oct 31, 2011, at 4:17 PM, "Robert Bonomi" <bonomi at mail.r-bonomi.com>
>
> <snip>
>
>> There is an at-least-somewhat-valid argument against outbound filtering.
>> to wit, various receiving systems may have different policies on what is/
>> is-not 'acceptable' traffic. ?They have a better idea of what is acceptable
>> to the recipients (their users), than the originating MTA operator does. An
>> originating system cannot accomodate that diversity of opinions _without_
>> getting input from all prospective recipients.
>>
>> And it is, of course, 'not practical' for every email recipient to notify
>> every email 'source' network as to what that recpient considers 'acceptable'.
>> <wry grin>
>
> This is not plausible. It also has nothing to do with a network owner protecting his network from his own users.
>
>>
>> There are only a relative handful of things a _residential_ provider can
>> use to "reliably" filter outgoing mail. A non-comprehensive list:
>> ?1) 'Greylisting' at the origin is as effective at stopping spam as it is
>> ? ? at the destination.
>> ?2) Checks for certain kinds of standards violations that legitimate mail
>> ? ? software does not make.
>> ?3) Check for certain kinds of 'lies' in headers -- things that *cannot*
>> ? ? occur in legitimate email.
>> ?4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels.
>> ?5) Tracking SMTP 'MAIL FROM:" and the "From:" (or 'Resent-From:', if
>> ? ? present), and quarrantining on abnormal numbers of different putative
>> ? ? origins.
>>
>> There's no point in checking source addresses against any DNSBL, for reasons
>> that should be 'obvious'. ?<*GRIN*>
>>
>> Further, any sort of "content" filters prevent customers from _discussing_
>> scams in e-mail.
>>
>> There is a 'hard' problem in letting the source 'opt out' of such filtering,
>> because an intentional 'bad guy' will request his outgoing mail not be
>> monitored, as well as the person who has a 'legitimate' reason for sending
>> messages that might trip mindless content filters.
>>
>> Statistical note: ?Out of the last roughly 6,000 pieces of spam seen here,
>> circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600
>> were in character-sets not supported here. ? Incidentally, spam volume, as
>> seen here, is running a bit _under_ 2/3 of all email, down from a peak of
>> over 95%.
>>
>
> This misses the point of the thread which is not filtering. It is port 25 blocking. Statistically all of he problems exist on TCP port 25. This is why the filtering is largely effective.
>
> - Brian
>



-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================


From jbates at brightok.net  Tue Nov  1 15:19:39 2011
From: jbates at brightok.net (Jack Bates)
Date: Tue, 01 Nov 2011 15:19:39 -0500
Subject: Colocation providers and ACL requests
In-Reply-To: <4EB038E7.4070703@kl.net>
References: <B671B0C8-45EA-40A6-A7C9-0EB2C217B1C7@0x1.net>
 <4EB038E7.4070703@kl.net>
Message-ID: <4EB0545B.6080900@brightok.net>


On 11/1/2011 1:22 PM, Kevin Loch wrote:
> Christopher Pilkington wrote:
>> Is it common in the industry for a colocation provider, when requested
>> to put an egress ACL facing us such as:
>>
>> deny udp any a.b.c.d/24 eq 80
>>
>> ?to refuse and tell us we must subscribe to their managed DDOS product?
>
> We have always accommodated temporary ACL's for active DDOS attacks. I
> think that is fairly standard across the ISP/hosting industry.
>
> I do feel it is bad practice to regularly implement customer specific
> ACL's on routers. If a customer wants a managed firewall we have a
> full range of those services available.
>

And Managed DDOS products better be a LOT more than an ACL. If I'm going 
to pay someone to manage DDOS, they will scrub the traffic and let all 
my legitimate traffic through. That's what I'm paying for. null routing 
an IP or a simple acl isn't worth paying a dime for.


Jack


From sfouant at shortestpathfirst.net  Tue Nov  1 18:05:22 2011
From: sfouant at shortestpathfirst.net (=?utf-8?B?U3RlZmFuIEZvdWFudA==?=)
Date: Tue, 01 Nov 2011 19:05:22 -0400
Subject: =?utf-8?B?UmU6IFJhbmRvbSBmaXZlIGNoYXJhY3RlciBzdHJpbmcgYWRkZWQgdG8gVVJMcz8=?=
Message-ID: <mailman.58.1320188717.1870.nanog@nanog.org>

Is there anything perhaps protecting or intercepting the data on its way to the server, perhaps an Arbor device of some type of load balancer?

This type of behavior is quite common when protecting web assets to eliminate zombies and such, but its usually something you would see back to the clients, not tp the server.

Also, IIRC, the LOIC DoS tool had this ability to create random strings in the URL, and I believe it did so with 5 characters.  Might want to do a packet trace and identify if this is coming from LOIC.

Regards,

Stefan Fouant
Technical Trainer, Juniper Networks
GPG Key ID: 0xB4C956EC

Sent from my HTC EVO.

----- Reply message -----
From: "Christopher J. Pilkington" <cjp at 0x1.net>
Date: Tue, Nov 1, 2011 3:51 pm
Subject: Random five character string added to URLs?
To: <nanog at nanog.org>

This might be off-topic, my apologies if so.

I seeing requests against a server with initial GET requests in the form:

     GET /[a-zA-Z]{5}/pagename.html

pagename.html being optional. The 5 character string seems to be
random. This GET always results in a 404, as our servers don't have
these paths.  The second request seems to always the same without the
modified path, which results in a 20.

I initially suspected this was something from an attack or DOS tool,
but the traffic doesn't fit such a pattern.

Is anyone familiar with what device/service behaves in this fashion?
Clearly something layer 7 is between the clients and the server.
Provider is without clue regarding this. Google results in many
GoDaddy users complaining of same; the server in question is not
hosted with them, but I suspect they may be doing something similar.

Thanks,
-cjp


From mysidia at gmail.com  Tue Nov  1 19:00:54 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 1 Nov 2011 19:00:54 -0500
Subject: Colocation providers and ACL requests
In-Reply-To: <4EB038E7.4070703@kl.net>
References: <B671B0C8-45EA-40A6-A7C9-0EB2C217B1C7@0x1.net>
 <4EB038E7.4070703@kl.net>
Message-ID: <CAAAwwbVAd3EJgkPHSTGM=7Y6m0VNYH6+7+dTm9ZzFBc1D0YZfQ@mail.gmail.com>

On Tue, Nov 1, 2011 at 1:22 PM, Kevin Loch <kloch at kl.net> wrote:
> Christopher Pilkington wrote:
> We have always accommodated temporary ACL's for active DDOS attacks. ?I
> think that is fairly standard across the ISP/hosting industry.

And it's reasonable to accomodate the customer that asks, and
reasonable for a customer to ask for
a temporary ACL in such situations.

However, it's also reasonable for the provider to refuse,  and there's
nothing wrong with that, unless the provider agreed that they would be
willing to do that, and then refused to do something they had already
agreed to do.

The provider might be especially dissuaded from responding and
providing a temporary
ACL for free if the DoS is a "small" one based on the provider's
definition of small,
or if the provider doesn't have  or won't allocate the resources to
respond, without
charging a fee to do so.

Or its a cut rate hosting service, and the customer refused to buy the
"managed filtering"
firewall  (or whatever solution).     In that case, it's reasonable
for the provider to counter the
request with  "You can buy our such and service, and we will gladly
implement that"


If this is something you want to be sure you can do,  then you should
ask the provider
about it before signing that colocation contract for IP connectivity,
and make sure you have it in writing
that the provider will create an ACL on your interface of sufficient
length to do what you want..

And be sure you have worked out  with the provider how this effects
billing in advance.
It's quite possible you still have to pay or have said dropped traffic
counted against your commit.

--
-JH


From aservin at lacnic.net  Tue Nov  1 19:41:12 2011
From: aservin at lacnic.net (Arturo Servin)
Date: Tue, 1 Nov 2011 22:41:12 -0200
Subject: using IPv6 address block across multiple locations
In-Reply-To: <Pine.LNX.4.64.1110311042580.6442@whammy.cluebyfour.org>
References: <CAP5kh1B9SbeA0T7EYtC2=PakUucyLk2WkxjwYaE470=jHGeMVA@mail.gmail.com>
 <E411C101-7FBB-49AB-AAED-A80892D29E4D@delong.com>
 <Pine.LNX.4.64.1110311042580.6442@whammy.cluebyfour.org>
Message-ID: <0A92D0F6-C7D8-4B24-B208-19DC8BC9E815@lacnic.net>


	Same from LACNIC. This would have justify a /44 or separate /48s for each site.


/as

On 31 Oct 2011, at 12:45, Justin M. Streiner wrote:

> On Mon, 31 Oct 2011, Owen DeLong wrote:
> 
>> Ideally, you should put a /48 at each location.
> 
> Speaking from my experience with getting v6 space from ARIN earlier this year, as long as your documentation is in pretty good order, a /48 per site is pretty easy to get.
> 
> I don't know if the experience is different with other RIRs.
> 
> jms



From edward.avanti at gmail.com  Tue Nov  1 20:01:37 2011
From: edward.avanti at gmail.com (Edward avanti)
Date: Wed, 2 Nov 2011 11:01:37 +1000
Subject: BGP conf
Message-ID: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>

Halo,
First, I accept this might not really right list for request, have use nsp
cisco list but only first post to was succeed, sent several other for past
4 day and none appear (verified by list archive) so please excuse request.

I am in need of a cisco config for BGP setup, we have a require to include
IX peering at new location as well as our Verizon link, we like to take
full bgp from Verizon and send to IX what they send us, I spend days
reading google, and so many conflict web site example, so many example seem
insecure no prefix list so on. end result to date is only sore eyes, would
someone who do same (not need be Verizon) be kind to send us off list
working running config (yes without your password heh) or at least how to
apply to BGP router including access/prefix list  and interfaces so we have
an idea on what do, if you take two full BGP feed from two transit
carrierin load share and IX, that good, because that our stage three plan,
but I can work without two transit.

I am not ignorant with cisco 7201, but am total newby to BGP.

Best Thanks
Edwardo

From MGauvin at dryden.ca  Tue Nov  1 20:11:55 2011
From: MGauvin at dryden.ca (Mark Gauvin)
Date: Tue, 1 Nov 2011 20:11:55 -0500
Subject: BGP conf
In-Reply-To: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
References: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
Message-ID: <630EAF96-3375-41ED-A681-F982CCF3A781@dryden.ca>

Why would you want to advertise full verizon routes out to the ix? You  
shoud only be advertising your own network via ix

Sent from my iPhone

On 2011-11-01, at 7:59 PM, "Edward avanti" <edward.avanti at gmail.com>  
wrote:

> Halo,
> First, I accept this might not really right list for request, have  
> use nsp
> cisco list but only first post to was succeed, sent several other  
> for past
> 4 day and none appear (verified by list archive) so please excuse  
> request.
>
> I am in need of a cisco config for BGP setup, we have a require to  
> include
> IX peering at new location as well as our Verizon link, we like to  
> take
> full bgp from Verizon and send to IX what they send us, I spend days
> reading google, and so many conflict web site example, so many  
> example seem
> insecure no prefix list so on. end result to date is only sore eyes,  
> would
> someone who do same (not need be Verizon) be kind to send us off list
> working running config (yes without your password heh) or at least  
> how to
> apply to BGP router including access/prefix list  and interfaces so  
> we have
> an idea on what do, if you take two full BGP feed from two transit
> carrierin load share and IX, that good, because that our stage three  
> plan,
> but I can work without two transit.
>
> I am not ignorant with cisco 7201, but am total newby to BGP.
>
> Best Thanks
> Edwardo


From jsw at inconcepts.biz  Tue Nov  1 20:17:47 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Tue, 1 Nov 2011 21:17:47 -0400
Subject: BGP conf
In-Reply-To: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
References: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
Message-ID: <CAPWAtb+t1QQAKJF5DM4THDF8Ue=vET430LqHGZW_Ub1wKP9kcg@mail.gmail.com>

On Tue, Nov 1, 2011 at 9:01 PM, Edward avanti <edward.avanti at gmail.com> wrote:
> many example seem
> insecure no prefix list so on.
...
> I am not ignorant with cisco 7201, but am total newby to BGP.

Your concern about a lack of any prefix-lists in the documentation /
examples you have read is justified.  If you are connecting to an IX
it may offer route-servers which have prefix-lists maintained by the
IX staff and tools.  However, as you may already know, you will only
receive the "best path" to each prefix from an IX route-server.  This
is often a motive (among others) to establish direct eBGP sessions
with other IX members.  Once you start doing that, you had better
filter routes from those neighbors, or you will subject your network
to your peers' mistakes and glitches.

If you imagine that the IX has other members like yourself, who also
do not know much about BGP, then you can understand why you do not
want your peers' mistakes to cause outages on your network.

Doing a "cut, replace, and paste" from online examples is obviously a
bad idea.  If I were you, I would find a local consultant (perhaps
someone on the staff of the IX or another member) who can assist you
with your initial configuration, and help you in the event of a severe
emergency.  Otherwise, frankly, you are going to be better off by just
buying transit from Verizon and being single-homed.  The added
complexity of BGP is not an asset to an organization that doesn't have
adequate expertise.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From edward.avanti at gmail.com  Tue Nov  1 20:18:15 2011
From: edward.avanti at gmail.com (Edward avanti)
Date: Wed, 2 Nov 2011 11:18:15 +1000
Subject: BGP conf
In-Reply-To: <630EAF96-3375-41ED-A681-F982CCF3A781@dryden.ca>
References: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
 <630EAF96-3375-41ED-A681-F982CCF3A781@dryden.ca>
Message-ID: <CAJxJZcm+Q=zOh2_QDYkPOLEqnb=HYU8p3SkLot_LVzJvH+kPDg@mail.gmail.com>

Halo,
I am not, I wish all transit by Verizon, but if traffic come in from IX, it
only fair I send trafic to them if they in that IX, they be closest path
anyway.


On Wed, Nov 2, 2011 at 11:11 AM, Mark Gauvin <MGauvin at dryden.ca> wrote:

> Why would you want to advertise full verizon routes out to the ix? You
> shoud only be advertising your own network via ix
>
> Sent from my iPhone
>
> On 2011-11-01, at 7:59 PM, "Edward avanti" <edward.avanti at gmail.com>
> wrote:
>
> > Halo,
> > First, I accept this might not really right list for request, have
> > use nsp
> > cisco list but only first post to was succeed, sent several other
> > for past
> > 4 day and none appear (verified by list archive) so please excuse
> > request.
> >
> > I am in need of a cisco config for BGP setup, we have a require to
> > include
> > IX peering at new location as well as our Verizon link, we like to
> > take
> > full bgp from Verizon and send to IX what they send us, I spend days
> > reading google, and so many conflict web site example, so many
> > example seem
> > insecure no prefix list so on. end result to date is only sore eyes,
> > would
> > someone who do same (not need be Verizon) be kind to send us off list
> > working running config (yes without your password heh) or at least
> > how to
> > apply to BGP router including access/prefix list  and interfaces so
> > we have
> > an idea on what do, if you take two full BGP feed from two transit
> > carrierin load share and IX, that good, because that our stage three
> > plan,
> > but I can work without two transit.
> >
> > I am not ignorant with cisco 7201, but am total newby to BGP.
> >
> > Best Thanks
> > Edwardo
>

From Gabriel.McCall at thyssenkrupp.com  Tue Nov  1 21:28:35 2011
From: Gabriel.McCall at thyssenkrupp.com (McCall, Gabriel)
Date: Tue, 1 Nov 2011 22:28:35 -0400
Subject: BGP conf
In-Reply-To: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
References: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
Message-ID: <afe93d54-e984-47cd-a739-f0bf86918679@blur>

Google for "team cymru secure bgp template" for a good starting point.


-----Original message-----
From: Edward avanti <edward.avanti at gmail.com>
To: "nanog at nanog.org" <nanog at nanog.org>
Sent: Wed, Nov 2, 2011 01:01:37 GMT+00:00
Subject: BGP conf

Halo,
First, I accept this might not really right list for request, have use nsp
cisco list but only first post to was succeed, sent several other for past
4 day and none appear (verified by list archive) so please excuse request.

I am in need of a cisco config for BGP setup, we have a require to include
IX peering at new location as well as our Verizon link, we like to take
full bgp from Verizon and send to IX what they send us, I spend days
reading google, and so many conflict web site example, so many example seem
insecure no prefix list so on. end result to date is only sore eyes, would
someone who do same (not need be Verizon) be kind to send us off list
working running config (yes without your password heh) or at least how to
apply to BGP router including access/prefix list and interfaces so we have
an idea on what do, if you take two full BGP feed from two transit
carrierin load share and IX, that good, because that our stage three plan,
but I can work without two transit.

I am not ignorant with cisco 7201, but am total newby to BGP.

Best Thanks
Edwardo


From jeff-kell at utc.edu  Tue Nov  1 21:42:38 2011
From: jeff-kell at utc.edu (Jeff Kell)
Date: Tue, 1 Nov 2011 22:42:38 -0400
Subject: Random five character string added to URLs?
In-Reply-To: <E1RLNOQ-0004kM-14@mailman.nanog.org>
References: <E1RLNOQ-0004kM-14@mailman.nanog.org>
Message-ID: <4EB0AE1E.3090904@utc.edu>

On 11/1/2011 7:05 PM, Stefan Fouant wrote:
> Is there anything perhaps protecting or intercepting the data on its way to the server, perhaps an Arbor device of some type of load balancer?
>
> This type of behavior is quite common when protecting web assets to eliminate zombies and such, but its usually something you would see back to the clients, not tp the server.

I have seen this in SEO-poisoning type of webpage defacement.  They
anchor a javascript in the main website "frame" and it generates
optimization "links" using a numeric suffix or ?argument so that they
appear as separate links.  If the crawler is recognized  (e.g.,
googlebot) then the SEO page is returned.

Jeff


From asr at latency.net  Wed Nov  2 10:53:37 2011
From: asr at latency.net (Adam Rothschild)
Date: Wed, 2 Nov 2011 11:53:37 -0400
Subject: Colocation providers and ACL requests
In-Reply-To: <CAAAwwbVAd3EJgkPHSTGM=7Y6m0VNYH6+7+dTm9ZzFBc1D0YZfQ@mail.gmail.com>
References: <B671B0C8-45EA-40A6-A7C9-0EB2C217B1C7@0x1.net>
 <4EB038E7.4070703@kl.net>
 <CAAAwwbVAd3EJgkPHSTGM=7Y6m0VNYH6+7+dTm9ZzFBc1D0YZfQ@mail.gmail.com>
Message-ID: <CAPZUUwUw=+5Q9mv8jaz6p-6LrSTDSX10aeLcj4T=jcWszhARMg@mail.gmail.com>

On Tue, Nov 1, 2011 at 8:00 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> On Tue, Nov 1, 2011 at 1:22 PM, Kevin Loch <kloch at kl.net> wrote:
>> We have always accommodated temporary ACL's for active DDOS attacks. ?I
>> think that is fairly standard across the ISP/hosting industry.

Indeed.  We'll do it; ditto every reputable hosting, collocation, or
IP transit shop I've come into contact with.

> And it's reasonable to accomodate the customer that asks, and
> reasonable for a customer to ask for
> a temporary ACL in such situations.
>
> However, it's also reasonable for the provider to refuse, ?and there's
> nothing wrong with that, unless the provider agreed that they would be
> willing to do that [...]

Disagree.  Furthermore, I think providers refusing to implement
temporary ACLs should be called out on fora such as NANOG, to aid
others in the vendor selection process.

This is not to say it's sustainable as a repeat or permanent
configuration -- possible up-sell and business drivers aside, TCAM
exhaustion, performance implications, and man-hours required for ACL
maintenance are all very real concerns -- but denying your customers
this type of emergency response is bad for the Internet, and goes
against basic tenets of customer service.

-a


From dholmes at mwdh2o.com  Wed Nov  2 10:54:16 2011
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Wed, 2 Nov 2011 08:54:16 -0700
Subject: BGP conf
In-Reply-To: <afe93d54-e984-47cd-a739-f0bf86918679@blur>
References: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
 <afe93d54-e984-47cd-a739-f0bf86918679@blur>
Message-ID: <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o>

This is a perfect example of why it is crucial that inbound route filters be scrupulously maintained in upstream BGP providers. Who knows who is out there.

-----Original Message-----
From: McCall, Gabriel [mailto:Gabriel.McCall at thyssenkrupp.com]
Sent: Tuesday, November 01, 2011 7:29 PM
To: Edward avanti; nanog at nanog.org
Subject: Re: BGP conf

Google for "team cymru secure bgp template" for a good starting point.


-----Original message-----
From: Edward avanti <edward.avanti at gmail.com>
To: "nanog at nanog.org" <nanog at nanog.org>
Sent: Wed, Nov 2, 2011 01:01:37 GMT+00:00
Subject: BGP conf

Halo,
First, I accept this might not really right list for request, have use nsp
cisco list but only first post to was succeed, sent several other for past
4 day and none appear (verified by list archive) so please excuse request.

I am in need of a cisco config for BGP setup, we have a require to include
IX peering at new location as well as our Verizon link, we like to take
full bgp from Verizon and send to IX what they send us, I spend days
reading google, and so many conflict web site example, so many example seem
insecure no prefix list so on. end result to date is only sore eyes, would
someone who do same (not need be Verizon) be kind to send us off list
working running config (yes without your password heh) or at least how to
apply to BGP router including access/prefix list and interfaces so we have
an idea on what do, if you take two full BGP feed from two transit
carrierin load share and IX, that good, because that our stage three plan,
but I can work without two transit.

I am not ignorant with cisco 7201, but am total newby to BGP.

Best Thanks
Edwardo


This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.

From bhuffake at caida.org  Wed Nov  2 12:31:51 2011
From: bhuffake at caida.org (Bradley Huffaker)
Date: Wed, 2 Nov 2011 10:31:51 -0700
Subject: Mexico?
In-Reply-To: <00c401cc9521$2ad65250$8082f6f0$@gmail.com>
References: <00c401cc9521$2ad65250$8082f6f0$@gmail.com>
Message-ID: <20111102173151.GB23566@caida.org>

LACNIC http://lacnic.net/en/index.html

On Thu, Oct 27, 2011 at 11:24:54PM -0400, Ryan Finnesey wrote:
> If I want to get a block of IP's issued for a network within Mexico who do I
> talk with?  I have been told arin does not cover Mexico.  It was my
> understand arin covers North America.
> 
>  
> 
> Cheers
> 
> Ryan
> 
>  

-- 
    true liberty is the right to be wrong


From itsmemattchung at gmail.com  Wed Nov  2 16:57:37 2011
From: itsmemattchung at gmail.com (Matt Chung)
Date: Wed, 2 Nov 2011 14:57:37 -0700
Subject: Performance Issues - PTR Records
Message-ID: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>

I work for a regional ISP and very recently there has been an influx of
calls reporting "slowness" when accessing certain websites (i.e
google.com/voice/b) via HTTP.  After performing a tcpdump and analyzing the
session, I have been able to pinpoint the latency at the application
layer.  After the tcp session has been established, it takes up to 15-20
seconds before the application begins sending data.   The root of the
problem was that the PTR record for our customer(s) address does not
exist.  As soon as the record is created, latency from the application is
eliminated.  This is analogous to latency when accessing a server over SSH
when no PTR is available.

A seperate packet capture from another customer exhibiting similar
performance behavior showed many TCP retransmissions.  At first glance, I
assumed this was network related however this correlates with the
application not responding and inducing retransmissions at the TCP layer
(different symptoms, same problem).

Historically, there was no compelling reason to create PTR records for our
CPE however more and more applications seem to be dependent on it.
Although we will be assigning a record for each address, my question is why
is the application (specifically HTTP) dependent on a reverse record ?
What is the purpose?

Hope this is helpful as well

-- 
-Matt Chung

From jeffw at he.net  Wed Nov  2 17:02:57 2011
From: jeffw at he.net (Jeff Walter)
Date: Wed, 02 Nov 2011 15:02:57 -0700
Subject: Performance Issues - PTR Records
In-Reply-To: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
References: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
Message-ID: <4EB1BE11.7050600@he.net>

On 11/2/2011 2:57 PM, Matt Chung wrote:
> <snip!>
> Although we will be assigning a record for each address, my question is why
> is the application (specifically HTTP) dependent on a reverse record ?
> What is the purpose?

HTTP has no requirement that the connecting client have reverse DNS 
setup.  Some servers have reverse lookups enabled, and some of those 
undoubtedly block until the record has been retrieved or all avenues of 
discovery have been exhausted... and this is likely where the issue 
exists.  As to why the server or the script/application its running 
needs the record, you'd have to ask the developer.

--
Jeff Walter
Network Engineer
Hurricane Electric, AS6939
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jeffw.vcf
Type: text/x-vcard
Size: 314 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111102/537d2443/attachment.vcf>

From tayeb.meftah at gmail.com  Tue Nov  1 15:36:29 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Tue, 1 Nov 2011 22:36:29 +0200
Subject: IPV6 6to4 and 6In4 Lab
Message-ID: <189B79EF119C4BEA96374EAAD13D8594@work>

Hello folks,
i'm posting this Message to both nanog and afnog lists
preferably if i can get one from afnog to work with me a bit for routing IPV6 prefixs over him using at least static or OSPFv3 or BGP (at you like)
i want to anounce my /48 optained from a friend as number) and 2002::/16 (6to4 prefixs=) at least for 10min to see real IPV6 traffic.
if someone want to help me, please contact me
thank you
    Meftah Tayeb
IT Consulting
http://www.tmvoip.com/ 
phone: +21321656139
Mobile: +213660347746


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6596 (20111102) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


From dhubbard at dino.hostasaurus.com  Wed Nov  2 17:12:21 2011
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Wed, 2 Nov 2011 18:12:21 -0400
Subject: Performance Issues - PTR Records
Message-ID: <FCD26398C5EDE746BFC47F43EA52A17304E0EE9A@dino.ad.hostasaurus.com>

From: Matt Chung [mailto:itsmemattchung at gmail.com] 
> 
 
> Historically, there was no compelling reason to create PTR 
> records for our CPE however more and more applications seem
> to be dependent on it.  Although we will be assigning a
> record for each address, my question is why
> is the application (specifically HTTP) dependent on a reverse record ?
> What is the purpose?
> 

As a web host, we frequently find customers who have
added Apache rules to their ecommerce sites to block
undesirable traffic, such as credit card scammers, etc.
Not knowing any better, they often do this by just
blocking anything that ends in .in to block Indonesia
for example.  Well, once you choose to block by 
resolved name, now that site has to do a dns lookup
for every incoming request to see if it resolves to a
name that should be blocked.

Just one example, but I'm sure there are countless
others that also impede performance for IP addresses
without a PTR record.

David


From arturo.servin at gmail.com  Wed Nov  2 17:37:29 2011
From: arturo.servin at gmail.com (Arturo Servin)
Date: Wed, 2 Nov 2011 20:37:29 -0200
Subject: IPV6 6to4 and 6In4 Lab
In-Reply-To: <189B79EF119C4BEA96374EAAD13D8594@work>
References: <189B79EF119C4BEA96374EAAD13D8594@work>
Message-ID: <8E119D82-A02D-4B1F-87F8-D6BA00178F5D@gmail.com>


	Why don't you use just a tunnelbroker?

	I would take just a few minutes to setup a tunnel. From there, you can do a lot of stuff inside your network.

My 2 cents
/as

On 1 Nov 2011, at 18:36, Meftah Tayeb wrote:

> Hello folks,
> i'm posting this Message to both nanog and afnog lists
> preferably if i can get one from afnog to work with me a bit for routing IPV6 prefixs over him using at least static or OSPFv3 or BGP (at you like)
> i want to anounce my /48 optained from a friend as number) and 2002::/16 (6to4 prefixs=) at least for 10min to see real IPV6 traffic.
> if someone want to help me, please contact me
> thank you
>    Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/ 
> phone: +21321656139
> Mobile: +213660347746
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6596 (20111102) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com



From tayeb.meftah at gmail.com  Tue Nov  1 16:03:47 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Tue, 1 Nov 2011 23:03:47 +0200
Subject: IPV6 6to4 and 6In4 Lab
References: <189B79EF119C4BEA96374EAAD13D8594@work>
 <8E119D82-A02D-4B1F-87F8-D6BA00178F5D@gmail.com>
Message-ID: <10C73E92DC014C21A2F42E32ED5F7628@work>

like i say, no routing
HE.Nett won accept me cause i don't have a AS number

----- Original Message ----- 
From: "Arturo Servin" <arturo.servin at gmail.com>
To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
Cc: <nanog at nanog.org>; <afnog at afnog.org>
Sent: Thursday, November 03, 2011 12:37 AM
Subject: Re: IPV6 6to4 and 6In4 Lab



Why don't you use just a tunnelbroker?

I would take just a few minutes to setup a tunnel. From there, you can do a 
lot of stuff inside your network.

My 2 cents
/as

On 1 Nov 2011, at 18:36, Meftah Tayeb wrote:

> Hello folks,
> i'm posting this Message to both nanog and afnog lists
> preferably if i can get one from afnog to work with me a bit for routing 
> IPV6 prefixs over him using at least static or OSPFv3 or BGP (at you like)
> i want to anounce my /48 optained from a friend as number) and 2002::/16 
> (6to4 prefixs=) at least for 10min to see real IPV6 traffic.
> if someone want to help me, please contact me
> thank you
>    Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/
> phone: +21321656139
> Mobile: +213660347746
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature database 6596 (20111102) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature 
database 6596 (20111102) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




__________ Information from ESET NOD32 Antivirus, version of virus signature database 6596 (20111102) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





From mpalmer at hezmatt.org  Wed Nov  2 18:02:15 2011
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Thu, 3 Nov 2011 10:02:15 +1100
Subject: Performance Issues - PTR Records
In-Reply-To: <FCD26398C5EDE746BFC47F43EA52A17304E0EE9A@dino.ad.hostasaurus.com>
References: <FCD26398C5EDE746BFC47F43EA52A17304E0EE9A@dino.ad.hostasaurus.com>
Message-ID: <20111102230215.GM3297@hezmatt.org>

On Wed, Nov 02, 2011 at 06:12:21PM -0400, David Hubbard wrote:
> From: Matt Chung [mailto:itsmemattchung at gmail.com] 
> > Historically, there was no compelling reason to create PTR 
> > records for our CPE however more and more applications seem
> > to be dependent on it.  Although we will be assigning a
> > record for each address, my question is why
> > is the application (specifically HTTP) dependent on a reverse record ?
> > What is the purpose?
> 
> As a web host, we frequently find customers who have
> added Apache rules to their ecommerce sites to block
> undesirable traffic, such as credit card scammers, etc.
> Not knowing any better, they often do this by just
> blocking anything that ends in .in to block Indonesia
> for example.

That's even less effective than you'd naively expect, given that Indonesia's
TLD is .id...

- Matt



From dhubbard at dino.hostasaurus.com  Wed Nov  2 18:05:04 2011
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Wed, 2 Nov 2011 19:05:04 -0400
Subject: Performance Issues - PTR Records
Message-ID: <FCD26398C5EDE746BFC47F43EA52A17304E0EE9B@dino.ad.hostasaurus.com>

From: Matthew Palmer [mailto:mpalmer at hezmatt.org] 
> 
> That's even less effective than you'd naively expect, given 
> that Indonesia's
> TLD is .id...
> 

Umm yeah, simple typo, but I appreciate the help.


From bzs at world.std.com  Wed Nov  2 18:08:47 2011
From: bzs at world.std.com (Barry Shein)
Date: Wed, 2 Nov 2011 19:08:47 -0400
Subject: Performance Issues - PTR Records
In-Reply-To: <FCD26398C5EDE746BFC47F43EA52A17304E0EE9A@dino.ad.hostasaurus.com>
References: <FCD26398C5EDE746BFC47F43EA52A17304E0EE9A@dino.ad.hostasaurus.com>
Message-ID: <20145.52607.535238.692116@world.std.com>


 > As a web host, we frequently find customers who have
 > added Apache rules to their ecommerce sites to block
 > undesirable traffic, such as credit card scammers, etc.
 > Not knowing any better, they often do this by just
 > blocking anything that ends in .in to block Indonesia
 > for example.  Well, once you choose to block by 
 > resolved name, now that site has to do a dns lookup
 > for every incoming request to see if it resolves to a
 > name that should be blocked.

Another practical problem with this approach is that .IN is India but
hey, at least it blocks something :-)

-- 
        -Barry Shein, that'd be .ID for Indonesia

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*


From ben at bjencks.net  Wed Nov  2 18:19:37 2011
From: ben at bjencks.net (Ben Jencks)
Date: Wed, 2 Nov 2011 19:19:37 -0400
Subject: Performance Issues - PTR Records
In-Reply-To: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
References: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
Message-ID: <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net>

On Nov 2, 2011, at 5:57 PM, Matt Chung wrote:

> I work for a regional ISP and very recently there has been an influx of
> calls reporting "slowness" when accessing certain websites (i.e
> google.com/voice/b) via HTTP.  After performing a tcpdump and analyzing the
> session, I have been able to pinpoint the latency at the application
> layer.  After the tcp session has been established, it takes up to 15-20
> seconds before the application begins sending data.   The root of the
> problem was that the PTR record for our customer(s) address does not
> exist.  As soon as the record is created, latency from the application is
> eliminated.  This is analogous to latency when accessing a server over SSH
> when no PTR is available.
> 
> A seperate packet capture from another customer exhibiting similar
> performance behavior showed many TCP retransmissions.  At first glance, I
> assumed this was network related however this correlates with the
> application not responding and inducing retransmissions at the TCP layer
> (different symptoms, same problem).
> 
> Historically, there was no compelling reason to create PTR records for our
> CPE however more and more applications seem to be dependent on it.
> Although we will be assigning a record for each address, my question is why
> is the application (specifically HTTP) dependent on a reverse record ?
> What is the purpose?

You're returning NXDOMAIN, right? If they're doing a reverse lookup and you return NXDOMAIN it should fail quickly, or else the application is even more horribly broken than just doing reverse lookups would imply. On the other hand, if you're not responding to the PTR request then that could be causing the timeout.

-Ben



From edward.avanti at gmail.com  Wed Nov  2 18:50:59 2011
From: edward.avanti at gmail.com (Edward avanti)
Date: Thu, 3 Nov 2011 09:50:59 +1000
Subject: BGP conf
In-Reply-To: <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o>
References: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
 <afe93d54-e984-47cd-a739-f0bf86918679@blur>
 <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o>
Message-ID: <CAJxJZc=e74v=73OAEf_-W2GZogU3QPk-kENu6y4uwYJ9Of7uyg@mail.gmail.com>

Halo,
sorry, my english not so perfect, at no time I mean send to IX what Verizon
send me, I'm not THAT stupid hehe
I mean if destination/origin is via IX, then send THAT traffic only by IX
and not Verizon.

On Thu, Nov 3, 2011 at 1:54 AM, Holmes,David A <dholmes at mwdh2o.com> wrote:

> This is a perfect example of why it is crucial that inbound route filters
> be scrupulously maintained in upstream BGP providers. Who knows who is out
> there.
>
> -----Original Message-----
> From: McCall, Gabriel [mailto:Gabriel.McCall at thyssenkrupp.com]
> Sent: Tuesday, November 01, 2011 7:29 PM
> To: Edward avanti; nanog at nanog.org
> Subject: Re: BGP conf
>
> Google for "team cymru secure bgp template" for a good starting point.
>
>
> -----Original message-----
> From: Edward avanti <edward.avanti at gmail.com>
> To: "nanog at nanog.org" <nanog at nanog.org>
> Sent: Wed, Nov 2, 2011 01:01:37 GMT+00:00
> Subject: BGP conf
>
> Halo,
> First, I accept this might not really right list for request, have use nsp
> cisco list but only first post to was succeed, sent several other for past
> 4 day and none appear (verified by list archive) so please excuse request.
>
> I am in need of a cisco config for BGP setup, we have a require to include
> IX peering at new location as well as our Verizon link, we like to take
> full bgp from Verizon and send to IX what they send us, I spend days
> reading google, and so many conflict web site example, so many example seem
> insecure no prefix list so on. end result to date is only sore eyes, would
> someone who do same (not need be Verizon) be kind to send us off list
> working running config (yes without your password heh) or at least how to
> apply to BGP router including access/prefix list and interfaces so we have
> an idea on what do, if you take two full BGP feed from two transit
> carrierin load share and IX, that good, because that our stage three plan,
> but I can work without two transit.
>
> I am not ignorant with cisco 7201, but am total newby to BGP.
>
> Best Thanks
> Edwardo
>
>
> This communication, together with any attachments or embedded links, is
> for the sole use of the intended recipient(s) and may contain information
> that is confidential or legally protected. If you are not the intended
> recipient, you are hereby notified that any review, disclosure, copying,
> dissemination, distribution or use of this communication is strictly
> prohibited. If you have received this communication in error, please notify
> the sender immediately by return e-mail message and delete the original and
> all copies of the communication, along with any attachments or embedded
> links, from your system.
>

From jsw at inconcepts.biz  Wed Nov  2 19:01:05 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Wed, 2 Nov 2011 20:01:05 -0400
Subject: BGP conf
In-Reply-To: <CAJxJZc=e74v=73OAEf_-W2GZogU3QPk-kENu6y4uwYJ9Of7uyg@mail.gmail.com>
References: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
 <afe93d54-e984-47cd-a739-f0bf86918679@blur>
 <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o>
 <CAJxJZc=e74v=73OAEf_-W2GZogU3QPk-kENu6y4uwYJ9Of7uyg@mail.gmail.com>
Message-ID: <CAPWAtb+HQUM1b8h7Rib84SsTH_SULb0K_O1Gm5CZ+upsdd-Fvg@mail.gmail.com>

On Wed, Nov 2, 2011 at 7:50 PM, Edward avanti <edward.avanti at gmail.com> wrote:
> sorry, my english not so perfect, at no time I mean send to IX what Verizon
> send me, I'm not THAT stupid hehe
> I mean if destination/origin is via IX, then send THAT traffic only by IX
> and not Verizon.

I understood what you mean.  The recommendations in my earlier reply
are still the best ones you've received:
1) hire a consultant to assist you both now and with any future problems
or 2) do not worry about being multi-homed, because the extra
complexity will do you more harm than good

Imagine if you took your car to a shop and asked for new tires, and
the mechanic said, "well, I have never changed tires before and I'm
not sure I have the right tools, but if you give me a couple of days I
think I can read about it on the Internet and figure it out."  Of
course you would not buy tires from him, you would go to another shop.
 That mechanic would quickly find that, if he wants to sell tires, he
needs to learn how to install them or hire someone to do it for him.

What you are asking your boss/company to do is trust you to put tires
on their car without the right tools or knowledge.  The result of that
is probably how your network will end up: "a wreck."

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From mysidia at gmail.com  Wed Nov  2 19:38:30 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 2 Nov 2011 19:38:30 -0500
Subject: Performance Issues - PTR Records
In-Reply-To: <20145.52607.535238.692116@world.std.com>
References: <FCD26398C5EDE746BFC47F43EA52A17304E0EE9A@dino.ad.hostasaurus.com>
 <20145.52607.535238.692116@world.std.com>
Message-ID: <CAAAwwbVmJWebFJO-nd-0sZQucq7i0Dtk31z2j37UWOWLz4me0A@mail.gmail.com>

On Wed, Nov 2, 2011 at 6:08 PM, Barry Shein <bzs at world.std.com> wrote:
> Another practical problem with this approach is that .IN is India but
> hey, at least it blocks something :-)

There are also some services out there that block connections
entirely, if the user doesn't have a PTR record.
I'm thinking IRC servers, MUDs,  and some other services with strange
security policies that check for a port 113 IDENT response and RDNS to
make a dark magic security decision to block a user who has no PTR.

But in the modern world... more commonly,  MTAs such as sendmail are
often configured to require a valid PTR record.     So as an ISP, you
may be breaking your user's local MTA if you don't have the correct
PTR for their IP addresses.

So I would say following the RFCs and implementing the proper PTRs
will help with that performance issue as a side-effect  of having a
valid zone,  and   head off   other issues  with  possibly less
popular services that are still blocking connections based on lack of
proper PTR. :)


> --
> ? ? ? ?-Barry Shein, that'd be .ID for Indonesia

--
-JH


From jbates at brightok.net  Wed Nov  2 19:44:48 2011
From: jbates at brightok.net (Jack Bates)
Date: Wed, 02 Nov 2011 19:44:48 -0500
Subject: BGP conf
In-Reply-To: <CAPWAtb+HQUM1b8h7Rib84SsTH_SULb0K_O1Gm5CZ+upsdd-Fvg@mail.gmail.com>
References: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
 <afe93d54-e984-47cd-a739-f0bf86918679@blur>
 <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o>
 <CAJxJZc=e74v=73OAEf_-W2GZogU3QPk-kENu6y4uwYJ9Of7uyg@mail.gmail.com>
 <CAPWAtb+HQUM1b8h7Rib84SsTH_SULb0K_O1Gm5CZ+upsdd-Fvg@mail.gmail.com>
Message-ID: <4EB1E400.5010601@brightok.net>

On 11/2/2011 7:01 PM, Jeff Wheeler wrote:
> What you are asking your boss/company to do is trust you to put tires
> on their car without the right tools or knowledge.  The result of that
> is probably how your network will end up: "a wreck."

Reminds me of the look on my original boss' face when I said, "Well, I 
have no BGP experience, but I think I'm going to redo this entire BGP 
config. It doesn't look right." I then proceeded to try every ? 
hierarchy under bgp in the then cisco routers and read up on every 
command until I understood each one.

Okay, it was simple, had no route-maps, and used access-lists instead of 
prefix-lists. It worked for a single 7206 BGP aggregation router.

Now I have the mile long monstrosity that uses BGP communities for 
everything, and of route-maps/policies with prefix-lists for downstream 
customers. You have to start somewhere.

cymru secure bgp templates is probably a good beginning. Careful study 
of your routing platform, what it supports, and reading up on what it 
means. If you don't understand something, use vendor specific 
lists/forums/documentation/google until you do.



Jack


From paul4004 at gmail.com  Wed Nov  2 19:48:45 2011
From: paul4004 at gmail.com (PC)
Date: Wed, 2 Nov 2011 18:48:45 -0600
Subject: Performance Issues - PTR Records
In-Reply-To: <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net>
References: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
 <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net>
Message-ID: <CAJAdsDkGc2CYfa=CDuCDSoFw1xVQ0TKz4B_MAPqBbFgFsyPnRQ@mail.gmail.com>

What happens if the ISP never defines a name server with their RIR for
their provider-independent address space?  Does ARIN point to somewhere
which supplies NXDOMAIN?  Just a thought -- I don't have a clue.

It is entirely possible they have it pointed to their non-existent or
broken DNS.  Given current best practices, I see no reason not to assign a
generic x.x.x.x-dynamic.customer.isp.com DNS across their netblock.

On Wed, Nov 2, 2011 at 5:19 PM, Ben Jencks <ben at bjencks.net> wrote:

> On Nov 2, 2011, at 5:57 PM, Matt Chung wrote:
>
> > I work for a regional ISP and very recently there has been an influx of
> > calls reporting "slowness" when accessing certain websites (i.e
> > google.com/voice/b) via HTTP.  After performing a tcpdump and analyzing
> the
> > session, I have been able to pinpoint the latency at the application
> > layer.  After the tcp session has been established, it takes up to 15-20
> > seconds before the application begins sending data.   The root of the
> > problem was that the PTR record for our customer(s) address does not
> > exist.  As soon as the record is created, latency from the application is
> > eliminated.  This is analogous to latency when accessing a server over
> SSH
> > when no PTR is available.
> >
> > A seperate packet capture from another customer exhibiting similar
> > performance behavior showed many TCP retransmissions.  At first glance, I
> > assumed this was network related however this correlates with the
> > application not responding and inducing retransmissions at the TCP layer
> > (different symptoms, same problem).
> >
> > Historically, there was no compelling reason to create PTR records for
> our
> > CPE however more and more applications seem to be dependent on it.
> > Although we will be assigning a record for each address, my question is
> why
> > is the application (specifically HTTP) dependent on a reverse record ?
> > What is the purpose?
>
> You're returning NXDOMAIN, right? If they're doing a reverse lookup and
> you return NXDOMAIN it should fail quickly, or else the application is even
> more horribly broken than just doing reverse lookups would imply. On the
> other hand, if you're not responding to the PTR request then that could be
> causing the timeout.
>
> -Ben
>
>
>

From nanog at namor.ca  Wed Nov  2 19:58:59 2011
From: nanog at namor.ca (J)
Date: Wed, 02 Nov 2011 19:58:59 -0500
Subject: Performance Issues - PTR Records
In-Reply-To: <CAJAdsDkGc2CYfa=CDuCDSoFw1xVQ0TKz4B_MAPqBbFgFsyPnRQ@mail.gmail.com>
References: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
 <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net>
 <CAJAdsDkGc2CYfa=CDuCDSoFw1xVQ0TKz4B_MAPqBbFgFsyPnRQ@mail.gmail.com>
Message-ID: <4EB1E753.8080300@namor.ca>

PC wrote:
> What happens if the ISP never defines a name server with their RIR for
> their provider-independent address space?  Does ARIN point to somewhere
> which supplies NXDOMAIN?  Just a thought -- I don't have a clue.
> 
> It is entirely possible they have it pointed to their non-existent or
> broken DNS.  Given current best practices, I see no reason not to assign a
> generic x.x.x.x-dynamic.customer.isp.com DNS across their netblock.

I think that returns SERVFAIL somewhere down the line?

Does it make sense to reinforce the behaviour (good and bad terms left for
another time), while looking forward to v6?


From Courtney_Smith at Cable.Comcast.com  Wed Nov  2 20:24:16 2011
From: Courtney_Smith at Cable.Comcast.com (Smith, Courtney)
Date: Thu, 3 Nov 2011 01:24:16 +0000
Subject: Generating IPv6 list with filtergen.level3.net
Message-ID: <8DD18D69FFC6DB46AE9CDB191CD8B9810F13E43F@PACDCEXMB04.cable.comcast.com>

Anyone out there know how to generate a IPv6 list Level3's filtergen?  I tried Google but didn't find anything.


()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments



From itsmemattchung at gmail.com  Wed Nov  2 20:27:48 2011
From: itsmemattchung at gmail.com (Matt Chung)
Date: Wed, 2 Nov 2011 18:27:48 -0700
Subject: Performance Issues - PTR Records
In-Reply-To: <4EB1E753.8080300@namor.ca>
References: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
 <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net>
 <CAJAdsDkGc2CYfa=CDuCDSoFw1xVQ0TKz4B_MAPqBbFgFsyPnRQ@mail.gmail.com>
 <4EB1E753.8080300@namor.ca>
Message-ID: <4979DA6C-6B78-4032-B024-3977A822182F@gmail.com>

We really have no objections to creating records for our IPs however there was no compelling reason previously. With the manifestation of performance issues, we are currently creating a generic record for our addresses. 

I assumed that the applications would take absent records into consideration instead of waiting and timing out before responding with data. Trying to troubleshoot this issue from the limited visibility is difficult ; the latency the application is introducing is abstracted (unless I am unaware of that troubleshooting technique).


Sent from my iPhone

On Nov 2, 2011, at 5:58 PM, J <nanog at namor.ca> wrote:

> PC wrote:
>> What happens if the ISP never defines a name server with their RIR for
>> their provider-independent address space?  Does ARIN point to somewhere
>> which supplies NXDOMAIN?  Just a thought -- I don't have a clue.
>> 
>> It is entirely possible they have it pointed to their non-existent or
>> broken DNS.  Given current best practices, I see no reason not to assign a
>> generic x.x.x.x-dynamic.customer.isp.com DNS across their netblock.
> 
> I think that returns SERVFAIL somewhere down the line?
> 
> Does it make sense to reinforce the behaviour (good and bad terms left for
> another time), while looking forward to v6?
> 


From lesmith at ecsis.net  Wed Nov  2 20:33:45 2011
From: lesmith at ecsis.net (Larry Smith)
Date: Wed, 2 Nov 2011 20:33:45 -0500
Subject: Performance Issues - PTR Records
In-Reply-To: <4979DA6C-6B78-4032-B024-3977A822182F@gmail.com>
References: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
 <4EB1E753.8080300@namor.ca> <4979DA6C-6B78-4032-B024-3977A822182F@gmail.com>
Message-ID: <201111022033.45568.lesmith@ecsis.net>

On Wed November 2 2011 20:27, Matt Chung wrote:
> I assumed that the applications would take absent records into
> consideration instead of waiting and timing out before responding with
> data. Trying to troubleshoot this issue from the limited visibility is
> difficult ; the latency the application is introducing is abstracted
> (unless I am unaware of that troubleshooting technique).

When you mis-place your keys do you only look in one place and then give
up?  The calling server does not know there is "no" record until it exhausts
its list of DNS servers, which is probably what is introducing the delay you
are seeing (each server trying to find a PTR with each of its upsteams) until
they all time out...

-- 
Larry Smith
lesmith at ecsis.net


From jsw at inconcepts.biz  Wed Nov  2 20:58:24 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Wed, 2 Nov 2011 21:58:24 -0400
Subject: BGP conf
In-Reply-To: <4EB1E400.5010601@brightok.net>
References: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
 <afe93d54-e984-47cd-a739-f0bf86918679@blur>
 <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o>
 <CAJxJZc=e74v=73OAEf_-W2GZogU3QPk-kENu6y4uwYJ9Of7uyg@mail.gmail.com>
 <CAPWAtb+HQUM1b8h7Rib84SsTH_SULb0K_O1Gm5CZ+upsdd-Fvg@mail.gmail.com>
 <4EB1E400.5010601@brightok.net>
Message-ID: <CAPWAtbJ4_dtBqwT+qj_tUJ6qtouzDu43+RwYhovYxnn_ywRkTw@mail.gmail.com>

On Wed, Nov 2, 2011 at 8:44 PM, Jack Bates <jbates at brightok.net> wrote:
> Now I have the mile long monstrosity that uses BGP communities for
> everything, and of route-maps/policies with prefix-lists for downstream
> customers. You have to start somewhere.
>
> cymru secure bgp templates is probably a good beginning.

I guess ten years of watching RIRs and users de-bogon new /8s didn't
teach you why those Cymru examples are more dangerous than they are
good.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From Epperson at Colorado.EDU  Wed Nov  2 21:00:20 2011
From: Epperson at Colorado.EDU (Kevin Epperson)
Date: Wed, 2 Nov 2011 20:00:20 -0600 (MDT)
Subject: Generating IPv6 list with filtergen.level3.net
In-Reply-To: <8DD18D69FFC6DB46AE9CDB191CD8B9810F13E43F@PACDCEXMB04.cable.comcast.com>
References: <8DD18D69FFC6DB46AE9CDB191CD8B9810F13E43F@PACDCEXMB04.cable.comcast.com>
Message-ID: <Pine.GSO.4.64.1111021955540.883@rintintin.colorado.edu>

Hi Courtney -

Try something like:

whois -h filtergen.level3.net "AS3356 -cp -v6"
  or
whois -h filtergen.level3.net "AS3356 -cp -v4v6"

Using AS7922 or something of that nature (currently I dont see any v6 
routes registered under 7922.)

 	-Kevin


On Thu, 3 Nov 2011, Smith, Courtney wrote:

> Anyone out there know how to generate a IPv6 list Level3's filtergen?  I tried Google but didn't find anything.
>
>
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
>
>


From jbates at brightok.net  Wed Nov  2 21:04:04 2011
From: jbates at brightok.net (Jack Bates)
Date: Wed, 02 Nov 2011 21:04:04 -0500
Subject: BGP conf
In-Reply-To: <CAPWAtbJ4_dtBqwT+qj_tUJ6qtouzDu43+RwYhovYxnn_ywRkTw@mail.gmail.com>
References: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
 <afe93d54-e984-47cd-a739-f0bf86918679@blur>
 <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o>
 <CAJxJZc=e74v=73OAEf_-W2GZogU3QPk-kENu6y4uwYJ9Of7uyg@mail.gmail.com>
 <CAPWAtb+HQUM1b8h7Rib84SsTH_SULb0K_O1Gm5CZ+upsdd-Fvg@mail.gmail.com>
 <4EB1E400.5010601@brightok.net>
 <CAPWAtbJ4_dtBqwT+qj_tUJ6qtouzDu43+RwYhovYxnn_ywRkTw@mail.gmail.com>
Message-ID: <4EB1F694.5050301@brightok.net>

On 11/2/2011 8:58 PM, Jeff Wheeler wrote:
> On Wed, Nov 2, 2011 at 8:44 PM, Jack Bates<jbates at brightok.net>  wrote:
>> Now I have the mile long monstrosity that uses BGP communities for
>> everything, and of route-maps/policies with prefix-lists for downstream
>> customers. You have to start somewhere.
>>
>> cymru secure bgp templates is probably a good beginning.
> I guess ten years of watching RIRs and users de-bogon new /8s didn't
> teach you why those Cymru examples are more dangerous than they are
> good.
>
Have to read the current cymru bgp templates?

"

! Team Cymru has removed all static bogon references from this template
! due to the high probability that the application of these bogon filters
! will be a one-time event. Unfortunately many of these templates are
! applied and never re-visited, despite our dire warnings that bogons do
! change.
!
! This doesn't mean bogon filtering can't be accomplished in an automated
! manner. Why not consider peering with our globally distributed bogon
! route-server project? Alternately you can obtain a current and well
! maintained bogon feed from our DNS and RADb services. Read more at the
! link below to learn how!
!
! 	https://www.team-cymru.org/Services/Bogons/
"



From Courtney_Smith at Cable.Comcast.com  Wed Nov  2 21:06:09 2011
From: Courtney_Smith at Cable.Comcast.com (Smith, Courtney)
Date: Thu, 3 Nov 2011 02:06:09 +0000
Subject: Generating IPv6 list with filtergen.level3.net
In-Reply-To: <Pine.GSO.4.64.1111021955540.883@rintintin.colorado.edu>
References: <8DD18D69FFC6DB46AE9CDB191CD8B9810F13E43F@PACDCEXMB04.cable.comcast.com>
 <Pine.GSO.4.64.1111021955540.883@rintintin.colorado.edu>
Message-ID: <8DD18D69FFC6DB46AE9CDB191CD8B9810F13E4C1@PACDCEXMB04.cable.comcast.com>

Thanks!!!

~$ whois -h filtergen.level3.net "RADB::AS7922 -v6"
Prefix list for policy RADB::AS7922 = 
 RADB::AS7922 

2001:558::/29
2001:558::/31
2601::/28
~$


Courtney Smith
Network Engineer
Comcast, National Engineering & Technical Operations
NOC:888.662.6386x2x2
http://as7922.peeringdb.com

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

-----Original Message-----
From: Kevin Epperson [mailto:Epperson at Colorado.EDU] 
Sent: Wednesday, November 02, 2011 10:00 PM
To: Smith, Courtney
Cc: 'nanog at nanog.org'
Subject: Re: Generating IPv6 list with filtergen.level3.net

Hi Courtney -

Try something like:

whois -h filtergen.level3.net "AS3356 -cp -v6"
  or
whois -h filtergen.level3.net "AS3356 -cp -v4v6"

Using AS7922 or something of that nature (currently I dont see any v6 
routes registered under 7922.)

 	-Kevin


On Thu, 3 Nov 2011, Smith, Courtney wrote:

> Anyone out there know how to generate a IPv6 list Level3's filtergen?  I tried Google but didn't find anything.
>
>
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
>
>


From mysidia at gmail.com  Wed Nov  2 21:09:36 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 2 Nov 2011 21:09:36 -0500
Subject: Performance Issues - PTR Records
In-Reply-To: <201111022033.45568.lesmith@ecsis.net>
References: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
 <4EB1E753.8080300@namor.ca>
 <4979DA6C-6B78-4032-B024-3977A822182F@gmail.com>
 <201111022033.45568.lesmith@ecsis.net>
Message-ID: <CAAAwwbWbqsBNXRE-H+RazNyxEmnkGyo5cU1ZFhHWG-LxeOnwRQ@mail.gmail.com>

On Wed, Nov 2, 2011 at 8:33 PM, Larry Smith <lesmith at ecsis.net> wrote:
> On Wed November 2 2011 20:27, Matt Chung wrote:
>> I assumed that the applications would take absent records into
> When you mis-place your keys do you only look in one place and then give
> up? ?The calling server does not know there is "no" record until it exhausts

If the reverse zone is properly configured, but just the PTR record is missing,
you get NXDOMAIN,  which is not "you mis-place your keys"; it's
"someone told you authoritatively that your keys don't exist", never existed
or no longer existed.

If you ask where your key ring went, and Frodo Baggins informs you that
it doesn't exist, because it was tossed down into a pool of magma on mount doom,
and you trust his reply, you stop looking for it.

The only way you don't trust a valid DNS reply is if you are
implementing DNSSEC,
and the "authoritative proof of non-existence" doesn't validate

--
-JH


From jsw at inconcepts.biz  Wed Nov  2 21:19:11 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Wed, 2 Nov 2011 22:19:11 -0400
Subject: BGP conf
In-Reply-To: <4EB1F694.5050301@brightok.net>
References: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
 <afe93d54-e984-47cd-a739-f0bf86918679@blur>
 <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o>
 <CAJxJZc=e74v=73OAEf_-W2GZogU3QPk-kENu6y4uwYJ9Of7uyg@mail.gmail.com>
 <CAPWAtb+HQUM1b8h7Rib84SsTH_SULb0K_O1Gm5CZ+upsdd-Fvg@mail.gmail.com>
 <4EB1E400.5010601@brightok.net>
 <CAPWAtbJ4_dtBqwT+qj_tUJ6qtouzDu43+RwYhovYxnn_ywRkTw@mail.gmail.com>
 <4EB1F694.5050301@brightok.net>
Message-ID: <CAPWAtbL67jtxYjB4iDVX02_Sf-4KMJdudM68koG0uW88y=UakA@mail.gmail.com>

On Wed, Nov 2, 2011 at 10:04 PM, Jack Bates <jbates at brightok.net> wrote:
> Have to read the current cymru bgp templates?
>
> ! manner. Why not consider peering with our globally distributed bogon
> ! route-server project? Alternately you can obtain a current and well

I'm not telling you something you don't already know, but for the
novices who regard this list as a source of expertise, I will explain
in greater detail why this is a really dumb idea.

If you took a list of bogons over eBGP from Cymru, you would get
unused /8s and similar.  What you don't get is a route that matches
whatever silly thing someone on the DFZ accidentally leaked: a
more-specific that will still cause you to route traffic to their
leaked prefix out to the Internet (and presumably, to their network.)

There is nothing good about this.  It's just adding unnecessary
complexity for no operational benefit.  There is bad about it.  It
adds complexity and risk.  What is that risk?  If you decide that the
Cymru "distributed bogon route-server" is for you, and simply rewrite
next-hops received on that session to Null0, it is possible that Cymru
could make an error, or otherwise introduce non-bogon routes into your
network as if they were bogons, causing black-holes.  This is
obviously too much to risk for something that has no operational
benefit.

The Cymru guys do many positive things.  One of the more questionable
things they do, though, is operate a route-server with the intention
of black-holing botnet C&C IPs on a very wide scale.  This is
certainly a positive thing to do, but it was not done in a transparent
manner; and in fact didn't even have management approval at Cogent
when they configured it on their network.  There was no established
channel to find out why your IP address appeared on this list or to
get it removed.  All it took for me to get the whole idea canned at
Cogent was one inquiry to management, asking why engineers had quietly
started using a clandestine blackhole list operated by a third-party
and would not give any answers to a customer if one of their IPs
appeared on that list.  The IP address I inquired about was certainly
not a botnet C&C node, and how it ended up on that list is a mystery.
I'm not saying there was any malicious intent, but it was a mistake at
least.

Trusting that "bogon" black-hole list to do something you don't even
need to do anyway is not smart.  It's *especially* not smart for some
novice who doesn't understand the implications of his decision.  This
is the danger of "cut & paste engineering."

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From jeff-kell at utc.edu  Wed Nov  2 22:46:00 2011
From: jeff-kell at utc.edu (Jeff Kell)
Date: Wed, 2 Nov 2011 23:46:00 -0400
Subject: BGP conf
In-Reply-To: <CAPWAtbJ4_dtBqwT+qj_tUJ6qtouzDu43+RwYhovYxnn_ywRkTw@mail.gmail.com>
References: <CAJxJZcmF3Vga=OjmXXyqG6QYC1aCrv29BY1GYSJnYPg_qcUjAA@mail.gmail.com>
 <afe93d54-e984-47cd-a739-f0bf86918679@blur>
 <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o>
 <CAJxJZc=e74v=73OAEf_-W2GZogU3QPk-kENu6y4uwYJ9Of7uyg@mail.gmail.com>
 <CAPWAtb+HQUM1b8h7Rib84SsTH_SULb0K_O1Gm5CZ+upsdd-Fvg@mail.gmail.com>
 <4EB1E400.5010601@brightok.net>
 <CAPWAtbJ4_dtBqwT+qj_tUJ6qtouzDu43+RwYhovYxnn_ywRkTw@mail.gmail.com>
Message-ID: <4EB20E78.70903@utc.edu>

On 11/2/2011 9:58 PM, Jeff Wheeler wrote:
> I guess ten years of watching RIRs and users de-bogon new /8s didn't
> teach you why those Cymru examples are more dangerous than they are good. 

If you follow "all" the CYMRU examples and subscribe to the BGP bogon
feed, that isn't an issue...

Jeff


From lmay at nframe.com  Wed Nov  2 23:45:53 2011
From: lmay at nframe.com (Larry May)
Date: Thu, 3 Nov 2011 00:45:53 -0400
Subject: BGP conf
In-Reply-To: <CAJxJZc=e74v=73OAEf_-W2GZogU3QPk-kENu6y4uwYJ9Of7uyg@mail.gmail.com>
Message-ID: <053E179161004E4C91C8613916AA37B90551A361@nframemail01.nframe.local>

Participants,

This thread makes me want to LAUGH and VOMIT at the same time...

This guy is asking for advice and all this list can do is poke and make
fun at him for trying to learn the right way to do things...

We ALL need to remember...NONE of us come out of the womb being BGP
experts... and anyone who says they are...are lying through their teeth.

I have had to work with such people who talked a big game...but in the
end didn't know their ass from a hole in the ground.

And to the original post Edward...if you follow "team CYMRU" you are
pretty much on the right path to being successful in your ventures...



-----Original Message-----
From: Edward avanti [mailto:edward.avanti at gmail.com] 
Sent: Wednesday, November 02, 2011 7:51 PM
To: Holmes, David A; nanog at nanog.org"
Subject: Re: BGP conf

Halo,
sorry, my english not so perfect, at no time I mean send to IX what
Verizon
send me, I'm not THAT stupid hehe
I mean if destination/origin is via IX, then send THAT traffic only by
IX
and not Verizon.

On Thu, Nov 3, 2011 at 1:54 AM, Holmes,David A <dholmes at mwdh2o.com>
wrote:

> This is a perfect example of why it is crucial that inbound route
filters
> be scrupulously maintained in upstream BGP providers. Who knows who is
out
> there.
>
> -----Original message-----
> From: Edward avanti <edward.avanti at gmail.com>
> To: "nanog at nanog.org" <nanog at nanog.org>
> Sent: Wed, Nov 2, 2011 01:01:37 GMT+00:00
> Subject: BGP conf
>
> Halo,
> First, I accept this might not really right list for request, have use
nsp
> cisco list but only first post to was succeed, sent several other for
past
> 4 day and none appear (verified by list archive) so please excuse
request.
>
> I am in need of a cisco config for BGP setup, we have a require to
include
> IX peering at new location as well as our Verizon link, we like to
take
> full bgp from Verizon and send to IX what they send us, I spend days
> reading google, and so many conflict web site example, so many example
seem
> insecure no prefix list so on. end result to date is only sore eyes,
would
> someone who do same (not need be Verizon) be kind to send us off list
> working running config (yes without your password heh) or at least how
to
> apply to BGP router including access/prefix list and interfaces so we
have
> an idea on what do, if you take two full BGP feed from two transit
> carrierin load share and IX, that good, because that our stage three
plan,
> but I can work without two transit.
>
> I am not ignorant with cisco 7201, but am total newby to BGP.
>
> Best Thanks
> Edwardo
>
>
> This communication, together with any attachments or embedded links,
is
> for the sole use of the intended recipient(s) and may contain
information
> that is confidential or legally protected. If you are not the intended
> recipient, you are hereby notified that any review, disclosure,
copying,
> dissemination, distribution or use of this communication is strictly
> prohibited. If you have received this communication in error, please
notify
> the sender immediately by return e-mail message and delete the
original and
> all copies of the communication, along with any attachments or
embedded
> links, from your system.
>


From ljb at merit.edu  Thu Nov  3 12:47:32 2011
From: ljb at merit.edu (Larry Blunk)
Date: Thu, 03 Nov 2011 13:47:32 -0400
Subject: Performance Issues - PTR Records
In-Reply-To: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
References: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
Message-ID: <4EB2D3B4.7060700@merit.edu>

On 11/02/2011 05:57 PM, Matt Chung wrote:
> I work for a regional ISP and very recently there has been an influx of
> calls reporting "slowness" when accessing certain websites (i.e
> google.com/voice/b) via HTTP.  After performing a tcpdump and analyzing the
> session, I have been able to pinpoint the latency at the application
> layer.  After the tcp session has been established, it takes up to 15-20
> seconds before the application begins sending data.   The root of the
> problem was that the PTR record for our customer(s) address does not
> exist.  As soon as the record is created, latency from the application is
> eliminated.  This is analogous to latency when accessing a server over SSH
> when no PTR is available.
>
> A seperate packet capture from another customer exhibiting similar
> performance behavior showed many TCP retransmissions.  At first glance, I
> assumed this was network related however this correlates with the
> application not responding and inducing retransmissions at the TCP layer
> (different symptoms, same problem).
>
> Historically, there was no compelling reason to create PTR records for our
> CPE however more and more applications seem to be dependent on it.
> Although we will be assigning a record for each address, my question is why
> is the application (specifically HTTP) dependent on a reverse record ?
> What is the purpose?
>
> Hope this is helpful as well
>

   We recently encountered a similar issue with a customer.
The sites that had slowness issues were configured to
use the traditional Google Analytics javascript instead
of the newer asynchronous code.
   The problem was not the lack of a PTR record, but rather
the in-addr delegation was pointing to lame servers that were
no longer responding (hence the long timeouts as the
Google servers attempted to perform reverse lookups
on the client IP's).  As others have pointed out, as long
as there's a valid nameserver responding, a lack of PTR
record would not cause issues as an NXDOMAIN record would
be sent back immediately and the Google Analytics server
will move on.


  -Larry Blunk
   Merit




From nonobvious at gmail.com  Thu Nov  3 16:15:19 2011
From: nonobvious at gmail.com (Bill Stewart)
Date: Thu, 3 Nov 2011 14:15:19 -0700
Subject: Outgoing SMTP Servers
In-Reply-To: <F05D77A9631CAE4097F7B69095F1B06F59722E48@EX02.drtel.lan>
References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local>
 <CAP-guGVKz-h44hvfMP53UhLSQNivxhPFn5wEngfyrZCe1sHTRA@mail.gmail.com>
 <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com>
 <CACnPsNVNe3GCsyOfjCVGZnrRLz2G=0ptOxvzhheYjiF0fA8T-Q@mail.gmail.com>
 <B8ECE656-6A9F-4EFA-A99E-97E73D997DB7@delong.com>
 <F05D77A9631CAE4097F7B69095F1B06F59720FA6@EX02.drtel.lan>
 <21422.1319729013@turing-police.cc.vt.edu>
 <F05D77A9631CAE4097F7B69095F1B06F597212F0@EX02.drtel.lan>
 <33536.1319751497@turing-police.cc.vt.edu>
 <4EAA056E.5010006@altadena.net>
 <CAP-guGUcWjx3oPUhr8N6nwHBZTbKG7qJVv0fwLQA-ukr1WaW7w@mail.gmail.com>
 <62968.1319816515@turing-police.cc.vt.edu>
 <F05D77A9631CAE4097F7B69095F1B06F59721B76@EX02.drtel.lan>
 <327761D3-53F7-4B52-9424-FC694FBB6851@delong.com>
 <F05D77A9631CAE4097F7B69095F1B06F59721C6F@EX02.drtel.lan>
 <025FE4D2-3B13-440B-BADC-AA1F5B3384DB@delong.com>
 <CAD45i00-We=syA2Sh3UD0TAHfrLS16p2aO9uZYE=k-Lq35C20g@mail.gmail.com>
 <F05D77A9631CAE4097F7B69095F1B06F59722E48@EX02.drtel.lan>
Message-ID: <CAD45i021HcQeJO87ARtikWCYPk8oK0QvQwU7Jj06sG0974hkgQ@mail.gmail.com>

On Mon, Oct 31, 2011 at 6:23 AM, Brian Johnson <bjohnson at drtel.com> wrote:
> For clarity it's really bad for ISPs to block ports other than 25 for the purposes of mail flow control... correct?
Yes, correct.  If you're using another mail submission port, you're
connecting to a mail service that has the responsibility not to let
spam escape, and your ISP has done its job of stopping point-source
pollution.


>Bill>I've got a strong preference for ISPs to run a
>Bill>Block-25-by-default/Enable-when-asked. ?[...]

> This is, of course, exactly why this blocking is done.

It looks like you're missing half my point, which is the Enable-when-asked part.
There are users who are perfectly legitimately running MTAs at home,
whether for reliability or privacy (e.g. so they can run SMTP-over-TLS
end-to-end) or just simplicity, and ISPs shouldn't be blocking them
(unless they're spammers, of course.)

> My take on this is that it IS best practice to have users use the submission port (587) for mail submission from the MUA to an MTA.
If you're running an MTA service, then yes.  If you're running a
transport service, then not necessarily.


-- 
----
? ? ? ? ? ?? Thanks;? ?? Bill

Note that this isn't my regular email account - It's still experimental so far.
And Google probably logs and indexes everything you send it.


From tayeb.meftah at gmail.com  Thu Nov  3 06:36:54 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Thu, 3 Nov 2011 13:36:54 +0200
Subject: looking for SixXS administtrator
Message-ID: <850F5DED855449888BD784F3ED7BDDE9@work>

Hello
please could one of the SixXS admin contact me privatly ?
thank you
    Meftah Tayeb
IT Consulting
http://www.tmvoip.com/ 
phone: +21321656139
Mobile: +213660347746


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6600 (20111104) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


From jeroen at unfix.org  Fri Nov  4 08:48:52 2011
From: jeroen at unfix.org (Jeroen Massar)
Date: Fri, 04 Nov 2011 14:48:52 +0100
Subject: looking for SixXS administtrator
In-Reply-To: <850F5DED855449888BD784F3ED7BDDE9@work>
References: <850F5DED855449888BD784F3ED7BDDE9@work>
Message-ID: <4EB3ED44.4090806@unfix.org>

On 2011-11-03 12:36 , Meftah Tayeb wrote:
> Hello
> please could one of the SixXS admin contact me privatly ?

As was previously pointed out to you on these very lists:

http://www.sixxs.net/contact/

Greets,
 Jeroen


From tayeb.meftah at gmail.com  Thu Nov  3 07:22:38 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Thu, 3 Nov 2011 14:22:38 +0200
Subject: looking for SixXS administtrator
References: <850F5DED855449888BD784F3ED7BDDE9@work>
 <4EB3ED44.4090806@unfix.org>
Message-ID: <044665A02784425F8FEE8E68D9FBBF1B@work>

dear  Jeroen,
why i'm posting here is that cause Sixxs never reply to my query.

----- Original Message ----- 
From: "Jeroen Massar" <jeroen at unfix.org>
To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
Cc: <nanog at nanog.org>; <afnog at afnog.org>
Sent: Friday, November 04, 2011 3:48 PM
Subject: Re: looking for SixXS administtrator


> On 2011-11-03 12:36 , Meftah Tayeb wrote:
>> Hello
>> please could one of the SixXS admin contact me privatly ?
>
> As was previously pointed out to you on these very lists:
>
> http://www.sixxs.net/contact/
>
> Greets,
> Jeroen
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature database 6601 (20111104) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> 


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6601 (20111104) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





From jeroen at unfix.org  Fri Nov  4 09:01:53 2011
From: jeroen at unfix.org (Jeroen Massar)
Date: Fri, 04 Nov 2011 15:01:53 +0100
Subject: looking for SixXS administtrator
In-Reply-To: <044665A02784425F8FEE8E68D9FBBF1B@work>
References: <850F5DED855449888BD784F3ED7BDDE9@work>
 <4EB3ED44.4090806@unfix.org> <044665A02784425F8FEE8E68D9FBBF1B@work>
Message-ID: <4EB3F051.9060103@unfix.org>

On 2011-11-03 13:22 , Meftah Tayeb wrote:
> dear  Jeroen,
> why i'm posting here is that cause Sixxs never reply to my query.

http://mailman.nanog.org/pipermail/nanog/2011-September/040108.html

"i don't need this stupid SixXs at all anymore."

Please keep it that way.

Greets,
 Jeroen


From trelane at trelane.net  Fri Nov  4 10:18:37 2011
From: trelane at trelane.net (Andrew Kirch)
Date: Fri, 04 Nov 2011 11:18:37 -0400
Subject: looking for SixXS administtrator
In-Reply-To: <4EB3F051.9060103@unfix.org>
References: <850F5DED855449888BD784F3ED7BDDE9@work>
 <4EB3ED44.4090806@unfix.org> <044665A02784425F8FEE8E68D9FBBF1B@work>
 <4EB3F051.9060103@unfix.org>
Message-ID: <4EB4024D.9070107@trelane.net>

On 11/4/2011 10:01 AM, Jeroen Massar wrote:

I realize you're volunteers, but grow up.

good grief children these days.

Andrew


From jeroen at unfix.org  Fri Nov  4 11:02:30 2011
From: jeroen at unfix.org (Jeroen Massar)
Date: Fri, 04 Nov 2011 17:02:30 +0100
Subject: looking for SixXS administtrator
In-Reply-To: <4EB4024D.9070107@trelane.net>
References: <850F5DED855449888BD784F3ED7BDDE9@work>
 <4EB3ED44.4090806@unfix.org> <044665A02784425F8FEE8E68D9FBBF1B@work>
 <4EB3F051.9060103@unfix.org> <4EB4024D.9070107@trelane.net>
Message-ID: <4EB40C96.8080007@unfix.org>

On 2011-11-04 16:18 , Andrew Kirch wrote:
> On 11/4/2011 10:01 AM, Jeroen Massar wrote:
> 
> I realize you're volunteers, but grow up.

We already did quite some time ago, which means we have full time jobs
nowadays and guess what goes first before all those whining people ;)

As this is a mailing list for operational content though, I suggest you
address your problems to info at sixxs.net if you still have them, they
will then be handled in due time.

> good grief children these days.

Nothing worse than old whiny folks eh ;)

Greets,
 Jeroen


From harbor235 at gmail.com  Fri Nov  4 11:09:44 2011
From: harbor235 at gmail.com (harbor235)
Date: Fri, 4 Nov 2011 12:09:44 -0400
Subject: MPLS TE
Message-ID: <CAB_zYdKv0v13-8eezR8VRwCJ=Myxh2prvr-odW-X-U6Lp027kQ@mail.gmail.com>

TE lab testing flushing out how TE works, configured a primary and backup
tunnel between PEs, both directions.
Primary is dynamic and backup is explicit, initially priorities were the
same, I then choose
to make one tunnel preferred over the other adjusting the priorities, I
choose the tunnel that was backup
to become primary to watch the traffic shift. (primary path was P1-P2-P3,
backup path P1-P3). However,
the traffic did not shift, a manual shut on a P3-P2 interface made the
traffic shift, reintroduction
kept the traffic on P1-P3,  then a "mpls traffic reoptimize" moved the
traffic back to P1-P2-P3.

Obviously the preferred MPLS tunnel is still  P1-P2-P3 even though I
configured "tunnel mpls traffic-eng priority 1 1"
on P1-P3 and "tunnel mpls traffic-eng priority 7 7" on P1-P2-P3. What am I
missing here?


My setup:



CE-----PE-----P1----------P3-------PE----CE
                     \          /
                      \        /
                          P2


Mike

From list-nanog2 at dragon.net  Fri Nov  4 11:28:14 2011
From: list-nanog2 at dragon.net (Paul Ebersman)
Date: Fri, 04 Nov 2011 09:28:14 -0700
Subject: Performance Issues - PTR Records
In-Reply-To: <CAJAdsDkGc2CYfa=CDuCDSoFw1xVQ0TKz4B_MAPqBbFgFsyPnRQ@mail.gmail.com>
References: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
 <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net>
 <CAJAdsDkGc2CYfa=CDuCDSoFw1xVQ0TKz4B_MAPqBbFgFsyPnRQ@mail.gmail.com>
Message-ID: <20111104162814.24EFAC0DC81@fafnir.remote.dragon.net>


paul4004> It is entirely possible they have it pointed to their
paul4004> non-existent or broken DNS.  Given current best practices, I
paul4004> see no reason not to assign a generic
paul4004> x.x.x.x-dynamic.customer.isp.com DNS across their netblock.

It's already been pointed out that lame delegations are more likely
problems for many. But the "we'll just pre-fill in-addr to avoid
problems" isn't going to work for ip6.arpa. If anyone has enough
hardware to serve the zone for a /48 (64k * 4bil * 4bil *
bytes-in-record), I'd love to see it. :)

We need to get web and app folks to stop counting on
ip6.arpa/in-addr.arpa as a validation of trustworthiness. PTR make some
sense for validating servers, MTAs, etc. and it's handy for traceroute
but it was never a great tool and it's getting less useful with time.


From avitkovsky at emea.att.com  Fri Nov  4 11:49:31 2011
From: avitkovsky at emea.att.com (Vitkovsky, Adam)
Date: Fri, 4 Nov 2011 17:49:31 +0100
Subject: MPLS TE
In-Reply-To: <CAB_zYdKv0v13-8eezR8VRwCJ=Myxh2prvr-odW-X-U6Lp027kQ@mail.gmail.com>
References: <CAB_zYdKv0v13-8eezR8VRwCJ=Myxh2prvr-odW-X-U6Lp027kQ@mail.gmail.com>
Message-ID: <D51498F0B6E1EF408AC4D63440BFD6F8BB1C995B9D@skbramsx02.emea.att.com>

Hello Mike,
What exactly do you mean by primary and backup please?
As the tunnel "mpls traffic-eng priority" cmd simply only specifies the setup and hold priorities 
(you'd use those when there are tunnels carrying low priority traffic filling up the available TE BW -and you need to setup a tunnel carrying voice through that link -because the primary link failed -the higher setup priority of the voice tunnel would knock down some of the scavenger tunnels with lower hold priority)

Now I'm not sure but I guess you can't have one tunnel act as backup for a specific te-tunnel
Though you can configure a te-tunnel to act as a backup for a link

Since one of your tunnels is dynamic it can be re-established around the failed link

Though which tunnel is going to be used to forward traffic is based on how you instruct the trafic to use one of the tunnes as primary path


adam
 

-----Original Message-----
From: harbor235 [mailto:harbor235 at gmail.com] 
Sent: Friday, November 04, 2011 5:10 PM
To: NANOG list
Subject: MPLS TE

TE lab testing flushing out how TE works, configured a primary and backup
tunnel between PEs, both directions.
Primary is dynamic and backup is explicit, initially priorities were the
same, I then choose
to make one tunnel preferred over the other adjusting the priorities, I
choose the tunnel that was backup
to become primary to watch the traffic shift. (primary path was P1-P2-P3,
backup path P1-P3). However,
the traffic did not shift, a manual shut on a P3-P2 interface made the
traffic shift, reintroduction
kept the traffic on P1-P3,  then a "mpls traffic reoptimize" moved the
traffic back to P1-P2-P3.

Obviously the preferred MPLS tunnel is still  P1-P2-P3 even though I
configured "tunnel mpls traffic-eng priority 1 1"
on P1-P3 and "tunnel mpls traffic-eng priority 7 7" on P1-P2-P3. What am I
missing here?


My setup:



CE-----PE-----P1----------P3-------PE----CE
                     \          /
                      \        /
                          P2


Mike


From harbor235 at gmail.com  Fri Nov  4 12:00:00 2011
From: harbor235 at gmail.com (harbor235)
Date: Fri, 4 Nov 2011 13:00:00 -0400
Subject: MPLS TE
In-Reply-To: <D51498F0B6E1EF408AC4D63440BFD6F8BB1C995B9D@skbramsx02.emea.att.com>
References: <CAB_zYdKv0v13-8eezR8VRwCJ=Myxh2prvr-odW-X-U6Lp027kQ@mail.gmail.com>
 <D51498F0B6E1EF408AC4D63440BFD6F8BB1C995B9D@skbramsx02.emea.att.com>
Message-ID: <CAB_zYdJ_KvJZMmz_ifeWr479fwkjf8j69LaOCmQ6DjqZVEH0qQ@mail.gmail.com>

I am also looking at FRR which uses a backup tunnel for fast convergence. I
did however not think
about the dynamic nature of the tunnel and the potential for
reestablishment.


Mike

On Fri, Nov 4, 2011 at 12:49 PM, Vitkovsky, Adam <avitkovsky at emea.att.com>wrote:

> Hello Mike,
> What exactly do you mean by primary and backup please?
> As the tunnel "mpls traffic-eng priority" cmd simply only specifies the
> setup and hold priorities
> (you'd use those when there are tunnels carrying low priority traffic
> filling up the available TE BW -and you need to setup a tunnel carrying
> voice through that link -because the primary link failed -the higher setup
> priority of the voice tunnel would knock down some of the scavenger tunnels
> with lower hold priority)
>
> Now I'm not sure but I guess you can't have one tunnel act as backup for a
> specific te-tunnel
> Though you can configure a te-tunnel to act as a backup for a link
>
> Since one of your tunnels is dynamic it can be re-established around the
> failed link
>
> Though which tunnel is going to be used to forward traffic is based on how
> you instruct the trafic to use one of the tunnes as primary path
>
>
> adam
>
>
> -----Original Message-----
> From: harbor235 [mailto:harbor235 at gmail.com]
> Sent: Friday, November 04, 2011 5:10 PM
> To: NANOG list
> Subject: MPLS TE
>
> TE lab testing flushing out how TE works, configured a primary and backup
> tunnel between PEs, both directions.
> Primary is dynamic and backup is explicit, initially priorities were the
> same, I then choose
> to make one tunnel preferred over the other adjusting the priorities, I
> choose the tunnel that was backup
> to become primary to watch the traffic shift. (primary path was P1-P2-P3,
> backup path P1-P3). However,
> the traffic did not shift, a manual shut on a P3-P2 interface made the
> traffic shift, reintroduction
> kept the traffic on P1-P3,  then a "mpls traffic reoptimize" moved the
> traffic back to P1-P2-P3.
>
> Obviously the preferred MPLS tunnel is still  P1-P2-P3 even though I
> configured "tunnel mpls traffic-eng priority 1 1"
> on P1-P3 and "tunnel mpls traffic-eng priority 7 7" on P1-P2-P3. What am I
> missing here?
>
>
> My setup:
>
>
>
> CE-----PE-----P1----------P3-------PE----CE
>                     \          /
>                      \        /
>                          P2
>
>
> Mike
>

From tim at pelican.org  Fri Nov  4 12:07:39 2011
From: tim at pelican.org (Tim Franklin)
Date: Fri, 04 Nov 2011 17:07:39 -0000 (GMT)
Subject: Performance Issues - PTR Records
In-Reply-To: <20111104162814.24EFAC0DC81@fafnir.remote.dragon.net>
Message-ID: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org>

> It's already been pointed out that lame delegations are more likely
> problems for many. But the "we'll just pre-fill in-addr to avoid
> problems" isn't going to work for ip6.arpa. If anyone has enough
> hardware to serve the zone for a /48 (64k * 4bil * 4bil *
> bytes-in-record), I'd love to see it. :)

If PTR exists in zone file, serve it.
Else, synthesize generic reverse.
Jobsagoodun.

> We need to get web and app folks to stop counting on
> ip6.arpa/in-addr.arpa as a validation of trustworthiness. PTR make some
> sense for validating servers, MTAs, etc. and it's handy for traceroute
> but it was never a great tool and it's getting less useful with time.

I've always seen it as a reasonable indication of a) minimum level of clue and b) giving a damn.  If you can't be bothered or don't know how to provide even basic generic rDNS for your network, there's a reasonable chance you're lacking in other areas of network / user management.  (Not "you" personally, of course).

Regards,
Tim.



From cscora at apnic.net  Fri Nov  4 14:17:41 2011
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 5 Nov 2011 05:17:41 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201111041917.pA4JHfLA026978@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 05 Nov, 2011

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              380959
    Prefixes after maximum aggregation:                          166564
    Deaggregation factor:                                          2.29
    Unique aggregates announced to Internet:                     187114
Total ASes present in the Internet Routing Table:                 39222
    Prefixes per ASN:                                              9.71
Origin-only ASes present in the Internet Routing Table:           32367
Origin ASes announcing only one prefix:                           15483
Transit ASes present in the Internet Routing Table:                5264
Transit-only ASes present in the Internet Routing Table:            133
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      33
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:              1628
    Unregistered ASNs in the Routing Table:                         862
Number of 32-bit ASNs allocated by the RIRs:                       1925
Number of 32-bit ASNs visible in the Routing Table:                1591
Prefixes from 32-bit ASNs in the Routing Table:                    3686
Special use prefixes present in the Routing Table:                    3
Prefixes being announced from unallocated address space:             86
Number of addresses announced to Internet:                   2489977408
    Equivalent to 148 /8s, 106 /16s and 10 /24s
    Percentage of available address space announced:               67.2
    Percentage of allocated address space announced:               67.2
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               91.6
Total number of prefixes smaller than registry allocations:      160771

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    94863
    Total APNIC prefixes after maximum aggregation:               31059
    APNIC Deaggregation factor:                                    3.05
Prefixes being announced from the APNIC address blocks:           91315
    Unique aggregates announced from the APNIC address blocks:    38279
APNIC Region origin ASes present in the Internet Routing Table:    4595
    APNIC Prefixes per ASN:                                       19.87
APNIC Region origin ASes announcing only one prefix:               1270
APNIC Region transit ASes present in the Internet Routing Table:    716
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         21
Number of APNIC region 32-bit ASNs visible in the Routing Table:    101
Number of APNIC addresses announced to Internet:              629651296
    Equivalent to 37 /8s, 135 /16s and 183 /24s
    Percentage of available APNIC address space announced:         79.9

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
                       182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
                       219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    145925
    Total ARIN prefixes after maximum aggregation:                74475
    ARIN Deaggregation factor:                                     1.96
Prefixes being announced from the ARIN address blocks:           117809
    Unique aggregates announced from the ARIN address blocks:     48321
ARIN Region origin ASes present in the Internet Routing Table:    14739
    ARIN Prefixes per ASN:                                         7.99
ARIN Region origin ASes announcing only one prefix:                5639
ARIN Region transit ASes present in the Internet Routing Table:    1559
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          25
Number of ARIN region 32-bit ASNs visible in the Routing Table:      12
Number of ARIN addresses announced to Internet:               804645888
    Equivalent to 47 /8s, 245 /16s and 236 /24s
    Percentage of available ARIN address space announced:          63.9

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 173/8,
                       174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8,
                       208/8, 209/8, 214/8, 215/8, 216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                     91828
    Total RIPE prefixes after maximum aggregation:                51035
    RIPE Deaggregation factor:                                     1.80
Prefixes being announced from the RIPE address blocks:            84299
    Unique aggregates announced from the RIPE address blocks:     54500
RIPE Region origin ASes present in the Internet Routing Table:    16084
    RIPE Prefixes per ASN:                                         5.24
RIPE Region origin ASes announcing only one prefix:                7968
RIPE Region transit ASes present in the Internet Routing Table:    2531
Average RIPE Region AS path length visible:                         4.7
    Max RIPE Region AS path length visible:                          33
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1108
Number of RIPE addresses announced to Internet:               491707840
    Equivalent to 29 /8s, 78 /16s and 221 /24s
    Percentage of available RIPE address space announced:          79.2

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   35936
    Total LACNIC prefixes after maximum aggregation:               7912
    LACNIC Deaggregation factor:                                   4.54
Prefixes being announced from the LACNIC address blocks:          35352
    Unique aggregates announced from the LACNIC address blocks:   18553
LACNIC Region origin ASes present in the Internet Routing Table:   1545
    LACNIC Prefixes per ASN:                                      22.88
LACNIC Region origin ASes announcing only one prefix:               446
LACNIC Region transit ASes present in the Internet Routing Table:   281
Average LACNIC Region AS path length visible:                       4.5
    Max LACNIC Region AS path length visible:                        19
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   366
Number of LACNIC addresses announced to Internet:              92827520
    Equivalent to 5 /8s, 136 /16s and 111 /24s
    Percentage of available LACNIC address space announced:        61.5

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   8537
    Total AfriNIC prefixes after maximum aggregation:              2007
    AfriNIC Deaggregation factor:                                  4.25
Prefixes being announced from the AfriNIC address blocks:          6608
    Unique aggregates announced from the AfriNIC address blocks:   1974
AfriNIC Region origin ASes present in the Internet Routing Table:   491
    AfriNIC Prefixes per ASN:                                     13.46
AfriNIC Region origin ASes announcing only one prefix:              160
AfriNIC Region transit ASes present in the Internet Routing Table:  108
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    4
Number of AfriNIC addresses announced to Internet:             27570432
    Equivalent to 1 /8s, 164 /16s and 177 /24s
    Percentage of available AfriNIC address space announced:       41.1

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2514      11129         974   Korea Telecom (KIX)
17974     1630        511          36   PT TELEKOMUNIKASI INDONESIA
 7545     1614        303          87   TPG Internet Pty Ltd
 4755     1548        637         174   TATA Communications formerly 
 7552     1394       1064           7   Vietel Corporation
 9829     1166        989          28   BSNL National Internet Backbo
 9583     1092         80         500   Sify Limited
 4808     1090       2103         312   CNCGROUP IP network: China169
24560      964        343         218   Bharti Airtel Ltd., Telemedia
18101      954        135         150   Reliance Infocom Ltd Internet

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3547       3814         223   bellsouth.net, inc. 
 7029     2337       1016         198   Windstream Communications Inc
18566     2094        383         177   Covad Communications 
 1785     1844        680         122   PaeTec Communications, Inc.
 4323     1623       1078         389   Time Warner Telecom
20115     1596       1547         621   Charter Communications 
22773     1462       2907         100   Cox Communications, Inc.
30036     1402        254         671   Mediacom Communications Corp 
19262     1395       4728         400   Verizon Global Networks 
 7018     1317       7045         862   AT&T WorldNet Services

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1449        416          14   Corbina telecom
 6830      650       1927         414   UPC Distribution Services
34984      596        110         184   BILISIM TELEKOM
12479      545        628          51   Uni2 Autonomous System
20940      542        179         425   Akamai Technologies European 
 3320      507       8169         387   Deutsche Telekom AG
 3292      481       2074         406   TDC Tele Danmark
 8866      461        133          26   Bulgarian Telecommunication C
31148      406         22         114   FreeNet ISP
 8551      402        354          43   Bezeq International

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1699        314         156   TVCABLE BOGOTA 
28573     1479       1043          79   NET Servicos de Comunicao S.A
 8151     1430       2937         346   UniNet S.A. de C.V. 
 7303     1236        751         171   Telecom Argentina Stet-France
27947      591         72          84   Telconet S.A
22047      580        322          17   VTR PUNTO NET S.A. 
 6503      565        434          68   AVANTEL, S.A. 
 7738      553       1050          31   Telecomunicacoes da Bahia S.A
 3816      537        233          95   Empresa Nacional de Telecomun
11172      524         85          95   Servicios Alestra S.A de C.V 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
24863      801        146          36   LINKdotNET AS number
 8452      652        446          12   TEDATA
15475      443         74           8   Nile Online
36992      285        415          21   Etisalat MISR
 3741      281        939         230   The Internet Solution 
15706      240         32           6   Sudatel Internet Exchange Aut
33776      239         13           8   Starcomms Nigeria Limited
 6713      235        519          14   Itissalat Al-MAGHRIB
29571      218         17          13   Ci Telecom Autonomous system 
12258      196         28          57   Vodacom Internet Company 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3547       3814         223   bellsouth.net, inc. 
 4766     2514      11129         974   Korea Telecom (KIX)
 7029     2337       1016         198   Windstream Communications Inc
18566     2094        383         177   Covad Communications 
 1785     1844        680         122   PaeTec Communications, Inc.
10620     1699        314         156   TVCABLE BOGOTA 
17974     1630        511          36   PT TELEKOMUNIKASI INDONESIA
 4323     1623       1078         389   Time Warner Telecom
 7545     1614        303          87   TPG Internet Pty Ltd
20115     1596       1547         621   Charter Communications 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 7029      2337        2139      Windstream Communications Inc
18566      2094        1917      Covad Communications 
 1785      1844        1722      PaeTec Communications, Inc.
17974      1630        1594      PT TELEKOMUNIKASI INDONESIA
10620      1699        1543      TVCABLE BOGOTA 
 4766      2514        1540      Korea Telecom (KIX)
 7545      1614        1527      TPG Internet Pty Ltd
 8402      1449        1435      Corbina telecom
28573      1479        1400      NET Servicos de Comunicao S.A
 7552      1394        1387      Vietel Corporation

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23       10912       InterNAP Network Ser

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.0.0/16         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
24.225.128.0/18      36377     Comcast Telecommunications, I
24.225.192.0/23      36377     Comcast Telecommunications, I
24.225.192.0/18      36377     Comcast Telecommunications, I
24.225.224.0/21      36377     Comcast Telecommunications, I
24.225.237.0/24      36377     Comcast Telecommunications, I
24.225.248.0/21      36377     Comcast Telecommunications, I
41.222.79.0/24       36938     >>UNKNOWN<<
41.223.92.0/22       36936     >>UNKNOWN<<
62.61.220.0/24       24974     Tachyon Europe BV - Wireless 
62.61.221.0/24       24974     Tachyon Europe BV - Wireless 

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:19       /9:12      /10:27      /11:81      /12:236     
/13:465     /14:809     /15:1422    /16:12027   /17:6052    /18:10085   
/19:19946   /20:27559   /21:27705   /22:37171   /23:35262   /24:198635  
/25:1153    /26:1357    /27:761     /28:166     /29:4       /30:0       
/31:0       /32:5       

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 6389     2187          3547      bellsouth.net, inc. 
18566     2043          2094      Covad Communications 
 7029     2005          2337      Windstream Communications Inc
10620     1594          1699      TVCABLE BOGOTA 
 8402     1424          1449      Corbina telecom
30036     1363          1402      Mediacom Communications Corp 
11492     1117          1155      Cable One 
 1785     1057          1844      PaeTec Communications, Inc.
 7011     1051          1169      Citizens Utilities 
22773      950          1462      Cox Communications, Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:416       2:476       4:15        5:1         6:3         8:361    
  12:1955     13:1        14:541      15:11       16:3        17:7      
  20:9        23:58       24:1682     27:1024     31:673      32:65     
  33:2        34:2        36:4        38:758      40:110      41:2691   
  42:55       44:3        46:1025     47:3        49:299      50:443    
  52:13       55:6        56:2        57:47       58:902      59:497    
  60:361      61:1115     62:1086     63:1966     64:4057     65:2302   
  66:4278     67:2003     68:1163     69:3184     70:882      71:384    
  72:1802     74:2608     75:388      76:316      77:963      78:874    
  79:480      80:1131     81:844      82:520      83:528      84:619    
  85:1153     86:398      87:976      88:356      89:1593     90:235    
  91:4255     92:535      93:1536     94:1300     95:1088     96:428    
  97:286      98:936      99:37      101:225     103:432     106:70     
 107:84      108:72      109:1155    110:661     111:797     112:341    
 113:486     114:620     115:715     116:882     117:723     118:877    
 119:1265    120:344     121:695     122:1572    123:1007    124:1352   
 125:1355    128:245     129:189     130:164     131:627     132:148    
 133:21      134:221     135:54      136:212     137:142     138:286    
 139:122     140:489     141:317     142:389     143:410     144:491    
 145:64      146:465     147:220     148:641     149:267     150:169    
 151:194     152:447     153:178     154:7       155:385     156:208    
 157:361     158:155     159:485     160:333     161:214     162:371    
 163:173     164:511     165:369     166:540     167:439     168:820    
 169:145     170:880     171:86      172:4       173:1708    174:679    
 175:417     176:278     177:369     178:1082    180:1139    181:38     
 182:653     183:221     184:387     185:1       186:1328    187:764    
 188:1061    189:1147    190:5167    192:5931    193:5050    194:3558   
 195:3112    196:1265    197:167     198:3629    199:4175    200:5513   
 201:1695    202:8573    203:8478    204:4315    205:2370    206:2674   
 207:2820    208:4037    209:3580    210:2720    211:1457    212:2083   
 213:1780    214:813     215:95      216:4918    217:1603    218:564    
 219:342     220:1254    221:517     222:322     223:269    

End of report


From michael.rocco.sabino at gmail.com  Fri Nov  4 15:39:43 2011
From: michael.rocco.sabino at gmail.com (Michael Sabino)
Date: Fri, 4 Nov 2011 15:39:43 -0500
Subject: Route server: Route-server.ip.att.net
Message-ID: <CAH85JoEwqAqWktqu=UXygNhugSPDz51ttyuT=cZbJKsXhaBVVg@mail.gmail.com>

Hi,

Could you give me the relevant configs explaining why when I traceroute to
12.83.43.9 on route-server.ip.att.net, the first hop is "
j6300.cbbtier3.att.net (12.0.1.202)". However, when I type "show ip route
12.83.43.9", the RIB shows, "* 12.122.83.91, from 12.122.83.91, 7w0d ago".

I asked someone who is knowledgeable about the matter, and he seems to
think that you can change the interface which sends back ICMP unreachables,
but I don't know how to do this on my own simulated equipment.

Also, I have noticed that when I traceroute to any ip address on the
internet from my home connection, the last hop that's in common with all
traceroutes is 12.83.43.9. This is a hop after several hops which seem to
be filtered. What is the purpose of this IP?

Are there any publically available documentation that would help me
understand the process of aggregating multiple DSLAMs, etc on my at&t
u-verse connection?

I am a CCNA/CCNP student in college and this would help me understand WANs
better.


Thanks

Michael R. Sabino
michael.rocco.sabino at gmail.com

From keegan.holley at sungard.com  Fri Nov  4 15:46:03 2011
From: keegan.holley at sungard.com (Keegan Holley)
Date: Fri, 4 Nov 2011 16:46:03 -0400
Subject: Route server: Route-server.ip.att.net
In-Reply-To: <CAH85JoEwqAqWktqu=UXygNhugSPDz51ttyuT=cZbJKsXhaBVVg@mail.gmail.com>
References: <CAH85JoEwqAqWktqu=UXygNhugSPDz51ttyuT=cZbJKsXhaBVVg@mail.gmail.com>
Message-ID: <CABO8Q6QYbahoppyvS44Z8SQ6QDO_VUDyyXHUZ63amxGTpKcDYg@mail.gmail.com>

Did you do a show ip route for 12.122.83.91?  It's probably a loopback of
the nearest BGP peer it may not be the actual next hop interface IP
though.  Not sure about the blocked hops, but I can think of a few
explanations.  Overall the point of that router is to provide a view of the
route table and not the physical hops from one point to another.  Since
actual customer traffic wouldn't flow through the route server the first
few hops are probably irrelevant.

2011/11/4 Michael Sabino <michael.rocco.sabino at gmail.com>

> Hi,
>
> Could you give me the relevant configs explaining why when I traceroute to
> 12.83.43.9 on route-server.ip.att.net, the first hop is "
> j6300.cbbtier3.att.net (12.0.1.202)". However, when I type "show ip route
> 12.83.43.9", the RIB shows, "* 12.122.83.91, from 12.122.83.91, 7w0d ago".
>
> I asked someone who is knowledgeable about the matter, and he seems to
> think that you can change the interface which sends back ICMP unreachables,
> but I don't know how to do this on my own simulated equipment.
>
> Also, I have noticed that when I traceroute to any ip address on the
> internet from my home connection, the last hop that's in common with all
> traceroutes is 12.83.43.9. This is a hop after several hops which seem to
> be filtered. What is the purpose of this IP?
>
> Are there any publically available documentation that would help me
> understand the process of aggregating multiple DSLAMs, etc on my at&t
> u-verse connection?
>
> I am a CCNA/CCNP student in college and this would help me understand WANs
> better.
>
>
> Thanks
>
> Michael R. Sabino
> michael.rocco.sabino at gmail.com
>
>

From prox at prolixium.com  Fri Nov  4 15:59:22 2011
From: prox at prolixium.com (Mark Kamichoff)
Date: Fri, 4 Nov 2011 16:59:22 -0400
Subject: Route server: Route-server.ip.att.net
In-Reply-To: <CAH85JoEwqAqWktqu=UXygNhugSPDz51ttyuT=cZbJKsXhaBVVg@mail.gmail.com>
References: <CAH85JoEwqAqWktqu=UXygNhugSPDz51ttyuT=cZbJKsXhaBVVg@mail.gmail.com>
Message-ID: <20111104205922.GA27068@prolixium.com>

On Fri, Nov 04, 2011 at 03:39:43PM -0500, Michael Sabino wrote:
> Could you give me the relevant configs explaining why when I
> traceroute to 12.83.43.9 on route-server.ip.att.net, the first hop is
> " j6300.cbbtier3.att.net (12.0.1.202)". However, when I type "show ip
> route 12.83.43.9", the RIB shows, "* 12.122.83.91, from 12.122.83.91,
> 7w0d ago".

A couple things here:

12.122.83.91 is the BGP next-hop in the RIB.  It needs to be resolved.
In this case it's being resolved via a /13 static route:

route-server>sho ip route 12.122.83.91
Routing entry for 12.120.0.0/13
  Known via "static", distance 1, metric 0
  Redistributing via bgp 65000
  Advertised by bgp 65000
  Routing Descriptor Blocks:
  * 12.0.1.1, via GigabitEthernet0/1
      Route metric is 0, traffic share count is 1

In real life it'd probably be resolved via an IGP such as OSPF or IS-IS,
but this is a route server, not a transit router.

So, the real next-hop is 12.0.1.1.  You can also verify this with the
following, since it's a Cisco box:

route-server>show ip cef 12.83.43.9  
12.0.0.0/9
  nexthop 12.0.1.1 GigabitEthernet0/1

However, you don't see 12.0.1.1 in the traceroute because it looks to be
the VRRP address of the Juniper J6300 upstream router (just judging by
the hostname):

route-server>sho arp 12.0.1.1
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  12.0.1.1               81   0000.5e00.0101  ARPA
GigabitEthernet0/1

The MAC address is a giveaway that it's VRRP, since 00-00-5E-00-01 is
reserved by IANA for VRRP (IPv4 only):

http://tools.ietf.org/html/rfc5798#section-7.3

The Juniper router will send back ICMP TTL-exceeded messages from the
real IP on its interface, which appears to be 12.0.1.202.

Hope this helps.

- Mark

-- 
Mark Kamichoff
prox at prolixium.com
http://www.prolixium.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111104/b9cf831e/attachment.bin>

From james at freedomnet.co.nz  Fri Nov  4 16:21:41 2011
From: james at freedomnet.co.nz (James Jones)
Date: Fri, 4 Nov 2011 17:21:41 -0400
Subject: TR-69 and linux
Message-ID: <CAE05tD+_KeBODoOb5fYdsH+p6hxUU5bHoLfQnc8N4z57OQmPhw@mail.gmail.com>

Does anyone know of a open TR-69 implementation for linux? Also to take it
one step further, does anyone of one that works in tandem with a web gui
like openwrt?

From cidr-report at potaroo.net  Fri Nov  4 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 4 Nov 2011 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201111042200.pA4M00Ck057405@wattle.apnic.net>

BGP Update Report
Interval: 27-Oct-11 -to- 03-Nov-11 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9829            33708  2.2%      55.3 -- BSNL-NIB National Internet Backbone
 2 - AS8402            32620  2.1%      27.4 -- CORBINA-AS OJSC "Vimpelcom"
 3 - AS14420           25170  1.6%      53.4 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP
 4 - AS32528           23722  1.6%    4744.4 -- ABBOTT Abbot Labs
 5 - AS38040           22818  1.5%    1629.9 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
 6 - AS5800            19466  1.3%      79.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 7 - AS9498            16593  1.1%      42.9 -- BBIL-AP BHARTI Airtel Ltd.
 8 - AS4274            14284  0.9%     187.9 -- ERX-AU-NET Assumption University
 9 - AS16916           12491  0.8%   12491.0 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC
10 - AS7552            11981  0.8%       8.8 -- VIETEL-AS-AP Vietel Corporation
11 - AS3475            11876  0.8%     152.3 -- DNIC-AS-03475 - Navy Network Information Center (NNIC)
12 - AS30890           11312  0.7%      31.6 -- EVOLVA EUROLAN SOLUTIONS SRL
13 - AS26615           11293  0.7%      32.3 -- Tim Celular S.A.
14 - AS8866            11264  0.7%     352.0 -- BTC-AS Bulgarian Telecommunication Company Plc.
15 - AS17974           11092  0.7%       7.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
16 - AS16010           10735  0.7%      86.6 -- RUSTAVI2ONLINEAS Caucasus Online LLC
17 - AS45514           10244  0.7%      34.1 -- TELEMEDIA-SMB-AS-AP Bharti Airtel Ltd., TELEMEDIA Services, for SMB customers
18 - AS3352            10129  0.7%       4.9 -- TELEFONICA-DATA-ESPANA TELEFONICA DE ESPANA
19 - AS7029             9950  0.7%       7.3 -- WINDSTREAM - Windstream Communications Inc
20 - AS45595            9764  0.6%      41.2 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS16916           12491  0.8%   12491.0 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC
 2 - AS57090            4891  0.3%    4891.0 -- SNSREAAL SNS REAAL N.V.
 3 - AS32528           23722  1.6%    4744.4 -- ABBOTT Abbot Labs
 4 - AS17408            3137  0.2%    3137.0 -- ABOVE-AS-AP AboveNet Communications Taiwan
 5 - AS38040           22818  1.5%    1629.9 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
 6 - AS9562             9496  0.6%    1356.6 -- MSU-TH-AP Mahasarakham University
 7 - AS22042            1311  0.1%    1311.0 -- FLOWUSLLC - Flow Traders US LLC
 8 - AS17425            4774  0.3%    1193.5 -- EPA-AS-TH Provincial Electricity Authority of Thailand.
 9 - AS47528            1140  0.1%    1140.0 -- INTELECOM-AS Intelecom Group ASA
10 - AS21789            4335  0.3%    1083.8 -- 168-244 - Lowe's Companies, Inc.
11 - AS55696            1016  0.1%    1016.0 -- SCOM-AS-ID Starcom Solusindo PT.
12 - AS25429            6413  0.4%     916.1 -- CBI-AS CBINET, Bujumbura, Burundi.
13 - AS56939             713  0.1%     713.0 -- CREDOS Credo-S Ltd.
14 - AS45615             693  0.1%     693.0 -- NRW NRW Holdings Limited
15 - AS45771             601  0.0%     601.0 -- WESTLINK-PH TELERURAL COMMUNICATION MANAGEMENT INC.
16 - AS46983             599  0.0%     599.0 -- SAML-ASN - Southpaw Asset Management LP
17 - AS6072             7420  0.5%     530.0 -- UNISYS-6072 For routing issues, email hostmaster at unisys.com
18 - AS10445            1796  0.1%     449.0 -- HTG - Huntleigh Telcom
19 - AS29356             419  0.0%     419.0 -- NESTLE Nestle Switzerland
20 - AS43389             396  0.0%     396.0 -- EULOGOS EULOGOS SPA


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 202.92.235.0/24   14325  0.9%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 2 - 206.80.93.0/24    12491  0.8%   AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC
 3 - 130.36.34.0/24    11856  0.7%   AS32528 -- ABBOTT Abbot Labs
 4 - 130.36.35.0/24    11856  0.7%   AS32528 -- ABBOTT Abbot Labs
 5 - 213.16.48.0/24    11076  0.7%   AS8866  -- BTC-AS Bulgarian Telecommunication Company Plc.
 6 - 196.2.14.0/24      5688  0.3%   AS25429 -- CBI-AS CBINET, Bujumbura, Burundi.
 7 - 194.53.211.0/24    4891  0.3%   AS57090 -- SNSREAAL SNS REAAL N.V.
 8 - 180.180.248.0/24   4762  0.3%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
 9 - 180.180.253.0/24   4762  0.3%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
10 - 180.180.250.0/24   4760  0.3%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
11 - 180.180.249.0/24   4561  0.3%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
12 - 84.204.132.0/24    4499  0.3%   AS20632 -- PETERSTAR-AS PeterStar
13 - 180.180.255.0/24   3829  0.2%   AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited
14 - 202.41.70.0/24     3515  0.2%   AS2697  -- ERX-ERNET-AS Education and Research Network
15 - 202.171.192.0/20   3239  0.2%   AS4788  -- TMNET-AS-AP TM Net, Internet Service Provider
16 - 202.153.174.0/24   3137  0.2%   AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan
17 - 221.183.16.0/23    3072  0.2%   AS65500 -- -Private Use AS-
                                     AS9808  -- CMNET-GD Guangdong Mobile Communication Co.Ltd.
18 - 202.93.40.0/24     2624  0.2%   AS4761  -- INDOSAT-INP-AP INDOSAT Internet Network Provider
19 - 202.151.6.0/24     2378  0.1%   AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand.
20 - 202.151.7.0/24     2378  0.1%   AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand.

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Nov  4 17:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 4 Nov 2011 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201111042200.pA4M00Rj057400@wattle.apnic.net>

This report has been generated at Fri Nov  4 21:12:12 2011 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        28-10-11    381389      224100
        29-10-11    381588      224071
        30-10-11    381765      223954
        31-10-11    381720      223778
        01-11-11    382078      223922
        02-11-11    382192      224106
        03-11-11    382733      224459
        04-11-11    382870      224689


AS Summary
         39319  Number of ASes in routing system
         16583  Number of ASes announcing only one prefix
          3547  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      108768256  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 04Nov11 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     383194   224787   158407    41.3%   All ASes

AS6389      3547      226     3321    93.6%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS18566     2094      406     1688    80.6%   COVAD - Covad Communications
                                               Co.
AS4766      2514      993     1521    60.5%   KIXS-AS-KR Korea Telecom
AS22773     1462      110     1352    92.5%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4755      1544      231     1313    85.0%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS4323      1624      391     1233    75.9%   TWTC - tw telecom holdings,
                                               inc.
AS1785      1847      786     1061    57.4%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS28573     1481      425     1056    71.3%   NET Servicos de Comunicao S.A.
AS19262     1395      400      995    71.3%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS10620     1699      710      989    58.2%   Telmex Colombia S.A.
AS7552      1394      424      970    69.6%   VIETEL-AS-AP Vietel
                                               Corporation
AS7303      1236      331      905    73.2%   Telecom Argentina S.A.
AS8402      1441      612      829    57.5%   CORBINA-AS OJSC "Vimpelcom"
AS18101      955      151      804    84.2%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS7029      2378     1591      787    33.1%   WINDSTREAM - Windstream
                                               Communications Inc
AS4808      1090      344      746    68.4%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS8151      1432      690      742    51.8%   Uninet S.A. de C.V.
AS30036     1402      676      726    51.8%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS7545      1614      944      670    41.5%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS3356      1116      463      653    58.5%   LEVEL3 Level 3 Communications
AS24560      964      336      628    65.1%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS4804       705       95      610    86.5%   MPX-AS Microplex PTY LTD
AS17676      678       70      608    89.7%   GIGAINFRA Softbank BB Corp.
AS20115     1596      992      604    37.8%   CHARTER-NET-HKY-NC - Charter
                                               Communications
AS17974     1629     1048      581    35.7%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS3549      1022      453      569    55.7%   GBLX Global Crossing Ltd.
AS22561      932      372      560    60.1%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS22047      580       33      547    94.3%   VTR BANDA ANCHA S.A.
AS17488      943      411      532    56.4%   HATHWAY-NET-AP Hathway IP Over
                                               Cable Internet
AS7011      1169      646      523    44.7%   FRONTIER-AND-CITIZENS -
                                               Frontier Communications of
                                               America, Inc.

Total      43483    15360    28123    64.7%   Top 30 total


Possible Bogus Routes

        5.0.0.0/16           AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        5.1.0.0/21           AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        5.1.24.0/24          AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        41.222.79.0/24       AS37345 MEDALLION
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.171.32.0/20       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.206.47.0/24       AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        69.6.80.0/24         AS13442 
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        80.88.10.0/24        AS33774 DJAWEB
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.45.1.0/24        AS29571 CITelecom-AS
        172.45.2.0/24        AS29571 CITelecom-AS
        172.45.3.0/24        AS29571 CITelecom-AS
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        185.0.0.0/16         AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        185.1.0.0/21         AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        185.24.0.0/24        AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS26061 Equant Colombia
        200.24.78.0/26       AS3549  GBLX Global Crossing Ltd.
        200.24.78.64/26      AS3549  GBLX Global Crossing Ltd.
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.74.232.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.74.233.0/24      AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.131.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        202.179.144.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        203.175.107.0/24     AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A.
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - Knology Holdings
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc.
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc.
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        208.64.240.0/21      AS13871 TELEBYTE-NW - Telebyte NW
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cb.list6 at gmail.com  Fri Nov  4 17:04:10 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Fri, 4 Nov 2011 15:04:10 -0700
Subject: IPv6 beta support for Android phones
Message-ID: <CAD6AjGQAU28=hnBJNmc1jPCQi907L26MbnhvUnJ69K6CHo=mKw@mail.gmail.com>

FYI.

T-Mobile USA now has opt-in beta support for an Android phone on IPv6,
more info here https://sites.google.com/site/tmoipv6/lg-mytouch

As far as i know, this is the first Android phone that support IPv6 on
the GSM/UMTS mobile interface.  Previous version of Android phones
supported IPv6 on WiFi and LTE.

Cameron


From pete at altadena.net  Fri Nov  4 18:45:44 2011
From: pete at altadena.net (Pete Carah)
Date: Fri, 04 Nov 2011 19:45:44 -0400
Subject: IPv6 beta support for Android phones
In-Reply-To: <CAD6AjGQAU28=hnBJNmc1jPCQi907L26MbnhvUnJ69K6CHo=mKw@mail.gmail.com>
References: <CAD6AjGQAU28=hnBJNmc1jPCQi907L26MbnhvUnJ69K6CHo=mKw@mail.gmail.com>
Message-ID: <4EB47928.3030503@altadena.net>

On 11/04/2011 06:04 PM, Cameron Byrne wrote:
> FYI.
>
> T-Mobile USA now has opt-in beta support for an Android phone on IPv6,
> more info here https://sites.google.com/site/tmoipv6/lg-mytouch
Very good.
>
> As far as i know, this is the first Android phone that support IPv6 on
> the GSM/UMTS mobile interface.  Previous version of Android phones
> supported IPv6 on WiFi and LTE.
My iPhone (old 3G, 4.2.1) supports v6 on wifi (I can see it at the other
end of connections; the
UI status page refuses to admit to ipv6 though.)  It appears to use only
eui64 addresses and not
privacy ones (this from perusing web and mail logs at the server end).

I don't know about any other medium since as far as I can see, AT&T's
network doesn't (yet)
support v6 on umts or gsm/edge :-(

-- Pete




From joelja at bogus.com  Fri Nov  4 19:00:10 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Fri, 4 Nov 2011 17:00:10 -0700
Subject: IPv6 beta support for Android phones
In-Reply-To: <4EB47928.3030503@altadena.net>
References: <CAD6AjGQAU28=hnBJNmc1jPCQi907L26MbnhvUnJ69K6CHo=mKw@mail.gmail.com>
 <4EB47928.3030503@altadena.net>
Message-ID: <1D420F82-B75C-437F-A0BE-4DAF004B45A6@bogus.com>

The cellular radios firmware doesn't support ipv6(on your iPhone)...

Sent from my iPhone

On Nov 4, 2011, at 4:45 PM, Pete Carah <pete at altadena.net> wrote:

> On 11/04/2011 06:04 PM, Cameron Byrne wrote:
>> FYI.
>> 
>> T-Mobile USA now has opt-in beta support for an Android phone on IPv6,
>> more info here https://sites.google.com/site/tmoipv6/lg-mytouch
> Very good.
>> 
>> As far as i know, this is the first Android phone that support IPv6 on
>> the GSM/UMTS mobile interface.  Previous version of Android phones
>> supported IPv6 on WiFi and LTE.
> My iPhone (old 3G, 4.2.1) supports v6 on wifi (I can see it at the other
> end of connections; the
> UI status page refuses to admit to ipv6 though.)  It appears to use only
> eui64 addresses and not
> privacy ones (this from perusing web and mail logs at the server end).
> 
> I don't know about any other medium since as far as I can see, AT&T's
> network doesn't (yet)
> support v6 on umts or gsm/edge :-(
> 
> -- Pete
> 
> 
> 


From mysidia at gmail.com  Fri Nov  4 19:26:02 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 4 Nov 2011 19:26:02 -0500
Subject: Performance Issues - PTR Records
In-Reply-To: <20111104162814.24EFAC0DC81@fafnir.remote.dragon.net>
References: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
 <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net>
 <CAJAdsDkGc2CYfa=CDuCDSoFw1xVQ0TKz4B_MAPqBbFgFsyPnRQ@mail.gmail.com>
 <20111104162814.24EFAC0DC81@fafnir.remote.dragon.net>
Message-ID: <CAAAwwbW7Hm5M4Y9AfmUgAz0oKEzaqxZRYJbzUbLhQCJxgwA7eg@mail.gmail.com>

On Fri, Nov 4, 2011 at 11:28 AM, Paul Ebersman <list-nanog2 at dragon.net> wrote:
> It's already been pointed out that lame delegations are more likely
> problems for many. But the "we'll just pre-fill in-addr to avoid
> problems" isn't going to work for ip6.arpa. If anyone has enough
> hardware to serve the zone for a /48 (64k * 4bil * 4bil *
> bytes-in-record), I'd love to see it. :)
[snip]
I can serve the zone for a /48   by creating a "sparse" zone.
That is... when you ask my  DNS server what such and such PTR reverses too,
what I don't have a DNS entry for, it can tell you something generic.

There is no need for me to physically create  64k*4bil*4bil  on a disk
or memory area
somewhere.    I can make a plugin for my DNS server to hand you the
generic result
when you ask my DNS server what something reverses to...

That is, I can serve you an ephemeral record without requiring an
extra byte of storage beyond
the life of your query :)

--
-JH


From jbates at brightok.net  Fri Nov  4 19:37:37 2011
From: jbates at brightok.net (Jack Bates)
Date: Fri, 04 Nov 2011 19:37:37 -0500
Subject: MPLS TE
In-Reply-To: <CAB_zYdJ_KvJZMmz_ifeWr479fwkjf8j69LaOCmQ6DjqZVEH0qQ@mail.gmail.com>
References: <CAB_zYdKv0v13-8eezR8VRwCJ=Myxh2prvr-odW-X-U6Lp027kQ@mail.gmail.com>
 <D51498F0B6E1EF408AC4D63440BFD6F8BB1C995B9D@skbramsx02.emea.att.com>
 <CAB_zYdJ_KvJZMmz_ifeWr479fwkjf8j69LaOCmQ6DjqZVEH0qQ@mail.gmail.com>
Message-ID: <4EB48551.1070200@brightok.net>

On 11/4/2011 12:00 PM, harbor235 wrote:
> I am also looking at FRR which uses a backup tunnel for fast convergence. I
> did however not think
> about the dynamic nature of the tunnel and the potential for
> reestablishment.
>
>
Even with primary/secondary paths, the secondary path will normally not 
get used if the primary can resignal to a different path. 
Implementations can get very vendor specific. Each vendor supports 
different subsets of the necessary protocols. I just had a single vendor 
network, that due to lack of SRLG support in their lower end boxes (and 
lack of admin-group in FRR) required setting facility based FRR with 
many bypasses (which luckily they did support at all levels and the 
manual bypasses did support admin-groups for setup).

The only time I usually use dual LSPs is to support load balancing 
across multiple circuits where vendor support is limited (1 LSP down 
each pipe, IGP balance between them, each LSP has secondary path on 
opposite pipe). The idea of MPLS is that the LSP should NOT be down. A 
path might go down and FRR/secondy paths might come into play, but the 
LSP itself should still be handling traffic. Even in complicated QOS 
setups, you can have primary, and multiple secondaries to allow stepdown 
of what a circuit should be reserving, and priorities to even preempt 
circuits to lower class of service (imagine a secondary trying for what 
it currently has without preemption, but then that failing, sets 
different requirements and preempts lesser circuits).

In simpler topologies where I don't need TE and I just want FRR, I've 
been playing with Juniper's LFA implementation. One of my current plans 
is using RSVP/FRR for mpls only services and using LFA for global 
routing. It works for my specific layout, and the only annoyance is 
setting BGP next-hops correctly.


Jack


From jack at bonyari.com  Fri Nov  4 20:31:14 2011
From: jack at bonyari.com (Jack Morgan)
Date: Fri, 04 Nov 2011 18:31:14 -0700
Subject: TR-69 and linux
In-Reply-To: <CAE05tD+_KeBODoOb5fYdsH+p6hxUU5bHoLfQnc8N4z57OQmPhw@mail.gmail.com>
References: <CAE05tD+_KeBODoOb5fYdsH+p6hxUU5bHoLfQnc8N4z57OQmPhw@mail.gmail.com>
Message-ID: <4EB491E2.405@bonyari.com>

On 11/04/2011 02:21 PM, James Jones wrote:
> Does anyone know of a open TR-69 implementation for linux? Also to take it
> one step further, does anyone of one that works in tandem with a web gui
> like openwrt?

This companies product is based off of TR-69 running on a Linux device
to a web gui applicaiton.


http://www.clearaccess.com/

-- 
Jack Morgan
Pub 4096R/761D8E0A 2010-09-13 Jack Morgan <jack at bonayri.com>
Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111104/00dda95c/attachment.bin>

From list-nanog2 at dragon.net  Fri Nov  4 21:44:42 2011
From: list-nanog2 at dragon.net (Paul Ebersman)
Date: Fri, 04 Nov 2011 19:44:42 -0700
Subject: Performance Issues - PTR Records
In-Reply-To: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org>
References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org>
Message-ID: <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net>


tim> If PTR exists in zone file, serve it.  Else, synthesize generic
tim> reverse.  Jobsagoodun.

If all we're doing is lying with some generic answer that we hack our
server to produce, why are we bothering?

At that point, you're not proving clue. You're proving you at least
bought a solution from someone with a clue...

My contention is that (at least for end hosts), PTR records are mostly
pointless and just overhead for DNS servers.


From jra at baylink.com  Fri Nov  4 21:57:33 2011
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 4 Nov 2011 22:57:33 -0400 (EDT)
Subject: Performance Issues - PTR Records
In-Reply-To: <CAAAwwbW7Hm5M4Y9AfmUgAz0oKEzaqxZRYJbzUbLhQCJxgwA7eg@mail.gmail.com>
Message-ID: <9655164.1668.1320461853541.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jimmy Hess" <mysidia at gmail.com>

> There is no need for me to physically create 64k*4bil*4bil on a disk or memory area
> somewhere. I can make a plugin for my DNS server to hand you the generic result
> when you ask my DNS server what something reverses to...
> 
> That is, I can serve you an ephemeral record without requiring an
> extra byte of storage beyond the life of your query :)

This is precisely the approach taken by the DNS server package written by 
the tech folks at the late, lamented MindSpring -- the name of which eludes
me for the moment.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From gary.steers at sharedband.com  Sat Nov  5 04:45:42 2011
From: gary.steers at sharedband.com (Gary Steers)
Date: Sat, 5 Nov 2011 09:45:42 -0000
Subject: Severe Packet loss
Message-ID: <CF4687332659244DA0C2D1F53AFF9F83834F14@sb-server-sbs.SharedComUK.local>

Hi Guys,

 

Is anyone else having major issue's tonight/this morning?

 

We our having issue's and our upstream provider is reporting route
flaps, the say its affecting quite a few networks but just checking if
anyone else is having issue's???

 

Gary


From tknchris at gmail.com  Sat Nov  5 08:31:33 2011
From: tknchris at gmail.com (chris)
Date: Sat, 5 Nov 2011 09:31:33 -0400
Subject: Severe Packet loss
In-Reply-To: <CF4687332659244DA0C2D1F53AFF9F83834F14@sb-server-sbs.SharedComUK.local>
References: <CF4687332659244DA0C2D1F53AFF9F83834F14@sb-server-sbs.SharedComUK.local>
Message-ID: <CAKnNFz8JKr8uXm5jHNEY6C4HU+4_EDyHZwYGas7e4k1z85CyKA@mail.gmail.com>

quite a bit of information you have there

anyone else think the internet is a little flaky today? *facepalm*

On Sat, Nov 5, 2011 at 5:45 AM, Gary Steers <gary.steers at sharedband.com>wrote:

> Hi Guys,
>
>
>
> Is anyone else having major issue's tonight/this morning?
>
>
>
> We our having issue's and our upstream provider is reporting route
> flaps, the say its affecting quite a few networks but just checking if
> anyone else is having issue's???
>
>
>
> Gary
>
>

From blake at pfankuch.me  Sat Nov  5 10:53:56 2011
From: blake at pfankuch.me (Blake T. Pfankuch)
Date: Sat, 5 Nov 2011 15:53:56 +0000
Subject: Severe Packet loss
In-Reply-To: <CF4687332659244DA0C2D1F53AFF9F83834F14@sb-server-sbs.SharedComUK.local>
References: <CF4687332659244DA0C2D1F53AFF9F83834F14@sb-server-sbs.SharedComUK.local>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C846D95028D@SHSBS.shenrons-house.local>

Understanding this is a little vague, I can say that I did see "weirdness" in connectivity from a datacenter in Seattle to LA, Dallas to LA and Amazon West US to Dallas, and Denver to Seattle about 2am to 3am MDT.  If you could provide what carriers you are on, maybe we can compare notes?

-----Original Message-----
From: Gary Steers [mailto:gary.steers at sharedband.com] 
Sent: Saturday, November 05, 2011 3:46 AM
To: nanog at nanog.org
Subject: Severe Packet loss

Hi Guys,

 

Is anyone else having major issue's tonight/this morning?

 

We our having issue's and our upstream provider is reporting route flaps, the say its affecting quite a few networks but just checking if anyone else is having issue's???

 

Gary



From randy at psg.com  Sat Nov  5 11:38:51 2011
From: randy at psg.com (Randy Bush)
Date: Sat, 05 Nov 2011 17:38:51 +0100
Subject: Severe Packet loss
In-Reply-To: <CF4687332659244DA0C2D1F53AFF9F83834F14@sb-server-sbs.SharedComUK.local>
References: <CF4687332659244DA0C2D1F53AFF9F83834F14@sb-server-sbs.SharedComUK.local>
Message-ID: <m28vnu1q3o.wl%randy@psg.com>

> Is anyone else having major issue's tonight/this morning?
> 
> We our having issue's and our upstream provider is reporting route
> flaps, the say its affecting quite a few networks but just checking if
> anyone else is having issue's???

"The internet is broken"

"Yes dear.  Care to tell me which part?"


From streiner at cluebyfour.org  Sat Nov  5 12:26:10 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Sat, 5 Nov 2011 13:26:10 -0400 (EDT)
Subject: Severe Packet loss
In-Reply-To: <CF4687332659244DA0C2D1F53AFF9F83834F14@sb-server-sbs.SharedComUK.local>
References: <CF4687332659244DA0C2D1F53AFF9F83834F14@sb-server-sbs.SharedComUK.local>
Message-ID: <Pine.LNX.4.64.1111051315310.29090@whammy.cluebyfour.org>

On Sat, 5 Nov 2011, Gary Steers wrote:

> Is anyone else having major issue's tonight/this morning?
>
> We our having issue's and our upstream provider is reporting route
> flaps, the say its affecting quite a few networks but just checking if
> anyone else is having issue's???

You'll generally get more helpful responses from NANOG and other forums if 
you provide more detail than "major issue's[sic]" and "route flaps". 
People will be more inclined to help or offer suggestions if you provide 
details and have done some research into the problem already.

For example:
What major issues were you seeing?  Can those issues be defined with 
traceroutes, snapshots of BGP route views, reproducible difficulties in 
reaching a particular site, etc?  What other carriers were reporting 
problems?  Can you provide a source and destination address that is having 
connectivity issues?

When you say "our upstream provider", are you single-homed or 
multi-homed?

Speaking from my own little corner of the world, I haven't seen any major 
connectivity problems here in the past 24 hours.

jms


From w3yni1 at gmail.com  Sat Nov  5 13:05:50 2011
From: w3yni1 at gmail.com (Charles Mills)
Date: Sat, 5 Nov 2011 14:05:50 -0400
Subject: Severe Packet loss
In-Reply-To: <Pine.LNX.4.64.1111051315310.29090@whammy.cluebyfour.org>
References: <CF4687332659244DA0C2D1F53AFF9F83834F14@sb-server-sbs.SharedComUK.local>
 <Pine.LNX.4.64.1111051315310.29090@whammy.cluebyfour.org>
Message-ID: <CAOF0KO9BbFws68693GBBwFKbi9zRtoMCWkEYnZUfsUSWvKad-A@mail.gmail.com>

Cogent had some planned maintenance during the 2-4a timeframe.

Furthermore there was some sluggishness and packet loss for some of my
customers that *seemed* to be centered around Ashburn, VA around 9-9:30 but
cleared up before I could get a good look at it or even before where it was
situated.


Chuck

On Sat, Nov 5, 2011 at 1:26 PM, Justin M. Streiner
<streiner at cluebyfour.org>wrote:

> On Sat, 5 Nov 2011, Gary Steers wrote:
>
>  Is anyone else having major issue's tonight/this morning?
>>
>> We our having issue's and our upstream provider is reporting route
>> flaps, the say its affecting quite a few networks but just checking if
>> anyone else is having issue's???
>>
>
> You'll generally get more helpful responses from NANOG and other forums if
> you provide more detail than "major issue's[sic]" and "route flaps". People
> will be more inclined to help or offer suggestions if you provide details
> and have done some research into the problem already.
>
> For example:
> What major issues were you seeing?  Can those issues be defined with
> traceroutes, snapshots of BGP route views, reproducible difficulties in
> reaching a particular site, etc?  What other carriers were reporting
> problems?  Can you provide a source and destination address that is having
> connectivity issues?
>
> When you say "our upstream provider", are you single-homed or multi-homed?
>
> Speaking from my own little corner of the world, I haven't seen any major
> connectivity problems here in the past 24 hours.
>
> jms
>
>

From tom at ninjabadger.net  Sun Nov  6 09:50:08 2011
From: tom at ninjabadger.net (Tom Hill)
Date: Sun, 06 Nov 2011 15:50:08 +0000
Subject: Severe Packet loss
In-Reply-To: <m28vnu1q3o.wl%randy@psg.com>
References: <CF4687332659244DA0C2D1F53AFF9F83834F14@sb-server-sbs.SharedComUK.local>
 <m28vnu1q3o.wl%randy@psg.com>
Message-ID: <1320594608.6199.3.camel@teh-desktop>

On Sat, 2011-11-05 at 17:38 +0100, Randy Bush wrote:
> "The internet is broken"
> 
> "Yes dear.  Care to tell me which part?" 

Was it just the bias of my nationality that prompted me to repeat this
out-loud with a posh, British accent? :)

Tom



From tom at ninjabadger.net  Sun Nov  6 10:32:57 2011
From: tom at ninjabadger.net (Tom Hill)
Date: Sun, 06 Nov 2011 16:32:57 +0000
Subject: IPv6 beta support for Android phones
In-Reply-To: <CAD6AjGQAU28=hnBJNmc1jPCQi907L26MbnhvUnJ69K6CHo=mKw@mail.gmail.com>
References: <CAD6AjGQAU28=hnBJNmc1jPCQi907L26MbnhvUnJ69K6CHo=mKw@mail.gmail.com>
Message-ID: <1320597177.6199.8.camel@teh-desktop>

On Fri, 2011-11-04 at 15:04 -0700, Cameron Byrne wrote:
> FYI.
> 
> T-Mobile USA now has opt-in beta support for an Android phone on IPv6,
> more info here https://sites.google.com/site/tmoipv6/lg-mytouch

Very, very good. I hope T-Mobile UK (and elsewhere in the world) take
heed. 

I have to wonder why they've chosen to go with IPv6-only & DNS/NAT64
instead of a dual-stack approach. Is there a particular restriction that
prevents this?

> As far as i know, this is the first Android phone that support IPv6 on
> the GSM/UMTS mobile interface.  Previous version of Android phones
> supported IPv6 on WiFi and LTE.

Indeed, the 'Network Info II' application will show you the IPv6
addresses gained on WiFi interfaces (if anyone's interested). My Galaxy
S (unlocked/orig.) does this very well.

I wonder if it's possible to provide IPv6 support for UMTS/GSM via
firmware and/or software updates from Samsung?

Tom



From lbstreamer at gmail.com  Sun Nov  6 12:01:24 2011
From: lbstreamer at gmail.com (Louis P)
Date: Sun, 06 Nov 2011 19:01:24 +0100
Subject: Historical records of IP allocations
Message-ID: <4EB6CB74.6060003@gmail.com>

Hello,
Does anyone know if it's possible to get old records (AS numbers...) of 
an IP allocation ?
I found on RIPE these data : ftp://ftp.ripe.net/pub/stats/ripencc/
But only the country and allocation date are included.

The IP range I would like to have more information about is 
109.190.0.0/17 (it was Russian before and now French).

Thanks in advance,
Regards,
Louis P.


From nanog at namor.ca  Sun Nov  6 13:41:49 2011
From: nanog at namor.ca (J)
Date: Sun, 06 Nov 2011 13:41:49 -0600
Subject: Historical records of IP allocations
In-Reply-To: <4EB6CB74.6060003@gmail.com>
References: <4EB6CB74.6060003@gmail.com>
Message-ID: <4EB6E2FD.5090807@namor.ca>

Louis P wrote:
> Hello,
> Does anyone know if it's possible to get old records (AS numbers...) of
> an IP allocation ?
> I found on RIPE these data : ftp://ftp.ripe.net/pub/stats/ripencc/
> But only the country and allocation date are included.
> 
> The IP range I would like to have more information about is
> 109.190.0.0/17 (it was Russian before and now French).
> 
> Thanks in advance,
> Regards,
> Louis P.

Cymru has something like that, don't they?  I'm not sure how far back it goes.

http://www.team-cymru.org/Services/ip-to-asn.html


From robt at cymru.com  Sun Nov  6 16:06:06 2011
From: robt at cymru.com (Rob Thomas)
Date: Sun, 06 Nov 2011 17:06:06 -0500
Subject: Historical records of IP allocations
In-Reply-To: <4EB6E2FD.5090807@namor.ca>
References: <4EB6CB74.6060003@gmail.com> <4EB6E2FD.5090807@namor.ca>
Message-ID: <4EB704CE.7000303@cymru.com>

Hi, team.

> Cymru has something like that, don't they?  I'm not sure how far back
> it goes.
> 
> http://www.team-cymru.org/Services/ip-to-asn.html

That's a more real-time view, so it won't be much use for historical
research.

Louis:  I did look in our archives, but only found AS35540 OVH-TELECOM
OVH Telecom as the origin.  Other folks on this list may have data that
goes further back.

Thanks,
Rob.
-- 
Rob Thomas
Team Cymru
https://www.team-cymru.org/
"Say little and do much." M Avot 1:15



From wilhelm at ripe.net  Sun Nov  6 16:34:45 2011
From: wilhelm at ripe.net (Rene Wilhelm)
Date: Sun, 06 Nov 2011 23:34:45 +0100
Subject: Historical records of IP allocations
In-Reply-To: <4EB6CB74.6060003@gmail.com>
References: <4EB6CB74.6060003@gmail.com>
Message-ID: <4EB70B85.3040103@ripe.net>

On 11/6/11 7:01 PM, Louis P wrote:
> Hello,
> Does anyone know if it's possible to get old records (AS numbers...) 
> of an IP allocation ?
> I found on RIPE these data : ftp://ftp.ripe.net/pub/stats/ripencc/
> But only the country and allocation date are included.
Have a look at stat.ripe.net , specifically the 'routing history' box.

http://stat.ripe.net/query/routing-history/109.190.0.0/17 shows the less 
specific 109.190/16 was originated by AS35408 from approximately january 
2010 to july 2010.

-- Rene
>
> The IP range I would like to have more information about is 
> 109.190.0.0/17 (it was Russian before and now French).
>
> Thanks in advance,
> Regards,
> Louis P.
>
>



From tom+nanog at oneshoeco.com  Sun Nov  6 19:00:52 2011
From: tom+nanog at oneshoeco.com (Tom Lanyon)
Date: Mon, 7 Nov 2011 11:30:52 +1030
Subject: Performance Issues - PTR Records
In-Reply-To: <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net>
References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org>
 <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net>
Message-ID: <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>

On 05/11/2011, at 1:14 PM, Paul Ebersman wrote:
> tim> If PTR exists in zone file, serve it.  Else, synthesize generic
> tim> reverse.  Jobsagoodun.
> 
> If all we're doing is lying with some generic answer that we hack our
> server to produce, why are we bothering?

Because some applications rely on it working (for some definition of "working").

> My contention is that (at least for end hosts), PTR records are mostly
> pointless and just overhead for DNS servers.

If you haven't set up PTR records for your end hosts, realistically you're going to be serving NXDOMAINs for them anyway, so there's not really any overhead introduced by supplying something generic instead...

Tom



From marka at isc.org  Sun Nov  6 19:10:21 2011
From: marka at isc.org (Mark Andrews)
Date: Mon, 07 Nov 2011 12:10:21 +1100
Subject: Performance Issues - PTR Records
In-Reply-To: Your message of "Mon, 07 Nov 2011 11:30:52 +1030."
 <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org>
 <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net>
 <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
Message-ID: <20111107011021.5CEB316CD13E@drugs.dv.isc.org>


In message <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8 at oneshoeco.com>, Tom Lanyon wri
tes:
> On 05/11/2011, at 1:14 PM, Paul Ebersman wrote:
> > tim> If PTR exists in zone file, serve it.  Else, synthesize generic
> > tim> reverse.  Jobsagoodun.
> >=20
> > If all we're doing is lying with some generic answer that we hack our
> > server to produce, why are we bothering?
> 
> Because some applications rely on it working (for some definition of =
> "working").
> 
> > My contention is that (at least for end hosts), PTR records are mostly
> > pointless and just overhead for DNS servers.
> 
> If you haven't set up PTR records for your end hosts, realistically =
> you're going to be serving NXDOMAINs for them anyway, so there's not =
> really any overhead introduced by supplying something generic instead...
> 
> Tom

Except you also have to supply the A/AAAA records as well.

MacOS and Windows can both populate the reverse zone for you as can
dhcp servers.

The practice of filling out the reverse zone with fake PTR record
started before there was wide spread support for UPDATE/DNS.  There
isn't any need for this to be done anymore.  Machines are capable
of adding records for themselves.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From craams at staff.ains.net.au  Sun Nov  6 19:36:03 2011
From: craams at staff.ains.net.au (Curtis Raams)
Date: Mon, 7 Nov 2011 01:36:03 +0000
Subject: Bulk purchase of some Cisco 857 routers
Message-ID: <C6F396C4A0183F4D91F07BF87D09A5809DC49D89@exchange.staff.ains.net.au>

Hello,

I have a client who is seeking to purchase 150 second hand Cisco 857 routers. We are unable to supply this quantity since we no longer inventory the items.

Does anyone on the list have a large quantity they want to get rid of?



[Description: map]

Curtis Raams
General Manager of ICT

Level 6, 140 Queen St. Melbourne Victoria 3000

T: 03 8665 8305 F: 03 9945 7502 M: 0404 394 904

E: craams at staff.ains.net.au<mailto:craams at staff.ains.net.au> W: www.ains.com.au<http://www.ains.com.au/>





This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify us immediately by telephone on 1300 887 877 and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.
BE GREEN! Read from the screen.




From mysidia at gmail.com  Sun Nov  6 19:57:51 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 6 Nov 2011 19:57:51 -0600
Subject: Performance Issues - PTR Records
In-Reply-To: <20111107011021.5CEB316CD13E@drugs.dv.isc.org>
References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org>
 <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net>
 <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org>
Message-ID: <CAAAwwbX3-LNd8hRCYwdBGhCamBwjqT6u9Xygf08GmO+RRNJjuA@mail.gmail.com>

On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews <marka at isc.org> wrote:
> MacOS and Windows can both populate the reverse zone for you as can
> dhcp servers.
> The practice of filling out the reverse zone with fake PTR record  [...]

OK.. let's say you're a DSL provider.   Are you going to have your
DHCP server populating the forward and reverse DNS?   With what,  the
account holder's  name?    somename.example.com ?

Wouldn't you say    blahblah192-168-0-2.city.state.dsl.example.com
provides more useful information?
First of all, you know that the IP address is an end user,  an access
network's end user's one IP address,
an endpoint, rather than a subnet assigned to an actual multinode network.

Second of all, you know it's an ISP, and you have city and state
information of the network service.
This is more useful than arbitrary user made up hostname.

The hostname is more meaningful on "real networks" such as SMB LANs,
Enterprise intranets, web farms,  server networks, and other places
where generic records should not be assigned, but the PTR should be
the actual hostname.

If the IP address is dynamic or autoconfigured for _those_ types of
networks, then yes, automatic RDNS registration makes sense.   If it's
static, not so much.

Dynamic DNS registration is also complicated to make secure....   as
in preventing hosts from updating other hosts'  records  or  mucking
around the zone in other unwanted ways  requires complex key
management and ACL configuration


>
> --
> Mark Andrews, ISC
--
-JH


From bonomi at mail.r-bonomi.com  Sun Nov  6 20:16:39 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sun, 6 Nov 2011 20:16:39 -0600 (CST)
Subject: Performance Issues - PTR Records
In-Reply-To: <CAAAwwbX3-LNd8hRCYwdBGhCamBwjqT6u9Xygf08GmO+RRNJjuA@mail.gmail.com>
Message-ID: <201111070216.pA72Gd7V047900@mail.r-bonomi.com>

> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Sun Nov  6 19:58:58 2011
> Date: Sun, 6 Nov 2011 19:57:51 -0600
> Subject: Re: Performance Issues - PTR Records
> From: Jimmy Hess <mysidia at gmail.com>
> To: Mark Andrews <marka at isc.org>
> Cc: nanog at nanog.org
>
> On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews <marka at isc.org> wrote:
> > MacOS and Windows can both populate the reverse zone for you as can
> > dhcp servers.
> > The practice of filling out the reverse zone with fake PTR record  [...]
>
> OK.. let's say you're a DSL provider.   Are you going to have your
> DHCP server populating the forward and reverse DNS?   With what,  the
> account holder's  name?    somename.example.com ?

I'll suggest that (a) IF the addresses do migrate among different customers
of the ISP, (b) the addresses handed out are publicly routable, AND (c) the
CPE has to 'authenticate' itself to the head-end, then it is _very_ useful 
*to*the*ISP* to have dynamically-assigned DNS records of the form: 
   cust.{accountid}.{locationid}.ISP.{com/net/TLD}
or something of the sort.

Something of that sort can save a -lot- of time/effort in identifying the
customer involved in a complaint.




From cmadams at hiwaay.net  Sun Nov  6 20:45:03 2011
From: cmadams at hiwaay.net (Chris Adams)
Date: Sun, 6 Nov 2011 20:45:03 -0600
Subject: Performance Issues - PTR Records
In-Reply-To: <201111070216.pA72Gd7V047900@mail.r-bonomi.com>
References: <CAAAwwbX3-LNd8hRCYwdBGhCamBwjqT6u9Xygf08GmO+RRNJjuA@mail.gmail.com>
 <201111070216.pA72Gd7V047900@mail.r-bonomi.com>
Message-ID: <20111107024502.GA20080@hiwaay.net>

Once upon a time, Robert Bonomi <bonomi at mail.r-bonomi.com> said:
> I'll suggest that (a) IF the addresses do migrate among different customers
> of the ISP, (b) the addresses handed out are publicly routable, AND (c) the
> CPE has to 'authenticate' itself to the head-end, then it is _very_ useful 
> *to*the*ISP* to have dynamically-assigned DNS records of the form: 
>    cust.{accountid}.{locationid}.ISP.{com/net/TLD}
> or something of the sort.

Putting a customer ID in reverse DNS would probably be a violation of
privacy policies.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From richard.barnes at gmail.com  Sun Nov  6 20:45:33 2011
From: richard.barnes at gmail.com (Richard Barnes)
Date: Mon, 7 Nov 2011 03:45:33 +0100
Subject: Historical records of IP allocations
In-Reply-To: <4EB6CB74.6060003@gmail.com>
References: <4EB6CB74.6060003@gmail.com>
Message-ID: <CACB24MtAwxa5vRA=UvQyACrjePeKRTmaEJpXGmxNFuK2nhCtyg@mail.gmail.com>

Sounds like a good application for INRDB:
<https://labs.ripe.net/Members/kistel/content-intro-inrdb-internet-number-resource-database>

RIPEstat also has at least its routing history, back as far as 2006:
<http://stat.ripe.net/109.190.0.0/17>

On Sun, Nov 6, 2011 at 7:01 PM, Louis P <lbstreamer at gmail.com> wrote:
> Hello,
> Does anyone know if it's possible to get old records (AS numbers...) of an
> IP allocation ?
> I found on RIPE these data : ftp://ftp.ripe.net/pub/stats/ripencc/
> But only the country and allocation date are included.
>
> The IP range I would like to have more information about is 109.190.0.0/17
> (it was Russian before and now French).
>
> Thanks in advance,
> Regards,
> Louis P.
>
>


From tom+nanog at oneshoeco.com  Sun Nov  6 20:51:29 2011
From: tom+nanog at oneshoeco.com (Tom Lanyon)
Date: Mon, 7 Nov 2011 13:21:29 +1030
Subject: Performance Issues - PTR Records
In-Reply-To: <201111070216.pA72Gd7V047900@mail.r-bonomi.com>
References: <201111070216.pA72Gd7V047900@mail.r-bonomi.com>
Message-ID: <06E4635F-2601-468B-832B-C10EE351117E@oneshoeco.com>

On 07/11/2011, at 12:46 PM, Robert Bonomi wrote:
>> OK.. let's say you're a DSL provider.   Are you going to have your
>> DHCP server populating the forward and reverse DNS?   With what,  the
>> account holder's  name?    somename.example.com ?
> 
> I'll suggest that (a) IF the addresses do migrate among different customers
> of the ISP, (b) the addresses handed out are publicly routable, AND (c) the
> CPE has to 'authenticate' itself to the head-end, then it is _very_ useful 
> *to*the*ISP* to have dynamically-assigned DNS records of the form: 
>   cust.{accountid}.{locationid}.ISP.{com/net/TLD}
> or something of the sort.
> 
> Something of that sort can save a -lot- of time/effort in identifying the
> customer involved in a complaint.

Surely that's only useful if they're still allocated the address at the time of investigating said complaint;  a dynamically updating DNS record like this is really no substitution for accurate accounting records in your RADIUS system.

Tom

From marka at isc.org  Sun Nov  6 21:19:35 2011
From: marka at isc.org (Mark Andrews)
Date: Mon, 07 Nov 2011 14:19:35 +1100
Subject: Performance Issues - PTR Records
In-Reply-To: Your message of "Sun, 06 Nov 2011 19:57:51 MDT."
 <CAAAwwbX3-LNd8hRCYwdBGhCamBwjqT6u9Xygf08GmO+RRNJjuA@mail.gmail.com>
References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org>
 <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net>
 <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org>
 <CAAAwwbX3-LNd8hRCYwdBGhCamBwjqT6u9Xygf08GmO+RRNJjuA@mail.gmail.com>
Message-ID: <20111107031935.1A29416D3DA6@drugs.dv.isc.org>


In message <CAAAwwbX3-LNd8hRCYwdBGhCamBwjqT6u9Xygf08GmO+RRNJjuA at mail.gmail.com>
, Jimmy Hess writes:
> On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews <marka at isc.org> wrote:
> > MacOS and Windows can both populate the reverse zone for you as can
> > dhcp servers.
> > The practice of filling out the reverse zone with fake PTR record  [...]
> 
> OK.. let's say you're a DSL provider.   Are you going to have your
> DHCP server populating the forward and reverse DNS?   With what,  the
> account holder's  name?    somename.example.com ?

With what the machine told you to populate it with.  If the hostname
isn't specified in the request uses your default naming scheme.

> Wouldn't you say    blahblah192-168-0-2.city.state.dsl.example.com
> provides more useful information?

No.

> First of all, you know that the IP address is an end user,  an access
> network's end user's one IP address,
> an endpoint, rather than a subnet assigned to an actual multinode network.

Is it?  Even today with IPv4 you don't have to hand out single addresses
to customers.
 
> Second of all, you know it's an ISP, and you have city and state
> information of the network service.
> This is more useful than arbitrary user made up hostname.

In your opinion.  It may not be in the customer's opinion and they are
the ones leasing the address.
 
> The hostname is more meaningful on "real networks" such as SMB LANs,
> Enterprise intranets, web farms,  server networks, and other places
> where generic records should not be assigned, but the PTR should be
> the actual hostname.

New flash.  "real networks" already exist in homes.  The only reason
they arn't visible outside the home is that ISP's have been
ridiculously slow in making IPv6 available to the homes and with that
the potential for directly address machines.

> If the IP address is dynamic or autoconfigured for _those_ types of
> networks, then yes, automatic RDNS registration makes sense.   If it's
> static, not so much.
 
> Dynamic DNS registration is also complicated to make secure....   as
> in preventing hosts from updating other hosts'  records  or  mucking
> around the zone in other unwanted ways  requires complex key
> management and ACL configuration

No.  It's not really complicated to make secure.  It's quite possible
to prevent machines muking up others records.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From brett at the-watsons.org  Sun Nov  6 22:43:11 2011
From: brett at the-watsons.org (Brett Watson)
Date: Sun, 6 Nov 2011 21:43:11 -0700
Subject: Performance Issues - PTR Records
In-Reply-To: <CAAAwwbX3-LNd8hRCYwdBGhCamBwjqT6u9Xygf08GmO+RRNJjuA@mail.gmail.com>
References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org>
 <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net>
 <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org>
 <CAAAwwbX3-LNd8hRCYwdBGhCamBwjqT6u9Xygf08GmO+RRNJjuA@mail.gmail.com>
Message-ID: <A24BB076-4ECB-464B-AEBF-C7AE6F66A208@the-watsons.org>

On Nov 6, 2011, at 6:57 PM, Jimmy Hess wrote:

> On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews <marka at isc.org> wrote:
>> MacOS and Windows can both populate the reverse zone for you as can
>> dhcp servers.
>> The practice of filling out the reverse zone with fake PTR record  [...]
> 
> OK.. let's say you're a DSL provider.   Are you going to have your
> DHCP server populating the forward and reverse DNS?   With what,  the
> account holder's  name?    somename.example.com ?

Is this discussion seriously happening, again? Really? I don't think it's been 2 full months since the last round.

From paul4004 at gmail.com  Sun Nov  6 22:48:34 2011
From: paul4004 at gmail.com (PC)
Date: Sun, 6 Nov 2011 21:48:34 -0700
Subject: IPv6 beta support for Android phones
In-Reply-To: <1320597177.6199.8.camel@teh-desktop>
References: <CAD6AjGQAU28=hnBJNmc1jPCQi907L26MbnhvUnJ69K6CHo=mKw@mail.gmail.com>
 <1320597177.6199.8.camel@teh-desktop>
Message-ID: <CAJAdsDmgDT5icPoU4rPpJaoxEk4T7X+GuQqhC1qdxKj3_BhB4Q@mail.gmail.com>

Is there any way this beta can be used in conjunction with other t-mobile
data products (such as pre or post paid SIMs used in data cards/USB
dongles)?

On Sun, Nov 6, 2011 at 9:32 AM, Tom Hill <tom at ninjabadger.net> wrote:

> On Fri, 2011-11-04 at 15:04 -0700, Cameron Byrne wrote:
> > FYI.
> >
> > T-Mobile USA now has opt-in beta support for an Android phone on IPv6,
> > more info here https://sites.google.com/site/tmoipv6/lg-mytouch
>
> Very, very good. I hope T-Mobile UK (and elsewhere in the world) take
> heed.
>
> I have to wonder why they've chosen to go with IPv6-only & DNS/NAT64
> instead of a dual-stack approach. Is there a particular restriction that
> prevents this?
>
> > As far as i know, this is the first Android phone that support IPv6 on
> > the GSM/UMTS mobile interface.  Previous version of Android phones
> > supported IPv6 on WiFi and LTE.
>
> Indeed, the 'Network Info II' application will show you the IPv6
> addresses gained on WiFi interfaces (if anyone's interested). My Galaxy
> S (unlocked/orig.) does this very well.
>
> I wonder if it's possible to provide IPv6 support for UMTS/GSM via
> firmware and/or software updates from Samsung?
>
> Tom
>
>
>

From cb.list6 at gmail.com  Sun Nov  6 23:31:48 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Sun, 6 Nov 2011 21:31:48 -0800
Subject: IPv6 beta support for Android phones
In-Reply-To: <1320597177.6199.8.camel@teh-desktop>
References: <CAD6AjGQAU28=hnBJNmc1jPCQi907L26MbnhvUnJ69K6CHo=mKw@mail.gmail.com>
 <1320597177.6199.8.camel@teh-desktop>
Message-ID: <CAD6AjGTTBnJhAdpcxGW0VWaym-Lcw9eHot4Mw=xNKULyEDUyvg@mail.gmail.com>

On Sun, Nov 6, 2011 at 8:32 AM, Tom Hill <tom at ninjabadger.net> wrote:
> On Fri, 2011-11-04 at 15:04 -0700, Cameron Byrne wrote:
>> FYI.
>>
>> T-Mobile USA now has opt-in beta support for an Android phone on IPv6,
>> more info here https://sites.google.com/site/tmoipv6/lg-mytouch
>
> Very, very good. I hope T-Mobile UK (and elsewhere in the world) take
> heed.
>
> I have to wonder why they've chosen to go with IPv6-only & DNS/NAT64
> instead of a dual-stack approach. Is there a particular restriction that
> prevents this?
>

There are a variety of reasons.  Most prominent is that if the issue
is lack of IPv4 addresses (public and private), dual-stack does not
solve this problem, each device still gets an IPv4 address.  Another
major issue is that in GSM/UMTS (3GPP pre-release 9), having
dual-stack means having 2 attachments to the network,  one for v4 and
one for v6.  Most mobile providers pay for most of their network kit
in terms of these attachments known as PDP.  Consequently, dual-stack
doubles the of the packet-core network.  If we take the licensing and
contractual parts out of the equations, double the attachments means
double the signalling and mobility events ... resulting in double the
CPU / Memory / blah ...

LTE does not have the dual attachment problem since there is the
concept of having v4 and v6 in one attachment, but it does not change
the fact that there are not enough IPv4 addresses to go around,
especially from a strategic planning perspective (let's design this
once for 5 to 10+ year life ...)


>> As far as i know, this is the first Android phone that support IPv6 on
>> the GSM/UMTS mobile interface. ?Previous version of Android phones
>> supported IPv6 on WiFi and LTE.
>
> Indeed, the 'Network Info II' application will show you the IPv6
> addresses gained on WiFi interfaces (if anyone's interested). My Galaxy
> S (unlocked/orig.) does this very well.
>
> I wonder if it's possible to provide IPv6 support for UMTS/GSM via
> firmware and/or software updates from Samsung?
>

That's a good question for Samsung.  Most vendors would rather have
you buy a new device :(

CB

> Tom
>
>
>


From dhubbard at dino.hostasaurus.com  Mon Nov  7 00:14:29 2011
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Mon, 7 Nov 2011 01:14:29 -0500
Subject: Cell-based OOB  management devices
Message-ID: <FCD26398C5EDE746BFC47F43EA52A173054DA958@dino.ad.hostasaurus.com>

Hi all, I am looking at cellular-based devices as a higher
speed alternative to dial-up backup access methods for
out of band management during emergencies.  I was
wondering if anyone had experiences with such devices
they could share?

Devices I've found include Sierra Wireless AirLink Raven X,
Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G.  I
have no experience with any but they all appear to support
the Sprint network which I assume would be ideal due to
not having usage caps on data (currently).  The Opengear
device runs linux and has four serial ports, a usb port
for additional storage and ethernet, so it seems to have
some small advantages over the others since it could double
as an emergency self-contained management station you can
SSH into and run diagnostics from.  All appear to have
VPN/gateway support.

What none of them are clear on is how you would connect
to it over cellular since I assume you're just paying for
a typical data plan and it will randomly obtain IP 
addresses.  Maybe some type of dynamic dns service so you
can easily figure out your device's current IP?  How
stable is the access to the device?  Any idea if any of
them can do ipv6?

Thanks!

David



From sethm at rollernet.us  Mon Nov  7 00:21:33 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Sun, 06 Nov 2011 22:21:33 -0800
Subject: Cell-based OOB  management devices
In-Reply-To: <FCD26398C5EDE746BFC47F43EA52A173054DA958@dino.ad.hostasaurus.com>
References: <FCD26398C5EDE746BFC47F43EA52A173054DA958@dino.ad.hostasaurus.com>
Message-ID: <4EB778ED.3010702@rollernet.us>

On 11/6/11 10:14 PM, David Hubbard wrote:
> Hi all, I am looking at cellular-based devices as a higher
> speed alternative to dial-up backup access methods for
> out of band management during emergencies.  I was
> wondering if anyone had experiences with such devices
> they could share?
> 
> Devices I've found include Sierra Wireless AirLink Raven X,
> Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G.  I
> have no experience with any but they all appear to support
> the Sprint network which I assume would be ideal due to
> not having usage caps on data (currently).  The Opengear
> device runs linux and has four serial ports, a usb port
> for additional storage and ethernet, so it seems to have
> some small advantages over the others since it could double
> as an emergency self-contained management station you can
> SSH into and run diagnostics from.  All appear to have
> VPN/gateway support.
> 
> What none of them are clear on is how you would connect
> to it over cellular since I assume you're just paying for
> a typical data plan and it will randomly obtain IP 
> addresses.  Maybe some type of dynamic dns service so you
> can easily figure out your device's current IP?  How
> stable is the access to the device?  Any idea if any of
> them can do ipv6?
> 


With the Cisco 3G WIC cards they'll do a static IP or a tunnel. I'd
presume something similar can be done with other options if you ask.

~Seth


From rdobbins at arbor.net  Mon Nov  7 00:21:31 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 7 Nov 2011 06:21:31 +0000
Subject: Cell-based OOB  management devices
In-Reply-To: <FCD26398C5EDE746BFC47F43EA52A173054DA958@dino.ad.hostasaurus.com>
References: <FCD26398C5EDE746BFC47F43EA52A173054DA958@dino.ad.hostasaurus.com>
Message-ID: <E2A76B94-24D5-440D-BCF1-C14037E445B9@arbor.net>


On Nov 7, 2011, at 1:14 PM, David Hubbard wrote:

> Hi all, I am looking at cellular-based devices as a higher speed alternative to dial-up backup access methods for
> out of band management during emergencies.

Some of the lower-end Cisco routers have '3G' interfaces available as an option, I believe.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From lucas at cs.ucla.edu  Mon Nov  7 00:34:05 2011
From: lucas at cs.ucla.edu (Lucas Wang)
Date: Sun, 6 Nov 2011 22:34:05 -0800
Subject: Historical records of IP allocations
In-Reply-To: <0737E427-68A2-4AC6-8F7A-1B2B81D45AC3@cs.ucla.edu>
References: <4EB6CB74.6060003@gmail.com>
 <0737E427-68A2-4AC6-8F7A-1B2B81D45AC3@cs.ucla.edu>
Message-ID: <F6A73811-0251-40A7-A504-E32359362DA2@cs.ucla.edu>

We started keeping track of whois databases from March 20th this year,
and our earliest data shows it belongs to a Russian company called DIMEDIA LLC.
Now the latest whois shows it belongs to "OVH Telecom" located in France.

On Nov 6, 2011, at 10:58 AM, Louis P wrote:

> Hello,
> Does anyone know if it's possible to get old records (AS numbers...) of an IP allocation ?
> I found on RIPE these data : ftp://ftp.ripe.net/pub/stats/ripencc/
> But only the country and allocation date are included.
> 
> The IP range I would like to have more information about is 109.190.0.0/17 (it was Russian before and now French).
> 
> Thanks in advance,
> Regards,
> Louis P.



From bjorn at mork.no  Mon Nov  7 00:50:48 2011
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 07 Nov 2011 07:50:48 +0100
Subject: Performance Issues - PTR Records
In-Reply-To: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> (Mark Andrews's
 message of "Mon, 07 Nov 2011 12:10:21 +1100")
References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org>
 <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net>
 <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org>
Message-ID: <87ty6g1l4n.fsf@nemi.mork.no>

Mark Andrews <marka at isc.org> writes:

> The practice of filling out the reverse zone with fake PTR record
> started before there was wide spread support for UPDATE/DNS.  There
> isn't any need for this to be done anymore.  Machines are capable
> of adding records for themselves.

How do I setup this for DHCPv6-PD?  Say, I delegate 2001:db8:42::/48 to
the end user.  Should I delegate reverse DNS as well?  If so, to whom?

Or is it the CPEs responibility to dynamically add records for whatever
addresses it sees on the internal LAN(s)?  Are there CPEs capable of
doing this?

Or will the end systems themselves do the update against my DNS server?
If so, how do I authenticate that?



Bj?rn


From swmike at swm.pp.se  Mon Nov  7 01:02:34 2011
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Mon, 7 Nov 2011 08:02:34 +0100 (CET)
Subject: IPv6 beta support for Android phones
In-Reply-To: <CAD6AjGTTBnJhAdpcxGW0VWaym-Lcw9eHot4Mw=xNKULyEDUyvg@mail.gmail.com>
References: <CAD6AjGQAU28=hnBJNmc1jPCQi907L26MbnhvUnJ69K6CHo=mKw@mail.gmail.com>
 <1320597177.6199.8.camel@teh-desktop>
 <CAD6AjGTTBnJhAdpcxGW0VWaym-Lcw9eHot4Mw=xNKULyEDUyvg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111070759020.19721@uplift.swm.pp.se>

On Sun, 6 Nov 2011, Cameron Byrne wrote:

> LTE does not have the dual attachment problem since there is the concept 
> of having v4 and v6 in one attachment, but it does not change the fact 
> that there are not enough IPv4 addresses to go around, especially from a 
> strategic planning perspective (let's design this once for 5 to 10+ year 
> life ...)

Actually, GTPv2 with v4v6 bearer works in GSM/UMTS as well, but one has to 
software upgrade all components to make sure it's supported. Unfortunately 
this is still a future roadmap item for a lot of vendors.

This of course needs to be supported in the end user devices as well, but 
the LTE dongles when in 2G/3G will hopefully still support this.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se


From bonomi at mail.r-bonomi.com  Mon Nov  7 01:09:19 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Mon, 7 Nov 2011 01:09:19 -0600 (CST)
Subject: Performance Issues - PTR Records
In-Reply-To: <06E4635F-2601-468B-832B-C10EE351117E@oneshoeco.com>
Message-ID: <201111070709.pA779JpT049171@mail.r-bonomi.com>


Tom Lanyon <tom+nanog at oneshoeco.com> opined:
> >> OK.. let's say you're a DSL provider.   Are you going to have your
> >> DHCP server populating the forward and reverse DNS?   With what,  the
> >> account holder's  name?    somename.example.com ?
> > 
> > I'll suggest that (a) IF the addresses do migrate among different customers
> > of the ISP, (b) the addresses handed out are publicly routable, AND (c) the
> > CPE has to 'authenticate' itself to the head-end, then it is _very_ useful 
> > *to*the*ISP* to have dynamically-assigned DNS records of the form: 
> >   cust.{accountid}.{locationid}.ISP.{com/net/TLD}
> > or something of the sort.
> > 
> > Something of that sort can save a -lot- of time/effort in identifying the
> > customer involved in a complaint.
>
> Surely that's only useful if they're still allocated the address at the time 
> of investigating said complaint;  a dynamically updating DNS record like thi
> s is really no substitution for accurate accounting records in your RADIUS s
> ystem.

You're missing some 'obvious' considerations.  Consider a spam complaint
sent with 'full headers' included.  The rDNS _at_the_time_of_the_crime_
is present in the complaint.  Yes, you need to confirm that -that- customer
was on that IP at that time -- but having an identifier for the customer
makes the verification check much quicker/simpler, and requires less skils
on the part of the front-line person dealing with the complaint.

No, it doesn't *always* provide a short-cut to identification, but it is
useful "often enough' to be well worth considering.




From Valdis.Kletnieks at vt.edu  Mon Nov  7 01:34:17 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 07 Nov 2011 02:34:17 -0500
Subject: Performance Issues - PTR Records
In-Reply-To: Your message of "Mon, 07 Nov 2011 01:09:19 CST."
 <201111070709.pA779JpT049171@mail.r-bonomi.com>
References: <201111070709.pA779JpT049171@mail.r-bonomi.com>
Message-ID: <22432.1320651257@turing-police.cc.vt.edu>

On Mon, 07 Nov 2011 01:09:19 CST, Robert Bonomi said:

> You're missing some 'obvious' considerations.  Consider a spam complaint
> sent with 'full headers' included.  The rDNS _at_the_time_of_the_crime_
> is present in the complaint.

And if the rDNS isn't provided, any sane MTA will have included the IP address
and timestamp involved, which shouldn't take you all *that* much longer to
track down to one of your users.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111107/16a2d20b/attachment.bin>

From mysidia at gmail.com  Mon Nov  7 02:51:07 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 7 Nov 2011 02:51:07 -0600
Subject: Performance Issues - PTR Records
In-Reply-To: <22432.1320651257@turing-police.cc.vt.edu>
References: <201111070709.pA779JpT049171@mail.r-bonomi.com>
 <22432.1320651257@turing-police.cc.vt.edu>
Message-ID: <CAAAwwbUYzR_-0OVupWZMnPxXcHHZsYMaiXxW3QuZuehtFfRd5w@mail.gmail.com>

On Mon, Nov 7, 2011 at 1:34 AM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Mon, 07 Nov 2011 01:09:19 CST, Robert Bonomi said:
>> You're missing some 'obvious' considerations. ?Consider a spam complaint
>> sent with 'full headers' included. ?The rDNS _at_the_time_of_the_crime_
>> is present in the complaint.
> And if the rDNS isn't provided, any sane MTA will have included the IP address
> and timestamp involved, which shouldn't take you all *that* much longer to
> track down to one of your users.

I wouldn't take for granted that "IP address plus timestamp"  can be
used to track down
a user after the fact.   This is not always the case,  plenty of times
it is not;  the user may not be logged on anymore, and there might be
no historical data available, or the lifetime of the historical data
short enough, that it  expired before the complaint came in, possibly
24 hours or more later.  Especially not on shared LANs,  where an
unruly user might actually select some random IP address and use it
without permission.

The RDNS will help in some of those cases if you don't keep/have
sufficient information to identify
a user by IP address, if your ability to create a mapping is
unreliable...  for example,
you can't really be sure  about accurate clock synchronization in the
timestamps of
the MTAs  to any detail info you may have.

But even with RDNS there is still a matching problem...   DNS records
have TTLs. The old mapping for an IP address can live in a cache for a
significant amount of time.

Sometimes unruly DNS servers or unruly applications fail to correctly
implement DNS, and wind up holding a record past its TTL...   an  "old
PTR mapping"  for the IP address may be reported in message headers.

The result can be a previous customer's ID in such a scheme would
appear in the complaint.
Now I  suppose you could include another piece of info in the reverse record

<custid>.registeredat<timestamp>.checksum

And then if the purported timestamp in the complaint is after the
'next DNS record registration time'  + TTL
you know that the RDNS on the complaint listed is invalid

To maintain integrity in that case...  you would need to ensure the IP
address could not be recycled to another user  before all DNS records
cached at the logoff time + DNS registration interval expired.

--
-JH


From leigh.porter at ukbroadband.com  Mon Nov  7 03:08:13 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 7 Nov 2011 09:08:13 +0000
Subject: IPv6 beta support for Android phones
In-Reply-To: <CAD6AjGTTBnJhAdpcxGW0VWaym-Lcw9eHot4Mw=xNKULyEDUyvg@mail.gmail.com>
References: <CAD6AjGQAU28=hnBJNmc1jPCQi907L26MbnhvUnJ69K6CHo=mKw@mail.gmail.com>
 <1320597177.6199.8.camel@teh-desktop>
 <CAD6AjGTTBnJhAdpcxGW0VWaym-Lcw9eHot4Mw=xNKULyEDUyvg@mail.gmail.com>
Message-ID: <D181DDABABE57E4DB72FEE003314786442BBDD@EALPO1.ukbroadband.com>

> 
> LTE does not have the dual attachment problem since there is the
> concept of having v4 and v6 in one attachment, but it does not change
> the fact that there are not enough IPv4 addresses to go around,
> especially from a strategic planning perspective (let's design this
> once for 5 to 10+ year life ...)
> 

Most networks seem to dish out address space behind a LSN box these days.

I have three dongle things from three networks in the UK, none of them give me a public address.

--
Leigh Porter


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From tom at ninjabadger.net  Mon Nov  7 03:54:14 2011
From: tom at ninjabadger.net (Tom Hill)
Date: Mon, 07 Nov 2011 09:54:14 +0000
Subject: IPv6 beta support for Android phones
In-Reply-To: <CAD6AjGTTBnJhAdpcxGW0VWaym-Lcw9eHot4Mw=xNKULyEDUyvg@mail.gmail.com>
References: <CAD6AjGQAU28=hnBJNmc1jPCQi907L26MbnhvUnJ69K6CHo=mKw@mail.gmail.com>
 <1320597177.6199.8.camel@teh-desktop>
 <CAD6AjGTTBnJhAdpcxGW0VWaym-Lcw9eHot4Mw=xNKULyEDUyvg@mail.gmail.com>
Message-ID: <1320659656.2054.0.camel@teh-desktop>

Hi Cameron,

On Sun, 2011-11-06 at 21:31 -0800, Cameron Byrne wrote:
> 
> There are a variety of reasons.  Most prominent is that if the issue
> is lack of IPv4 addresses (public and private), dual-stack does not
> solve this problem, each device still gets an IPv4 address.  Another
> major issue is that in GSM/UMTS (3GPP pre-release 9), having
> dual-stack means having 2 attachments to the network,  one for v4 and
> one for v6.  Most mobile providers pay for most of their network kit
> in terms of these attachments known as PDP.  Consequently, dual-stack
> doubles the of the packet-core network.  If we take the licensing and
> contractual parts out of the equations, double the attachments means
> double the signalling and mobility events ... resulting in double the
> CPU / Memory / blah ...

That'll probably explain it... Thanks. :)

> LTE does not have the dual attachment problem since there is the
> concept of having v4 and v6 in one attachment, but it does not change
> the fact that there are not enough IPv4 addresses to go around,
> especially from a strategic planning perspective (let's design this
> once for 5 to 10+ year life ...)

If only the UK was as far ahead on LTE as the US!

Tom



From sthaug at nethelp.no  Mon Nov  7 07:46:48 2011
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Mon, 07 Nov 2011 14:46:48 +0100 (CET)
Subject: Performance Issues - PTR Records
In-Reply-To: <87ty6g1l4n.fsf@nemi.mork.no>
References: <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org>
 <87ty6g1l4n.fsf@nemi.mork.no>
Message-ID: <20111107.144648.74734213.sthaug@nethelp.no>

> > The practice of filling out the reverse zone with fake PTR record
> > started before there was wide spread support for UPDATE/DNS.  There
> > isn't any need for this to be done anymore.  Machines are capable
> > of adding records for themselves.
> 
> How do I setup this for DHCPv6-PD?  Say, I delegate 2001:db8:42::/48 to
> the end user.  Should I delegate reverse DNS as well?  If so, to whom?
> 
> Or is it the CPEs responibility to dynamically add records for whatever
> addresses it sees on the internal LAN(s)?  Are there CPEs capable of
> doing this?
> 
> Or will the end systems themselves do the update against my DNS server?
> If so, how do I authenticate that?

With my ISP hat on, I find the idea of customer CPEs updating their
own PTR records to be completely unacceptable. So I guess I'll either
live without the reverse DNS, or use a name server that can synthesize
answers on the fly.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no


From jeremyparr at gmail.com  Mon Nov  7 07:47:23 2011
From: jeremyparr at gmail.com (Jeremy Parr)
Date: Mon, 7 Nov 2011 08:47:23 -0500
Subject: Performance Issues - PTR Records
In-Reply-To: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
References: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
Message-ID: <CAKkPQBvx_N3dMGnBVZUBzueFDQ5XXCJ5iq6g4g8-4rNegBqxwg@mail.gmail.com>

On 2 November 2011 17:57, Matt Chung <itsmemattchung at gmail.com> wrote:

> I work for a regional ISP and very recently there has been an influx of
> calls reporting "slowness" when accessing certain websites (i.e
> google.com/voice/b) via HTTP.  *snip*
>

I have been experiencing this same issue as an end user, my ISP does not
provide PTR records for their address pools. YouTube, xkcd, Mozilla.org,
among others, are slow to load initially. Coming from AS15146 here.

From leigh.porter at ukbroadband.com  Mon Nov  7 07:52:46 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 7 Nov 2011 13:52:46 +0000
Subject: Performance Issues - PTR Records
In-Reply-To: <20111107.144648.74734213.sthaug@nethelp.no>
References: <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org>
 <87ty6g1l4n.fsf@nemi.mork.no>,<20111107.144648.74734213.sthaug@nethelp.no>
Message-ID: <40117B81-3201-4649-BA7E-C6800D923535@ukbroadband.com>



On 7 Nov 2011, at 13:48, "sthaug at nethelp.no" <sthaug at nethelp.no> wrote:

>>> The practice of filling out the reverse zone with fake PTR record
>>> started before there was wide spread support for UPDATE/DNS.  There
>>> isn't any need for this to be done anymore.  Machines are capable
>>> of adding records for themselves.
>> 
>> How do I setup this for DHCPv6-PD?  Say, I delegate 2001:db8:42::/48 to
>> the end user.  Should I delegate reverse DNS as well?  If so, to whom?
>> 
>> Or is it the CPEs responibility to dynamically add records for whatever
>> addresses it sees on the internal LAN(s)?  Are there CPEs capable of
>> doing this?
>> 
>> Or will the end systems themselves do the update against my DNS server?
>> If so, how do I authenticate that?
> 
> With my ISP hat on, I find the idea of customer CPEs updating their
> own PTR records to be completely unacceptable. So I guess I'll either
> live without the reverse DNS, or use a name server that can synthesize
> answers on the fly.
> 
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
> 

Indeed, there is no way I would allow that either. But really, providing a reverse zone and forward zone to match is a case of five minutes and a shell script or a DNS that as Steinar said, will synthesise results.

It's really not all that difficult..

--
Leigh Porter

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From bjorn at mork.no  Mon Nov  7 08:00:31 2011
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 07 Nov 2011 15:00:31 +0100
Subject: Performance Issues - PTR Records
In-Reply-To: <40117B81-3201-4649-BA7E-C6800D923535@ukbroadband.com> (Leigh
 Porter's message of "Mon, 7 Nov 2011 13:52:46 +0000")
References: <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org>
 <87ty6g1l4n.fsf@nemi.mork.no>
 <20111107.144648.74734213.sthaug@nethelp.no>
 <40117B81-3201-4649-BA7E-C6800D923535@ukbroadband.com>
Message-ID: <87fwi0118g.fsf@nemi.mork.no>

Leigh Porter <leigh.porter at ukbroadband.com> writes:

> Indeed, there is no way I would allow that either. But really,
> providing a reverse zone and forward zone to match is a case of five
> minutes and a shell script or a DNS that as Steinar said, will
> synthesise results.
>
> It's really not all that difficult..

No, not at all.  It's just totally pointless.  Any IPv6 address is just
as pretty as a synthesized name.  Maybe even prettier. Do you prefer
"2001:db8:1::2" or "20010db8000100000000000000000002.rev.example.com"?

If we're going to provide any reverse DNS for end users, then it is
because we can create names which actually improves something.


Bj?rn


From todd at borked.ca  Mon Nov  7 09:00:34 2011
From: todd at borked.ca (Todd Snyder)
Date: Mon, 7 Nov 2011 10:00:34 -0500
Subject: TATA problems?
Message-ID: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>

We seem to be having some problems with our tata links - first seen in EU
about 45 minutes ago, now we're seeing problems in NA.  I'm focused on DNS,
so I'm seeing a lot of timeouts/servfails, but our networking folks are
talking about links dropping.

Anyone else seeing oddness on the NA Internet right now?

http://downrightnow.com/ confirms - something is up.

cheers,

t.

From ppauly at gmail.com  Mon Nov  7 09:04:19 2011
From: ppauly at gmail.com (Peter Pauly)
Date: Mon, 7 Nov 2011 10:04:19 -0500
Subject: Time Warner Telecom problems
Message-ID: <CAKXfWbRjoZwB8m_1ozSnS=ki5Z2GaXJE2NKQKUWo2f6YM5aAFQ@mail.gmail.com>

Gizmodo is reporting problems at Time Warner Telecom .... we're suffering
from it too and calls to the NOC have not been answered so far...  does
anyone have any further information?

http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us

From bortzmeyer at nic.fr  Mon Nov  7 09:05:34 2011
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Mon, 7 Nov 2011 16:05:34 +0100
Subject: TATA problems?
In-Reply-To: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
Message-ID: <20111107150534.GA21702@nic.fr>

On Mon, Nov 07, 2011 at 10:00:34AM -0500,
 Todd Snyder <todd at borked.ca> wrote 
 a message of 12 lines which said:

> We seem to be having some problems with our tata links 

They probably use Juniper routers :-)





From drew.weaver at thenap.com  Mon Nov  7 09:05:57 2011
From: drew.weaver at thenap.com (Drew Weaver)
Date: Mon, 7 Nov 2011 10:05:57 -0500
Subject: Time Warner Telecom problems
In-Reply-To: <CAKXfWbRjoZwB8m_1ozSnS=ki5Z2GaXJE2NKQKUWo2f6YM5aAFQ@mail.gmail.com>
References: <CAKXfWbRjoZwB8m_1ozSnS=ki5Z2GaXJE2NKQKUWo2f6YM5aAFQ@mail.gmail.com>
Message-ID: <F3318834F1F89D46857972DD4B411D700523FEC33C@exchange>

The current line is Level3 is currently having an issue where they have certain code versions of a certain router vendor deployed.

They haven't said anything yet, so it's still kind of sketchy.

-----Original Message-----
From: Peter Pauly [mailto:ppauly at gmail.com] 
Sent: Monday, November 07, 2011 10:04 AM
To: nanog at nanog.org
Subject: Time Warner Telecom problems

Gizmodo is reporting problems at Time Warner Telecom .... we're suffering
from it too and calls to the NOC have not been answered so far...  does
anyone have any further information?

http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us


From tim at interworx.nl  Mon Nov  7 09:06:07 2011
From: tim at interworx.nl (Tim Vollebregt)
Date: Mon, 07 Nov 2011 16:06:07 +0100
Subject: TATA problems?
In-Reply-To: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
Message-ID: <4EB7F3DF.5040006@interworx.nl>

Hi,

This issue seems to be much bigger, we lost about 20 Level3 and some 
TATA sessions.
Also we lost about 15% of our total traffic.

On #IX there are rumours about Junos version 10.3R2.11 being core dumped 
and rebooted, which makes sense.

Currently traffic is restored.

Tim

On 07-11-11 16:00, Todd Snyder wrote:
> We seem to be having some problems with our tata links - first seen in EU
> about 45 minutes ago, now we're seeing problems in NA.  I'm focused on DNS,
> so I'm seeing a lot of timeouts/servfails, but our networking folks are
> talking about links dropping.
>
> Anyone else seeing oddness on the NA Internet right now?
>
> http://downrightnow.com/ confirms - something is up.
>
> cheers,
>
> t.

From lane.powers at swat.coop  Mon Nov  7 09:06:10 2011
From: lane.powers at swat.coop (Lane Powers)
Date: Mon, 07 Nov 2011 09:06:10 -0600
Subject: Time Warner Telecom problems
In-Reply-To: <CAKXfWbRjoZwB8m_1ozSnS=ki5Z2GaXJE2NKQKUWo2f6YM5aAFQ@mail.gmail.com>
Message-ID: <CADD4FD6.213BC%lane.powers@swat.coop>

L3 reported multiple links bouncing nationwide in the US approx 30 minutes
ago.  Causing multiple IP issues.


Lane
--
Lane Powers

On 11/7/11 9:04 AM, "Peter Pauly" <ppauly at gmail.com> wrote:

>Gizmodo is reporting problems at Time Warner Telecom .... we're suffering
>from it too and calls to the NOC have not been answered so far...  does
>anyone have any further information?
>
>http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
>





From drew.weaver at thenap.com  Mon Nov  7 09:08:01 2011
From: drew.weaver at thenap.com (Drew Weaver)
Date: Mon, 7 Nov 2011 10:08:01 -0500
Subject: Time Warner Telecom problems
In-Reply-To: <CADD4FD6.213BC%lane.powers@swat.coop>
References: <CAKXfWbRjoZwB8m_1ozSnS=ki5Z2GaXJE2NKQKUWo2f6YM5aAFQ@mail.gmail.com>
 <CADD4FD6.213BC%lane.powers@swat.coop>
Message-ID: <F3318834F1F89D46857972DD4B411D700523FEC33D@exchange>

Any idea where this information can be found publically?

-----Original Message-----
From: Lane Powers [mailto:lane.powers at swat.coop] 
Sent: Monday, November 07, 2011 10:06 AM
To: Peter Pauly; nanog at nanog.org
Subject: Re: Time Warner Telecom problems

L3 reported multiple links bouncing nationwide in the US approx 30 minutes
ago.  Causing multiple IP issues.


Lane
--
Lane Powers

On 11/7/11 9:04 AM, "Peter Pauly" <ppauly at gmail.com> wrote:

>Gizmodo is reporting problems at Time Warner Telecom .... we're suffering
>from it too and calls to the NOC have not been answered so far...  does
>anyone have any further information?
>
>http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
>






From Mark.Calkins at twtelecom.com  Mon Nov  7 09:09:17 2011
From: Mark.Calkins at twtelecom.com (Calkins, Mark)
Date: Mon, 7 Nov 2011 15:09:17 +0000
Subject: Time Warner Telecom problems
In-Reply-To: <CAKXfWbRjoZwB8m_1ozSnS=ki5Z2GaXJE2NKQKUWo2f6YM5aAFQ@mail.gmail.com>
References: <CAKXfWbRjoZwB8m_1ozSnS=ki5Z2GaXJE2NKQKUWo2f6YM5aAFQ@mail.gmail.com>
Message-ID: <0EB48B40EDC6C643AC36ADE613C78DEF0FEF97B5@SRVMSXMBDEN4.ad.twtelecom.com>

I believe you are referring to Time Warner Cable.  There is no such thing as Time Warner Telecom anymore.

-----Original Message-----
From: Peter Pauly [mailto:ppauly at gmail.com]
Sent: Monday, November 07, 2011 8:04 AM
To: nanog at nanog.org
Subject: Time Warner Telecom problems

Gizmodo is reporting problems at Time Warner Telecom .... we're suffering from it too and calls to the NOC have not been answered so far...  does anyone have any further information?

http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us



-------------



The content contained in this electronic message is not intended to constitute formation of a contract binding tw telecom. tw telecom will be contractually bound only upon execution, by an authorized officer, of a contract including agreed terms and conditions or by express application of its tariffs. This message is intended only for the use of the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail or by telephone.




From lane.powers at swat.coop  Mon Nov  7 09:10:18 2011
From: lane.powers at swat.coop (Lane Powers)
Date: Mon, 07 Nov 2011 09:10:18 -0600
Subject: Time Warner Telecom problems
In-Reply-To: <F3318834F1F89D46857972DD4B411D700523FEC33D@exchange>
Message-ID: <CADD5096.213C3%lane.powers@swat.coop>

If your an L3 transit customer you should be able to refer to event id
5197215.
Not sure if they have published anything otherwise, it is still very early.

In our case we had to drop our L3 sessions until the storm passes.

Lane


On 11/7/11 9:08 AM, "Drew Weaver" <drew.weaver at thenap.com> wrote:

>Any idea where this information can be found publically?
>
>-----Original Message-----
>From: Lane Powers [mailto:lane.powers at swat.coop]
>Sent: Monday, November 07, 2011 10:06 AM
>To: Peter Pauly; nanog at nanog.org
>Subject: Re: Time Warner Telecom problems
>
>L3 reported multiple links bouncing nationwide in the US approx 30 minutes
>ago.  Causing multiple IP issues.
>
>
>Lane
>--
>Lane Powers
>
>On 11/7/11 9:04 AM, "Peter Pauly" <ppauly at gmail.com> wrote:
>
>>Gizmodo is reporting problems at Time Warner Telecom .... we're suffering
>>from it too and calls to the NOC have not been answered so far...  does
>>anyone have any further information?
>>
>>http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
>>
>
>
>
>
>





From tom at ninjabadger.net  Mon Nov  7 09:08:55 2011
From: tom at ninjabadger.net (Tom Hill)
Date: Mon, 07 Nov 2011 15:08:55 +0000
Subject: TATA problems?
In-Reply-To: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
Message-ID: <1320678667.4104.1.camel@teh-desktop>

On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
> We seem to be having some problems with our tata links - first seen in EU
> about 45 minutes ago, now we're seeing problems in NA.  I'm focused on DNS,
> so I'm seeing a lot of timeouts/servfails, but our networking folks are
> talking about links dropping.
> 
> Anyone else seeing oddness on the NA Internet right now?
> 
> http://downrightnow.com/ confirms - something is up.

There are widespread issues across the Internet; certain versions of
Juniper firmware have core dumped after seeing a particular BGP 'UPDATE'
message. 

(That's the running theory at least).

It's affected multiple service providers, globally, not just those
connected to TATA.

Tom



From jlewis at lewis.org  Mon Nov  7 09:12:30 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 7 Nov 2011 10:12:30 -0500 (EST)
Subject: Time Warner Telecom problems
In-Reply-To: <CAKXfWbRjoZwB8m_1ozSnS=ki5Z2GaXJE2NKQKUWo2f6YM5aAFQ@mail.gmail.com>
References: <CAKXfWbRjoZwB8m_1ozSnS=ki5Z2GaXJE2NKQKUWo2f6YM5aAFQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.1111071005540.24418@soloth.lewis.org>

On Mon, 7 Nov 2011, Peter Pauly wrote:

> Gizmodo is reporting problems at Time Warner Telecom .... we're suffering
> from it too and calls to the NOC have not been answered so far...  does
> anyone have any further information?
>
> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us

I noticed just a little while ago that we're having a lot of DNS fail. 
Initial findings were that several of the root-servers we were trying to 
reach via our TWTelecom link were unreachable after 2 hops into TWT.

  4  64-128-130-233.static.twtelecom.NET (64.128.130.233)  2.399 ms  2.298 ms  2.338 ms
  5  mia2-pr1-xe-1-3-0-0.us.twtelecom.net (66.192.253.18)  11.571 ms  11.552 ms  9.467 ms
  6  * * *
  7  * * *
  8  * * *

For instance, a.root-servers.net is pingable from a rackspace server, but 
not from our network (unless I shut off TWT, at which point it is, but 
it's apparently not the same a.root-servers.net instance rackspace sees). 
I assume this is one of the root-servers being anycast.

Shutting off our BGP with TWT didn't appear to help (though the 
root-servers became reachable)...so I assume there's more going on than 
just TWT routing fail.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From leigh.porter at ukbroadband.com  Mon Nov  7 09:29:30 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 7 Nov 2011 15:29:30 +0000
Subject: Performance Issues - PTR Records
In-Reply-To: <87fwi0118g.fsf@nemi.mork.no>
References: <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org>	<87ty6g1l4n.fsf@nemi.mork.no>
 <20111107.144648.74734213.sthaug@nethelp.no>
 <40117B81-3201-4649-BA7E-C6800D923535@ukbroadband.com>,
 <87fwi0118g.fsf@nemi.mork.no>
Message-ID: <53A4963F-4969-4A60-BF06-E690C7324863@ukbroadband.com>



On 7 Nov 2011, at 14:03, "Bj?rn Mork" <bjorn at mork.no> wrote:

> Leigh Porter <leigh.porter at ukbroadband.com> writes:
> 
>> Indeed, there is no way I would allow that either. But really,
>> providing a reverse zone and forward zone to match is a case of five
>> minutes and a shell script or a DNS that as Steinar said, will
>> synthesise results.
>> 
>> It's really not all that difficult..
> 
> No, not at all.  It's just totally pointless.  Any IPv6 address is just
> as pretty as a synthesized name.  Maybe even prettier. Do you prefer
> "2001:db8:1::2" or "20010db8000100000000000000000002.rev.example.com"?
> 
> If we're going to provide any reverse DNS for end users, then it is
> because we can create names which actually improves something.
> 
> 
> Bj?rn
> 
> 

Yup it is pointless.. Mine are all ipadrress.domain which is of course, pointless.. I suppose at least somebody would glean that perhaps its a home user rather than a business or server on that address but that's all.

With IPv6 arguably even more pointless as you say.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From rvandolson at esri.com  Mon Nov  7 09:28:18 2011
From: rvandolson at esri.com (Ray Van Dolson)
Date: Mon, 7 Nov 2011 07:28:18 -0800
Subject: Time Warner Telecom problems
In-Reply-To: <CAKXfWbRjoZwB8m_1ozSnS=ki5Z2GaXJE2NKQKUWo2f6YM5aAFQ@mail.gmail.com>
References: <CAKXfWbRjoZwB8m_1ozSnS=ki5Z2GaXJE2NKQKUWo2f6YM5aAFQ@mail.gmail.com>
Message-ID: <20111107152817.GA29715@esri.com>

On Mon, Nov 07, 2011 at 07:04:19AM -0800, Peter Pauly wrote:
> Gizmodo is reporting problems at Time Warner Telecom .... we're suffering
> from it too and calls to the NOC have not been answered so far...  does
> anyone have any further information?
> 
> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us

FWIW, my home TWC connection dropped this morning for about 15 minutes
(Southern California around 6:30AM'ish).  Still could ping the default
gateway, but packets weren't traversing much beyond that.

Didn't investigate further, just headed into work.

Ray


From jared at puck.nether.net  Mon Nov  7 09:31:31 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 7 Nov 2011 10:31:31 -0500
Subject: General Internet Instability
In-Reply-To: <1320678667.4104.1.camel@teh-desktop>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
Message-ID: <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>

On Nov 7, 2011, at 10:08 AM, Tom Hill wrote:

> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
>> We seem to be having some problems with our tata links - first seen in EU
>> about 45 minutes ago, now we're seeing problems in NA.  I'm focused on DNS,
>> so I'm seeing a lot of timeouts/servfails, but our networking folks are
>> talking about links dropping.
>> 
>> Anyone else seeing oddness on the NA Internet right now?
>> 
>> http://downrightnow.com/ confirms - something is up.
> 
> There are widespread issues across the Internet; certain versions of
> Juniper firmware have core dumped after seeing a particular BGP 'UPDATE'
> message. 
> 
> (That's the running theory at least).
> 
> It's affected multiple service providers, globally, not just those
> connected to TATA.


Pretty much any major BGP event will impact multiple providers.

A threshold you should use to view the general instability (which I find valuable, you may as well) is route views data.

If you look at the BGP UPDATES archive sizes, you can see when something happens, e.g.:

http://archive.routeviews.org/bgpdata/2011.11/UPDATES/

Take a look at the size of the updates.20111107.1400.bz2 file and the 1415 file.  They are abnormally large compared to a normal period of time.  This shows there were a lot of updates out there being processed and a reference to levels of instability.

If you are not feeding route views or similar community projects, please consider doing so.  It helps paint the view for those doing analysis.

- Jared

From nanog at maunier.org  Mon Nov  7 09:33:15 2011
From: nanog at maunier.org (Pierre-Yves Maunier)
Date: Mon, 7 Nov 2011 16:33:15 +0100
Subject: TATA problems?
In-Reply-To: <1320678667.4104.1.camel@teh-desktop>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
Message-ID: <CAEGdXrM+2rFXG2=d80kO_1ObtAv=24npNqZsLCTXUxeKS9q9yA@mail.gmail.com>

2011/11/7 Tom Hill <tom at ninjabadger.net>

> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
> > We seem to be having some problems with our tata links - first seen in EU
> > about 45 minutes ago, now we're seeing problems in NA.  I'm focused on
> DNS,
> > so I'm seeing a lot of timeouts/servfails, but our networking folks are
> > talking about links dropping.
> >
> > Anyone else seeing oddness on the NA Internet right now?
> >
> > http://downrightnow.com/ confirms - something is up.
>
> There are widespread issues across the Internet; certain versions of
> Juniper firmware have core dumped after seeing a particular BGP 'UPDATE'
> message.
>
> (That's the running theory at least).
>
> It's affected multiple service providers, globally, not just those
> connected to TATA.
>
> Tom
>
>
>
On our side all our 10.3R2.11 core dumped which made all our interfaces
flapped.
I've been told 10.4R1.9 is affected too.

-- 
Pierre-Yves Maunier

From leigh.porter at ukbroadband.com  Mon Nov  7 09:45:18 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 7 Nov 2011 15:45:18 +0000
Subject: TATA problems?
In-Reply-To: <CAEGdXrM+2rFXG2=d80kO_1ObtAv=24npNqZsLCTXUxeKS9q9yA@mail.gmail.com>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>,
 <CAEGdXrM+2rFXG2=d80kO_1ObtAv=24npNqZsLCTXUxeKS9q9yA@mail.gmail.com>
Message-ID: <7994AF08-0622-434F-974F-FC9269469176@ukbroadband.com>


My 10.4r1.9 boxes died also but I saw interfaces go down whilst bgpd seemed stable. 

-- 
Leigh


On 7 Nov 2011, at 15:34, "Pierre-Yves Maunier" <nanog at maunier.org> wrote:

> 2011/11/7 Tom Hill <tom at ninjabadger.net>
> 
>> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
>>> We seem to be having some problems with our tata links - first seen in EU
>>> about 45 minutes ago, now we're seeing problems in NA.  I'm focused on
>> DNS,
>>> so I'm seeing a lot of timeouts/servfails, but our networking folks are
>>> talking about links dropping.
>>> 
>>> Anyone else seeing oddness on the NA Internet right now?
>>> 
>>> http://downrightnow.com/ confirms - something is up.
>> 
>> There are widespread issues across the Internet; certain versions of
>> Juniper firmware have core dumped after seeing a particular BGP 'UPDATE'
>> message.
>> 
>> (That's the running theory at least).
>> 
>> It's affected multiple service providers, globally, not just those
>> connected to TATA.
>> 
>> Tom
>> 
>> 
>> 
> On our side all our 10.3R2.11 core dumped which made all our interfaces
> flapped.
> I've been told 10.4R1.9 is affected too.
> 
> -- 
> Pierre-Yves Maunier
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From jgreco at ns.sol.net  Mon Nov  7 09:54:25 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Mon, 7 Nov 2011 09:54:25 -0600 (CST)
Subject: Time Warner Telecom problems
In-Reply-To: <CAKXfWbRjoZwB8m_1ozSnS=ki5Z2GaXJE2NKQKUWo2f6YM5aAFQ@mail.gmail.com>
Message-ID: <201111071554.pA7FsPHb045359@aurora.sol.net>

> Gizmodo is reporting problems at Time Warner Telecom .... we're suffering
> from it too and calls to the NOC have not been answered so far...  does
> anyone have any further information?
> 
> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us

Actually, it looks to me like they mean "Time Warner", because that's
what they said.

The company once known as "Time Warner Telecom" has always been a
different entity, and hasn't been known as that in some time, now
being called "twtelecom."  Much of that company is what was once
known as inc.net, a Milwaukee area provider of the '90's.

Time Warner Cable appears to have experienced an implosion this morning,
being out of service for about 11 minutes.  During that time, packets
originating here in Milwaukee quickly died in Chicago;

 1  76.46.192.1  8.320 ms  9.900 ms  7.974 ms
 2  24.160.230.32  7.967 ms  5.975 ms  8.479 ms
 3  24.160.229.132  8.471 ms  7.969 ms  10.991 ms
 4  24.160.229.193  9.972 ms  9.973 ms
    24.160.229.197  9.985 ms
 5  * * *
 6  * * *

while packets destined for RR all seemed to be headed out to SJC, from
what I can tell.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From kelly at hawknetworks.com  Mon Nov  7 09:55:33 2011
From: kelly at hawknetworks.com (Kelly Kane)
Date: Mon, 7 Nov 2011 07:55:33 -0800
Subject: TATA problems?
In-Reply-To: <4EB7F3DF.5040006@interworx.nl>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <4EB7F3DF.5040006@interworx.nl>
Message-ID: <CAKfXD0zrH9TJkN=7doGe1uAq8zxVszyvtJYfLLTbiC6+UMy4ww@mail.gmail.com>

On Mon, Nov 7, 2011 at 07:06, Tim Vollebregt <tim at interworx.nl> wrote:
>
> On #IX there are rumours about Junos version 10.3R2.11 being core dumped and
> rebooted, which makes sense.

Perhaps related to Juniper PSN-2011-08-327? Did the whole router
reboot, or just the service module?

We saw one TATA session, and one Abovenet session flap.

Kelly


From blake at ispn.net  Mon Nov  7 10:02:13 2011
From: blake at ispn.net (Blake Hudson)
Date: Mon, 07 Nov 2011 10:02:13 -0600
Subject: Time Warner Telecom problems
In-Reply-To: <201111071554.pA7FsPHb045359@aurora.sol.net>
References: <201111071554.pA7FsPHb045359@aurora.sol.net>
Message-ID: <4EB80105.8060703@ispn.net>


Joe Greco wrote the following on 11/7/2011 9:54 AM:
>> Gizmodo is reporting problems at Time Warner Telecom .... we're suffering
>> from it too and calls to the NOC have not been answered so far...  does
>> anyone have any further information?
>>
>> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
> Actually, it looks to me like they mean "Time Warner", because that's
> what they said.
>
> The company once known as "Time Warner Telecom" has always been a
> different entity, and hasn't been known as that in some time, now
> being called "twtelecom."  Much of that company is what was once
> known as inc.net, a Milwaukee area provider of the '90's.
>
> Time Warner Cable appears to have experienced an implosion this morning,
> being out of service for about 11 minutes.  During that time, packets
> originating here in Milwaukee quickly died in Chicago;

Using the looking glass from TWtelecom, we saw 30-60min outage (roughly 
8:30AM to 9:30AM CST) between the Kansas City location and our own 
server room in Kansas City. Other TWtelecom locations appeared to be 
unaffected. Perhaps TWtelecom is served by Timewarner or shares 
equipment in KC. Either way, none of our KC customers who were served 
via TWtelecom or Timewarner were able to reach us. Packets would hit 
Level 3 Communications and die in either direction at the border between 
L3 and TW. FWIW, TW was showing a good BGP route to us and vise versa.
http://lglass.twtelecom.net/


From straterra at fuhell.com  Mon Nov  7 10:04:59 2011
From: straterra at fuhell.com (Thomas York)
Date: Mon, 7 Nov 2011 11:04:59 -0500
Subject: Time Warner Telecom problems
In-Reply-To: <4EB80105.8060703@ispn.net>
References: <201111071554.pA7FsPHb045359@aurora.sol.net>
 <4EB80105.8060703@ispn.net>
Message-ID: <c23401cc9d67$046baea0$0d430be0$@fuhell.com>

FWIW, We saw issues here in Indianapolis between TWTC and L3 up until a few minutes ago.

--Thomas York

-----Original Message-----
From: Blake Hudson [mailto:blake at ispn.net] 
Sent: Monday, November 07, 2011 11:02 AM
To: nanog at nanog.org
Subject: Re: Time Warner Telecom problems


Joe Greco wrote the following on 11/7/2011 9:54 AM:
>> Gizmodo is reporting problems at Time Warner Telecom .... we're 
>> suffering from it too and calls to the NOC have not been answered so 
>> far...  does anyone have any further information?
>>
>> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
> Actually, it looks to me like they mean "Time Warner", because that's 
> what they said.
>
> The company once known as "Time Warner Telecom" has always been a 
> different entity, and hasn't been known as that in some time, now 
> being called "twtelecom."  Much of that company is what was once known 
> as inc.net, a Milwaukee area provider of the '90's.
>
> Time Warner Cable appears to have experienced an implosion this 
> morning, being out of service for about 11 minutes.  During that time, 
> packets originating here in Milwaukee quickly died in Chicago;

Using the looking glass from TWtelecom, we saw 30-60min outage (roughly 8:30AM to 9:30AM CST) between the Kansas City location and our own server room in Kansas City. Other TWtelecom locations appeared to be unaffected. Perhaps TWtelecom is served by Timewarner or shares equipment in KC. Either way, none of our KC customers who were served via TWtelecom or Timewarner were able to reach us. Packets would hit Level 3 Communications and die in either direction at the border between
L3 and TW. FWIW, TW was showing a good BGP route to us and vise versa.
http://lglass.twtelecom.net/




From jlewis at lewis.org  Mon Nov  7 10:06:57 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 7 Nov 2011 11:06:57 -0500 (EST)
Subject: Time Warner Telecom problems
In-Reply-To: <0EB48B40EDC6C643AC36ADE613C78DEF0FEF97B5@SRVMSXMBDEN4.ad.twtelecom.com>
References: <CAKXfWbRjoZwB8m_1ozSnS=ki5Z2GaXJE2NKQKUWo2f6YM5aAFQ@mail.gmail.com>
 <0EB48B40EDC6C643AC36ADE613C78DEF0FEF97B5@SRVMSXMBDEN4.ad.twtelecom.com>
Message-ID: <Pine.LNX.4.61.1111071029150.24418@soloth.lewis.org>

On Mon, 7 Nov 2011, Calkins, Mark wrote:

> I believe you are referring to Time Warner Cable.  There is no such thing as Time Warner Telecom anymore.

It's just TW Telecom now.

http://www.twtelecom.com/

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From jpchaba at cs.wisc.edu  Mon Nov  7 10:07:52 2011
From: jpchaba at cs.wisc.edu (Joseph Chabarek)
Date: Mon, 07 Nov 2011 10:07:52 -0600
Subject: Router and interface naming convention survey
Message-ID: <4EB80258.6080501@cs.wisc.edu>

I am doing a survey to see what naming conventions are used for routers 
and router interfaces as part of a measurement study that I am 
conducting as a student at the University of Wisconsin Madison. If you 
are interested in participating please fill out my form at:

https://docs.google.com/spreadsheet/viewform?formkey=dE1OYmVGcjlxV1YtZjB1QmJ4bmg1aUE6MQ

I am aware that this issue has been discussed extensively on nanog (and 
other lists). The purpose of this survey is to see in a structured 
manner which networks use which conventions, and get an idea for how 
automated the process of PTR record generation is across different 
providers. I am happy to provide high level results from the survey to 
anyone that is interested. Thanks for any feedback!

-Joe
http://www.cs.wisc.edu/~jpchaba


From cb.list6 at gmail.com  Mon Nov  7 10:09:24 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Mon, 7 Nov 2011 08:09:24 -0800
Subject: Cell-based OOB management devices
In-Reply-To: <FCD26398C5EDE746BFC47F43EA52A173054DA958@dino.ad.hostasaurus.com>
References: <FCD26398C5EDE746BFC47F43EA52A173054DA958@dino.ad.hostasaurus.com>
Message-ID: <CAD6AjGTH0N3_V-gnP3m0D6bS5hLYJCOfT_gyNeKzw9fP+FYdGw@mail.gmail.com>

On Nov 6, 2011 10:15 PM, "David Hubbard" <dhubbard at dino.hostasaurus.com>
wrote:
>
> Hi all, I am looking at cellular-based devices as a higher
> speed alternative to dial-up backup access methods for
> out of band management during emergencies.  I was
> wondering if anyone had experiences with such devices
> they could share?
>
> Devices I've found include Sierra Wireless AirLink Raven X,
> Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G.  I
> have no experience with any but they all appear to support
> the Sprint network which I assume would be ideal due to
> not having usage caps on data (currently).  The Opengear
> device runs linux and has four serial ports, a usb port
> for additional storage and ethernet, so it seems to have
> some small advantages over the others since it could double
> as an emergency self-contained management station you can
> SSH into and run diagnostics from.  All appear to have
> VPN/gateway support.
>
> What none of them are clear on is how you would connect
> to it over cellular since I assume you're just paying for
> a typical data plan and it will randomly obtain IP
> addresses.  Maybe some type of dynamic dns service so you
> can easily figure out your device's current IP?  How
> stable is the access to the device?  Any idea if any of
> them can do ipv6?
>

Another good question is if the 3g modem is firewalled by the mobile
provider so that incoming connections are blocked.

Cb
> Thanks!
>
> David
>
>

From todd at hatescomputers.org  Mon Nov  7 10:09:35 2011
From: todd at hatescomputers.org (Todd Snyder)
Date: Mon, 7 Nov 2011 11:09:35 -0500
Subject: General Internet Instability
In-Reply-To: <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
Message-ID: <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>

Can anyone point to any authoritative updates about this?

On Mon, Nov 7, 2011 at 10:31 AM, Jared Mauch <jared at puck.nether.net> wrote:

> On Nov 7, 2011, at 10:08 AM, Tom Hill wrote:
>
> > On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
> >> We seem to be having some problems with our tata links - first seen in
> EU
> >> about 45 minutes ago, now we're seeing problems in NA.  I'm focused on
> DNS,
> >> so I'm seeing a lot of timeouts/servfails, but our networking folks are
> >> talking about links dropping.
> >>
> >> Anyone else seeing oddness on the NA Internet right now?
> >>
> >> http://downrightnow.com/ confirms - something is up.
> >
> > There are widespread issues across the Internet; certain versions of
> > Juniper firmware have core dumped after seeing a particular BGP 'UPDATE'
> > message.
> >
> > (That's the running theory at least).
> >
> > It's affected multiple service providers, globally, not just those
> > connected to TATA.
>
>
> Pretty much any major BGP event will impact multiple providers.
>
> A threshold you should use to view the general instability (which I find
> valuable, you may as well) is route views data.
>
> If you look at the BGP UPDATES archive sizes, you can see when something
> happens, e.g.:
>
> http://archive.routeviews.org/bgpdata/2011.11/UPDATES/
>
> Take a look at the size of the updates.20111107.1400.bz2 file and the 1415
> file.  They are abnormally large compared to a normal period of time.  This
> shows there were a lot of updates out there being processed and a reference
> to levels of instability.
>
> If you are not feeding route views or similar community projects, please
> consider doing so.  It helps paint the view for those doing analysis.
>
> - Jared
>

From accesss801 at gmail.com  Mon Nov  7 10:08:42 2011
From: accesss801 at gmail.com (Dan)
Date: Mon, 7 Nov 2011 09:08:42 -0700
Subject: TATA problems?
In-Reply-To: <CAKfXD0zrH9TJkN=7doGe1uAq8zxVszyvtJYfLLTbiC6+UMy4ww@mail.gmail.com>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <4EB7F3DF.5040006@interworx.nl>
 <CAKfXD0zrH9TJkN=7doGe1uAq8zxVszyvtJYfLLTbiC6+UMy4ww@mail.gmail.com>
Message-ID: <2CC473DD-67DA-425C-A47C-0E33222E8ABA@gmail.com>

We got a panic message about the PFE that core'd and looks like it restarted our FPC's.

JUNOS 10.2R2.11

-Dan

On Nov 7, 2011, at 8:55 AM, Kelly Kane wrote:

> On Mon, Nov 7, 2011 at 07:06, Tim Vollebregt <tim at interworx.nl> wrote:
>> 
>> On #IX there are rumours about Junos version 10.3R2.11 being core dumped and
>> rebooted, which makes sense.
> 
> Perhaps related to Juniper PSN-2011-08-327? Did the whole router
> reboot, or just the service module?
> 
> We saw one TATA session, and one Abovenet session flap.
> 
> Kelly
> 



From bhmccie at gmail.com  Mon Nov  7 10:14:32 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Mon, 07 Nov 2011 10:14:32 -0600
Subject: General Internet Instability
In-Reply-To: <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
 <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
Message-ID: <4EB803E8.5070805@gmail.com>

I'm struggling to do the same. All the various "Internet Health" sites 
show(ed) some upticks in negative performance but I don't have any 
specifics. We are a Gomez customer and Gomez is showing issues In St. 
Louis (SAVVIS) and Philly (L3) that specifically impacts the 
availability of our applications but it's not clear on the underlying 
reason. I'm giving cautious updates to management because even though 
it's obvious something is going on I don't have anything official except 
random email threads. Looking for more insight before misinforming 
management.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/07/2011 10:09 AM, Todd Snyder wrote:
> Can anyone point to any authoritative updates about this?
>
> On Mon, Nov 7, 2011 at 10:31 AM, Jared Mauch<jared at puck.nether.net>  wrote:
>
>    
>> On Nov 7, 2011, at 10:08 AM, Tom Hill wrote:
>>
>>      
>>> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
>>>        
>>>> We seem to be having some problems with our tata links - first seen in
>>>>          
>> EU
>>      
>>>> about 45 minutes ago, now we're seeing problems in NA.  I'm focused on
>>>>          
>> DNS,
>>      
>>>> so I'm seeing a lot of timeouts/servfails, but our networking folks are
>>>> talking about links dropping.
>>>>
>>>> Anyone else seeing oddness on the NA Internet right now?
>>>>
>>>> http://downrightnow.com/ confirms - something is up.
>>>>          
>>> There are widespread issues across the Internet; certain versions of
>>> Juniper firmware have core dumped after seeing a particular BGP 'UPDATE'
>>> message.
>>>
>>> (That's the running theory at least).
>>>
>>> It's affected multiple service providers, globally, not just those
>>> connected to TATA.
>>>        
>>
>> Pretty much any major BGP event will impact multiple providers.
>>
>> A threshold you should use to view the general instability (which I find
>> valuable, you may as well) is route views data.
>>
>> If you look at the BGP UPDATES archive sizes, you can see when something
>> happens, e.g.:
>>
>> http://archive.routeviews.org/bgpdata/2011.11/UPDATES/
>>
>> Take a look at the size of the updates.20111107.1400.bz2 file and the 1415
>> file.  They are abnormally large compared to a normal period of time.  This
>> shows there were a lot of updates out there being processed and a reference
>> to levels of instability.
>>
>> If you are not feeding route views or similar community projects, please
>> consider doing so.  It helps paint the view for those doing analysis.
>>
>> - Jared
>>
>>      

From jrex at CS.Princeton.EDU  Mon Nov  7 10:16:52 2011
From: jrex at CS.Princeton.EDU (Jennifer Rexford)
Date: Mon, 7 Nov 2011 11:16:52 -0500
Subject: Router and interface naming convention survey
In-Reply-To: <4EB80258.6080501@cs.wisc.edu>
References: <4EB80258.6080501@cs.wisc.edu>
Message-ID: <E2D409A7-2FC5-42C2-BD3C-F9AE273FBBFE@cs.princeton.edu>

Joe,

> I am doing a survey to see what naming conventions are used for routers and router interfaces as part of a measurement study

On a related note, you might be interested in a study we did a few years ago about errors in naming router interfaces, where a router in one location has a name suggestive of a different location (e.g., because a network administrator did not update the DNS entries for the interface names).  See

  Ming Zhang, Yaoping Ruan, Vivek Pai, and Jennifer Rexford, "How DNS misnaming distorts Internet topology mapping," Proc. USENIX Annual Technical Conference, May/June 2006.
    http://www.cs.princeton.edu/~jrex/papers/dns06.pdf
    http://www.cs.princeton.edu/~jrex/talks/dns06.ppt

In particular, we found that a few "errors" in the DNS names for router interfaces could lead to significant distortions in measurement studies -- e.g., a study might wrongly conclude that path inflation is very high because traceroute measurements wrongly suggested that the traffic traverses a particular sequence of cities...

Best wishes...

-- Jen

From rgolodner at infratection.com  Mon Nov  7 10:27:07 2011
From: rgolodner at infratection.com (Richard Golodner)
Date: Mon, 07 Nov 2011 10:27:07 -0600
Subject: General Internet Instability
In-Reply-To: <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
 <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
Message-ID: <1320683227.2220.108.camel@Andromeda>

On Mon, 2011-11-07 at 11:09 -0500, Todd Snyder wrote:
> Can anyone point to any authoritative updates about this?

	I think Jared's suggestion was about as close as your going to get for
right now. Look at the size of the files he mentioned as compared to the
average size of the others.
	Hopefully someone will come forth with an authoritative answer later
today.
	Richard Golodner



From jared at puck.nether.net  Mon Nov  7 10:37:47 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 7 Nov 2011 11:37:47 -0500
Subject: General Internet Instability
In-Reply-To: <1320683227.2220.108.camel@Andromeda>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
 <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
 <1320683227.2220.108.camel@Andromeda>
Message-ID: <B0528F35-1374-4FD4-A452-BA2B3EAF63C9@puck.nether.net>


On Nov 7, 2011, at 11:27 AM, Richard Golodner wrote:

> On Mon, 2011-11-07 at 11:09 -0500, Todd Snyder wrote:
>> Can anyone point to any authoritative updates about this?
> 
> 	I think Jared's suggestion was about as close as your going to get for
> right now. Look at the size of the files he mentioned as compared to the
> average size of the others.
> 	Hopefully someone will come forth with an authoritative answer later
> today.
> 	Richard Golodner
> 

One can do some analysis of the files to determine what prefixes and autonomous
system neighbors were impacted.

I can do some of this as I have some other tools that quickly process this data
if people are interested.   Please send those replies/votes off list to me directly.

- Jared

From todd at hatescomputers.org  Mon Nov  7 10:40:03 2011
From: todd at hatescomputers.org (Todd Snyder)
Date: Mon, 7 Nov 2011 11:40:03 -0500
Subject: General Internet Instability
In-Reply-To: <1320683227.2220.108.camel@Andromeda>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
 <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
 <1320683227.2220.108.camel@Andromeda>
Message-ID: <CAPQUSnPRruLnyaRXsKJ12W==oW=mYWUR01D7JfikEhTYaQ=sfA@mail.gmail.com>

On Mon, Nov 7, 2011 at 11:27 AM, Richard Golodner <
rgolodner at infratection.com> wrote:

> On Mon, 2011-11-07 at 11:09 -0500, Todd Snyder wrote:
> > Can anyone point to any authoritative updates about this?
>
>         I think Jared's suggestion was about as close as your going to get
> for
> right now. Look at the size of the files he mentioned as compared to the
> average size of the others.
>        Hopefully someone will come forth with an authoritative answer later
> today.
>         Richard Golodner
>
>
Management don't understand or care about BGP updates, they just want to
know if the problem is ours, and if it's not, who to blame :)

thank goodness for NANOG - updates here have been helpful explaining things
to management.

t.

From dispensa at phonefactor.com  Mon Nov  7 10:41:59 2011
From: dispensa at phonefactor.com (Steve Dispensa)
Date: Mon, 7 Nov 2011 10:41:59 -0600
Subject: NANOG Digest, Vol 46, Issue 15
In-Reply-To: <mailman.13480.1320681914.1873.nanog@nanog.org>
References: <mailman.13480.1320681914.1873.nanog@nanog.org>
Message-ID: <0F7F9A82BB0DBB4396A9F8386D0E0612071F65A3@pos-exch1.corp.positivenetworks.net>

Level 3 was down in KC, Chi, and San Jose (at least) for us between
about 8:10 and 8:40, plus or minus. Brought down SureWest in KC too.

 -Steve

> -----Original Message-----
> From: nanog-request at nanog.org [mailto:nanog-request at nanog.org]
> Sent: Monday, November 07, 2011 10:05 AM
> To: nanog at nanog.org
> Subject: NANOG Digest, Vol 46, Issue 15
> 
> Send NANOG mailing list submissions to
> 	nanog at nanog.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://mailman.nanog.org/mailman/listinfo/nanog
> or, via email, send a message with subject or body 'help' to
> 	nanog-request at nanog.org
> 
> You can reach the person managing the list at
> 	nanog-owner at nanog.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NANOG digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Time Warner Telecom problems (Jon Lewis)
>    2. Re: Performance Issues - PTR Records (Leigh Porter)
>    3. Re: Time Warner Telecom problems (Ray Van Dolson)
>    4. General Internet Instability (Jared Mauch)
>    5. Re: TATA problems? (Pierre-Yves Maunier)
>    6. Re: TATA problems? (Leigh Porter)
>    7. Re: Time Warner Telecom problems (Joe Greco)
>    8. Re: TATA problems? (Kelly Kane)
>    9. Re: Time Warner Telecom problems (Blake Hudson)
>   10. RE: Time Warner Telecom problems (Thomas York)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 7 Nov 2011 10:12:30 -0500 (EST)
> From: Jon Lewis <jlewis at lewis.org>
> To: Peter Pauly <ppauly at gmail.com>
> Cc: nanog at nanog.org
> Subject: Re: Time Warner Telecom problems
> Message-ID: <Pine.LNX.4.61.1111071005540.24418 at soloth.lewis.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> 
> On Mon, 7 Nov 2011, Peter Pauly wrote:
> 
> > Gizmodo is reporting problems at Time Warner Telecom .... we're
> suffering
> > from it too and calls to the NOC have not been answered so far...
does
> > anyone have any further information?
> >
> > http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
> 
> I noticed just a little while ago that we're having a lot of DNS fail.
> Initial findings were that several of the root-servers we were trying
to
> reach via our TWTelecom link were unreachable after 2 hops into TWT.
> 
>   4  64-128-130-233.static.twtelecom.NET (64.128.130.233)  2.399 ms
2.298
> ms  2.338 ms
>   5  mia2-pr1-xe-1-3-0-0.us.twtelecom.net (66.192.253.18)  11.571 ms
> 11.552 ms  9.467 ms
>   6  * * *
>   7  * * *
>   8  * * *
> 
> For instance, a.root-servers.net is pingable from a rackspace server,
but
> not from our network (unless I shut off TWT, at which point it is, but
> it's apparently not the same a.root-servers.net instance rackspace
sees).
> I assume this is one of the root-servers being anycast.
> 
> Shutting off our BGP with TWT didn't appear to help (though the
> root-servers became reachable)...so I assume there's more going on
than
> just TWT routing fail.
> 
> ----------------------------------------------------------------------
>   Jon Lewis, MCP :)           |  I route
>   Senior Network Engineer     |  therefore you are
>   Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 7 Nov 2011 15:29:30 +0000
> From: Leigh Porter <leigh.porter at ukbroadband.com>
> To: Bj?rn Mork <bjorn at mork.no>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Subject: Re: Performance Issues - PTR Records
> Message-ID: <53A4963F-4969-4A60-BF06-E690C7324863 at ukbroadband.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 
> 
> On 7 Nov 2011, at 14:03, "Bj?rn Mork" <bjorn at mork.no> wrote:
> 
> > Leigh Porter <leigh.porter at ukbroadband.com> writes:
> >
> >> Indeed, there is no way I would allow that either. But really,
> >> providing a reverse zone and forward zone to match is a case of
five
> >> minutes and a shell script or a DNS that as Steinar said, will
> >> synthesise results.
> >>
> >> It's really not all that difficult..
> >
> > No, not at all.  It's just totally pointless.  Any IPv6 address is
just
> > as pretty as a synthesized name.  Maybe even prettier. Do you prefer
> > "2001:db8:1::2" or
"20010db8000100000000000000000002.rev.example.com"?
> >
> > If we're going to provide any reverse DNS for end users, then it is
> > because we can create names which actually improves something.
> >
> >
> > Bj?rn
> >
> >
> 
> Yup it is pointless.. Mine are all ipadrress.domain which is of
course,
> pointless.. I suppose at least somebody would glean that perhaps its a
> home user rather than a business or server on that address but that's
all.
> 
> With IPv6 arguably even more pointless as you say.
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 7 Nov 2011 07:28:18 -0800
> From: Ray Van Dolson <rvandolson at esri.com>
> To: nanog at nanog.org
> Subject: Re: Time Warner Telecom problems
> Message-ID: <20111107152817.GA29715 at esri.com>
> Content-Type: text/plain; charset=us-ascii
> 
> On Mon, Nov 07, 2011 at 07:04:19AM -0800, Peter Pauly wrote:
> > Gizmodo is reporting problems at Time Warner Telecom .... we're
> suffering
> > from it too and calls to the NOC have not been answered so far...
does
> > anyone have any further information?
> >
> > http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
> 
> FWIW, my home TWC connection dropped this morning for about 15 minutes
> (Southern California around 6:30AM'ish).  Still could ping the default
> gateway, but packets weren't traversing much beyond that.
> 
> Didn't investigate further, just headed into work.
> 
> Ray
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 7 Nov 2011 10:31:31 -0500
> From: Jared Mauch <jared at puck.nether.net>
> To: Tom Hill <tom at ninjabadger.net>
> Cc: nanog at nanog.org
> Subject: General Internet Instability
> Message-ID: <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD at puck.nether.net>
> Content-Type: text/plain; charset=us-ascii
> 
> On Nov 7, 2011, at 10:08 AM, Tom Hill wrote:
> 
> > On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
> >> We seem to be having some problems with our tata links - first seen
in
> EU
> >> about 45 minutes ago, now we're seeing problems in NA.  I'm focused
on
> DNS,
> >> so I'm seeing a lot of timeouts/servfails, but our networking folks
are
> >> talking about links dropping.
> >>
> >> Anyone else seeing oddness on the NA Internet right now?
> >>
> >> http://downrightnow.com/ confirms - something is up.
> >
> > There are widespread issues across the Internet; certain versions of
> > Juniper firmware have core dumped after seeing a particular BGP
'UPDATE'
> > message.
> >
> > (That's the running theory at least).
> >
> > It's affected multiple service providers, globally, not just those
> > connected to TATA.
> 
> 
> Pretty much any major BGP event will impact multiple providers.
> 
> A threshold you should use to view the general instability (which I
find
> valuable, you may as well) is route views data.
> 
> If you look at the BGP UPDATES archive sizes, you can see when
something
> happens, e.g.:
> 
> http://archive.routeviews.org/bgpdata/2011.11/UPDATES/
> 
> Take a look at the size of the updates.20111107.1400.bz2 file and the
1415
> file.  They are abnormally large compared to a normal period of time.
> This shows there were a lot of updates out there being processed and a
> reference to levels of instability.
> 
> If you are not feeding route views or similar community projects,
please
> consider doing so.  It helps paint the view for those doing analysis.
> 
> - Jared
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Mon, 7 Nov 2011 16:33:15 +0100
> From: Pierre-Yves Maunier <nanog at maunier.org>
> To: Tom Hill <tom at ninjabadger.net>
> Cc: nanog at nanog.org
> Subject: Re: TATA problems?
> Message-ID:
>
<CAEGdXrM+2rFXG2=d80kO_1ObtAv=24npNqZsLCTXUxeKS9q9yA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> 2011/11/7 Tom Hill <tom at ninjabadger.net>
> 
> > On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
> > > We seem to be having some problems with our tata links - first
seen in
> EU
> > > about 45 minutes ago, now we're seeing problems in NA.  I'm
focused on
> > DNS,
> > > so I'm seeing a lot of timeouts/servfails, but our networking
folks
> are
> > > talking about links dropping.
> > >
> > > Anyone else seeing oddness on the NA Internet right now?
> > >
> > > http://downrightnow.com/ confirms - something is up.
> >
> > There are widespread issues across the Internet; certain versions of
> > Juniper firmware have core dumped after seeing a particular BGP
'UPDATE'
> > message.
> >
> > (That's the running theory at least).
> >
> > It's affected multiple service providers, globally, not just those
> > connected to TATA.
> >
> > Tom
> >
> >
> >
> On our side all our 10.3R2.11 core dumped which made all our
interfaces
> flapped.
> I've been told 10.4R1.9 is affected too.
> 
> --
> Pierre-Yves Maunier
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Mon, 7 Nov 2011 15:45:18 +0000
> From: Leigh Porter <leigh.porter at ukbroadband.com>
> To: Pierre-Yves Maunier <nanog at maunier.org>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> Subject: Re: TATA problems?
> Message-ID: <7994AF08-0622-434F-974F-FC9269469176 at ukbroadband.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> My 10.4r1.9 boxes died also but I saw interfaces go down whilst bgpd
> seemed stable.
> 
> --
> Leigh
> 
> 
> On 7 Nov 2011, at 15:34, "Pierre-Yves Maunier" <nanog at maunier.org>
wrote:
> 
> > 2011/11/7 Tom Hill <tom at ninjabadger.net>
> >
> >> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
> >>> We seem to be having some problems with our tata links - first
seen in
> EU
> >>> about 45 minutes ago, now we're seeing problems in NA.  I'm
focused on
> >> DNS,
> >>> so I'm seeing a lot of timeouts/servfails, but our networking
folks
> are
> >>> talking about links dropping.
> >>>
> >>> Anyone else seeing oddness on the NA Internet right now?
> >>>
> >>> http://downrightnow.com/ confirms - something is up.
> >>
> >> There are widespread issues across the Internet; certain versions
of
> >> Juniper firmware have core dumped after seeing a particular BGP
> 'UPDATE'
> >> message.
> >>
> >> (That's the running theory at least).
> >>
> >> It's affected multiple service providers, globally, not just those
> >> connected to TATA.
> >>
> >> Tom
> >>
> >>
> >>
> > On our side all our 10.3R2.11 core dumped which made all our
interfaces
> > flapped.
> > I've been told 10.4R1.9 is affected too.
> >
> > --
> > Pierre-Yves Maunier
> >
> >
______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security
System.
> > For more information please visit http://www.messagelabs.com/email
> >
______________________________________________________________________
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Mon, 7 Nov 2011 09:54:25 -0600 (CST)
> From: Joe Greco <jgreco at ns.sol.net>
> To: ppauly at gmail.com (Peter Pauly)
> Cc: nanog at nanog.org
> Subject: Re: Time Warner Telecom problems
> Message-ID: <201111071554.pA7FsPHb045359 at aurora.sol.net>
> Content-Type: text/plain; charset=us-ascii
> 
> > Gizmodo is reporting problems at Time Warner Telecom .... we're
> suffering
> > from it too and calls to the NOC have not been answered so far...
does
> > anyone have any further information?
> >
> > http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
> 
> Actually, it looks to me like they mean "Time Warner", because that's
> what they said.
> 
> The company once known as "Time Warner Telecom" has always been a
> different entity, and hasn't been known as that in some time, now
> being called "twtelecom."  Much of that company is what was once
> known as inc.net, a Milwaukee area provider of the '90's.
> 
> Time Warner Cable appears to have experienced an implosion this
morning,
> being out of service for about 11 minutes.  During that time, packets
> originating here in Milwaukee quickly died in Chicago;
> 
>  1  76.46.192.1  8.320 ms  9.900 ms  7.974 ms
>  2  24.160.230.32  7.967 ms  5.975 ms  8.479 ms
>  3  24.160.229.132  8.471 ms  7.969 ms  10.991 ms
>  4  24.160.229.193  9.972 ms  9.973 ms
>     24.160.229.197  9.985 ms
>  5  * * *
>  6  * * *
> 
> while packets destined for RR all seemed to be headed out to SJC, from
> what I can tell.
> 
> ... JG
> --
> Joe Greco - sol.net Network Services - Milwaukee, WI -
http://www.sol.net
> "We call it the 'one bite at the apple' rule. Give me one chance [and]
> then I
> won't contact you again." - Direct Marketing Ass'n position on e-mail
> spam(CNN)
> With 24 million small businesses in the US alone, that's way too many
> apples.
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Mon, 7 Nov 2011 07:55:33 -0800
> From: Kelly Kane <kelly at hawknetworks.com>
> To: Tim Vollebregt <tim at interworx.nl>
> Cc: nanog at nanog.org
> Subject: Re: TATA problems?
> Message-ID:
>
<CAKfXD0zrH9TJkN=7doGe1uAq8zxVszyvtJYfLLTbiC6+UMy4ww at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> On Mon, Nov 7, 2011 at 07:06, Tim Vollebregt <tim at interworx.nl> wrote:
> >
> > On #IX there are rumours about Junos version 10.3R2.11 being core
dumped
> and
> > rebooted, which makes sense.
> 
> Perhaps related to Juniper PSN-2011-08-327? Did the whole router
> reboot, or just the service module?
> 
> We saw one TATA session, and one Abovenet session flap.
> 
> Kelly
> 
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Mon, 07 Nov 2011 10:02:13 -0600
> From: Blake Hudson <blake at ispn.net>
> To: nanog at nanog.org
> Subject: Re: Time Warner Telecom problems
> Message-ID: <4EB80105.8060703 at ispn.net>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> 
> Joe Greco wrote the following on 11/7/2011 9:54 AM:
> >> Gizmodo is reporting problems at Time Warner Telecom .... we're
> suffering
> >> from it too and calls to the NOC have not been answered so far...
does
> >> anyone have any further information?
> >>
> >> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
> > Actually, it looks to me like they mean "Time Warner", because
that's
> > what they said.
> >
> > The company once known as "Time Warner Telecom" has always been a
> > different entity, and hasn't been known as that in some time, now
> > being called "twtelecom."  Much of that company is what was once
> > known as inc.net, a Milwaukee area provider of the '90's.
> >
> > Time Warner Cable appears to have experienced an implosion this
morning,
> > being out of service for about 11 minutes.  During that time,
packets
> > originating here in Milwaukee quickly died in Chicago;
> 
> Using the looking glass from TWtelecom, we saw 30-60min outage
(roughly
> 8:30AM to 9:30AM CST) between the Kansas City location and our own
> server room in Kansas City. Other TWtelecom locations appeared to be
> unaffected. Perhaps TWtelecom is served by Timewarner or shares
> equipment in KC. Either way, none of our KC customers who were served
> via TWtelecom or Timewarner were able to reach us. Packets would hit
> Level 3 Communications and die in either direction at the border
between
> L3 and TW. FWIW, TW was showing a good BGP route to us and vise versa.
> http://lglass.twtelecom.net/
> 
> 
> 
> ------------------------------
> 
> Message: 10
> Date: Mon, 7 Nov 2011 11:04:59 -0500
> From: "Thomas York" <straterra at fuhell.com>
> To: "'Blake Hudson'" <blake at ispn.net>,	<nanog at nanog.org>
> Subject: RE: Time Warner Telecom problems
> Message-ID: <c23401cc9d67$046baea0$0d430be0$@fuhell.com>
> Content-Type: text/plain;	charset="utf-8"
> 
> FWIW, We saw issues here in Indianapolis between TWTC and L3 up until
a
> few minutes ago.
> 
> --Thomas York
> 
> -----Original Message-----
> From: Blake Hudson [mailto:blake at ispn.net]
> Sent: Monday, November 07, 2011 11:02 AM
> To: nanog at nanog.org
> Subject: Re: Time Warner Telecom problems
> 
> 
> Joe Greco wrote the following on 11/7/2011 9:54 AM:
> >> Gizmodo is reporting problems at Time Warner Telecom .... we're
> >> suffering from it too and calls to the NOC have not been answered
so
> >> far...  does anyone have any further information?
> >>
> >> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
> > Actually, it looks to me like they mean "Time Warner", because
that's
> > what they said.
> >
> > The company once known as "Time Warner Telecom" has always been a
> > different entity, and hasn't been known as that in some time, now
> > being called "twtelecom."  Much of that company is what was once
known
> > as inc.net, a Milwaukee area provider of the '90's.
> >
> > Time Warner Cable appears to have experienced an implosion this
> > morning, being out of service for about 11 minutes.  During that
time,
> > packets originating here in Milwaukee quickly died in Chicago;
> 
> Using the looking glass from TWtelecom, we saw 30-60min outage
(roughly
> 8:30AM to 9:30AM CST) between the Kansas City location and our own
server
> room in Kansas City. Other TWtelecom locations appeared to be
unaffected.
> Perhaps TWtelecom is served by Timewarner or shares equipment in KC.
> Either way, none of our KC customers who were served via TWtelecom or
> Timewarner were able to reach us. Packets would hit Level 3
Communications
> and die in either direction at the border between
> L3 and TW. FWIW, TW was showing a good BGP route to us and vise versa.
> http://lglass.twtelecom.net/
> 
> 
> 
> 
> 
> End of NANOG Digest, Vol 46, Issue 15
> *************************************


From leigh.porter at ukbroadband.com  Mon Nov  7 10:43:52 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 7 Nov 2011 16:43:52 +0000
Subject: General Internet Instability
In-Reply-To: <CAPQUSnPRruLnyaRXsKJ12W==oW=mYWUR01D7JfikEhTYaQ=sfA@mail.gmail.com>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
 <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
 <1320683227.2220.108.camel@Andromeda>,
 <CAPQUSnPRruLnyaRXsKJ12W==oW=mYWUR01D7JfikEhTYaQ=sfA@mail.gmail.com>
Message-ID: <F21D4282-E69F-4A21-834D-55ED5AD1F84D@ukbroadband.com>



On 7 Nov 2011, at 16:41, "Todd Snyder" <todd at hatescomputers.org> wrote:

> On Mon, Nov 7, 2011 at 11:27 AM, Richard Golodner <
> rgolodner at infratection.com> wrote:
> 
>> On Mon, 2011-11-07 at 11:09 -0500, Todd Snyder wrote:
>>> Can anyone point to any authoritative updates about this?
>> 
>>        I think Jared's suggestion was about as close as your going to get
>> for
>> right now. Look at the size of the files he mentioned as compared to the
>> average size of the others.
>>       Hopefully someone will come forth with an authoritative answer later
>> today.
>>        Richard Golodner
>> 
>> 
> Management don't understand or care about BGP updates, they just want to
> know if the problem is ours, and if it's not, who to blame :)
> 
> thank goodness for NANOG - updates here have been helpful explaining things
> to management.
> 
> t.
> 

Just blame Shub Internet..

Oh no, I've said it now!

--
Leigh


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From bhmccie at gmail.com  Mon Nov  7 10:41:13 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Mon, 07 Nov 2011 10:41:13 -0600
Subject: General Internet Instability
In-Reply-To: <1320683227.2220.108.camel@Andromeda>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
 <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
 <1320683227.2220.108.camel@Andromeda>
Message-ID: <4EB80A29.1070006@gmail.com>

So the file size was 30% higher implies that the number of updates is 
larger and therefore there is instability? I see the logic but if you 
scroll thru that page (the whole month of November) there are tons of 
 >1M files. Trying to see what is different about today....

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/07/2011 10:27 AM, Richard Golodner wrote:
> On Mon, 2011-11-07 at 11:09 -0500, Todd Snyder wrote:
>    
>> Can anyone point to any authoritative updates about this?
>>      
> 	I think Jared's suggestion was about as close as your going to get for
> right now. Look at the size of the files he mentioned as compared to the
> average size of the others.
> 	Hopefully someone will come forth with an authoritative answer later
> today.
> 	Richard Golodner
>
>
>    

From nanog at maunier.org  Mon Nov  7 10:43:43 2011
From: nanog at maunier.org (Pierre-Yves Maunier)
Date: Mon, 7 Nov 2011 17:43:43 +0100
Subject: TATA problems?
In-Reply-To: <CAKfXD0zrH9TJkN=7doGe1uAq8zxVszyvtJYfLLTbiC6+UMy4ww@mail.gmail.com>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <4EB7F3DF.5040006@interworx.nl>
 <CAKfXD0zrH9TJkN=7doGe1uAq8zxVszyvtJYfLLTbiC6+UMy4ww@mail.gmail.com>
Message-ID: <CAEGdXrPBjXjRyL7817dbp099XeE_FB+Potr6QZaVKNk+h43BkA@mail.gmail.com>

2011/11/7 Kelly Kane <kelly at hawknetworks.com>

> On Mon, Nov 7, 2011 at 07:06, Tim Vollebregt <tim at interworx.nl> wrote:
> >
> > On #IX there are rumours about Junos version 10.3R2.11 being core dumped
> and
> > rebooted, which makes sense.
>
> Perhaps related to Juniper PSN-2011-08-327? Did the whole router
> reboot, or just the service module?
>
> We saw one TATA session, and one Abovenet session flap.
>
> Kelly
>
>
On our side we did not have any reboot, just a core dump generated and all
interfaces flapped.

-- 
Pierre-Yves Maunier

From deric.kwok2000 at gmail.com  Mon Nov  7 10:45:13 2011
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Mon, 7 Nov 2011 11:45:13 -0500
Subject: mtu question. more should be better, right?
Message-ID: <CAAiP322G=5AoEcu46NPOqOC3-wPoyXP5-dth5_YSTbO_vhAqoQ@mail.gmail.com>

Hi all

When I setup the server mtu as 9100. why I have to configure the
switch mtu 9300 to make it working?

What this extra 200 bytes is for what purpose? ls it standard?

What is disadvantage of setting our all internal networks (host /
equipment) mtu more than 1500?

Thank you for your advice.


From jared at puck.nether.net  Mon Nov  7 10:45:25 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 7 Nov 2011 11:45:25 -0500
Subject: General Internet Instability
In-Reply-To: <4EB80A29.1070006@gmail.com>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
 <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
 <1320683227.2220.108.camel@Andromeda> <4EB80A29.1070006@gmail.com>
Message-ID: <A297B31E-E0D7-47E5-A6A2-C061F2E1CEE5@puck.nether.net>


On Nov 7, 2011, at 11:41 AM, -Hammer- wrote:

> So the file size was 30% higher implies that the number of updates is larger and therefore there is instability? I see the logic but if you scroll thru that page (the whole month of November) there are tons of >1M files. Trying to see what is different about today....

This is an easy benchmark to gauge overall stability.  Large files mean something was unstable.  Then you need to actually look at them to see *why*.  Also since the files are compressed you lose some visibility into what is really in them.

- Jared

From bhmccie at gmail.com  Mon Nov  7 10:50:03 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Mon, 07 Nov 2011 10:50:03 -0600
Subject: General Internet Instability
In-Reply-To: <A297B31E-E0D7-47E5-A6A2-C061F2E1CEE5@puck.nether.net>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
 <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
 <1320683227.2220.108.camel@Andromeda> <4EB80A29.1070006@gmail.com>
 <A297B31E-E0D7-47E5-A6A2-C061F2E1CEE5@puck.nether.net>
Message-ID: <4EB80C3B.6050302@gmail.com>

Thank you. This is somewhat of a learning opportunity for me. I hit all 
the generic Internet health sites and I understand that there IS an 
issue. Now I'm getting to learn how you guys attempt to understand WHY 
we had an issue.

But my point is the same. If this is the case than the entire month of 
November reflects "instability" where I see transitions from 600k to 1M 
between updates. Yet we didn't experience the same negative customer 
experience for those. So how do you see the difference with todays 
events? Digging into files now.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/07/2011 10:45 AM, Jared Mauch wrote:
> On Nov 7, 2011, at 11:41 AM, -Hammer- wrote:
>
>    
>> So the file size was 30% higher implies that the number of updates is larger and therefore there is instability? I see the logic but if you scroll thru that page (the whole month of November) there are tons of>1M files. Trying to see what is different about today....
>>      
> This is an easy benchmark to gauge overall stability.  Large files mean something was unstable.  Then you need to actually look at them to see *why*.  Also since the files are compressed you lose some visibility into what is really in them.
>
> - Jared

From joelja at bogus.com  Mon Nov  7 10:52:51 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Mon, 07 Nov 2011 08:52:51 -0800
Subject: General Internet Instability
In-Reply-To: <B0528F35-1374-4FD4-A452-BA2B3EAF63C9@puck.nether.net>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
 <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
 <1320683227.2220.108.camel@Andromeda>
 <B0528F35-1374-4FD4-A452-BA2B3EAF63C9@puck.nether.net>
Message-ID: <4EB80CE3.4060508@bogus.com>

On 11/7/11 08:37 , Jared Mauch wrote:
> 
> On Nov 7, 2011, at 11:27 AM, Richard Golodner wrote:
> 
>> On Mon, 2011-11-07 at 11:09 -0500, Todd Snyder wrote:
>>> Can anyone point to any authoritative updates about this?
>>
>> 	I think Jared's suggestion was about as close as your going to get for
>> right now. Look at the size of the files he mentioned as compared to the
>> average size of the others.
>> 	Hopefully someone will come forth with an authoritative answer later
>> today.
>> 	Richard Golodner
>>
> 
> One can do some analysis of the files to determine what prefixes and autonomous
> system neighbors were impacted.
> 
> I can do some of this as I have some other tools that quickly process this data
> if people are interested.   Please send those replies/votes off list to me directly.

according to my peakflow the level-3 update spike was from ~1408 utc to
~1424 utc.

> - Jared
> 



From jared at puck.nether.net  Mon Nov  7 11:01:13 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 7 Nov 2011 12:01:13 -0500
Subject: real data [Re: General Internet Instability]
In-Reply-To: <4EB80A29.1070006@gmail.com>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
 <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
 <1320683227.2220.108.camel@Andromeda> <4EB80A29.1070006@gmail.com>
Message-ID: <F20FE5E0-5E0E-462F-A79D-2419A59D21F3@puck.nether.net>


Here's some real data for those interested.  It seems a quick view seems many TATA <-> Level3 and TATA <-> GBLX sets of instability.

Combined with the overall update levels seen over that 30 minutes, we saw ~1.566M updates at route views.

Compared with the 24h prior (2011.11.06 14:15 as reference) we see ~17-20x the updates in the same time period.  Now take your control plane and make it work 17-20x as hard, and you can see why we had some even general instability.

I don't have better tools for doing a more detailed analysis at this time, but this should get you started in talking to others about what happened.  (There were no stand-out prefixes for this time-period, they all had about the same number of updates per prefix).

#Updates|Filename
--------+-----------------
   42041 20111106.1415.out
  727711 20111107.1400.out
  838894 20111107.1415.out

2011.11.07 14:15 datafile - Most updates/as-path (complete as seen @ rviews)
Count AS_PATH
-----+----------------------------
4563  3549 3356
3172  3549 3356 11492
2912  8492 3356 6453 4755
2729  812 6453 4755
2695  3549 6453 14080 10620
2504  3549 3356 11492 11492 11492
2421  3549 3356 7029
2362  3356 209 721 27064
2244  3356 209 20115
2130  3356 209 22561
2044  7018 6453 14080 10620
2000  3356 209
1934  3549 3356 2907
1909  3356 15412 18101
1821  3549 6453 4755
1807  3356 6453 4755
1660  8492 3356 174
1634  3549 3356 18566
1619  3549 3356 4837 17623
1617  7018 6453 4755
1581  2497 6453 7545 7545 7545
1496  8492 3356 209 721 27064
1478  2497 6453 4755
1437  8492 8928 3356 11492 11492 11492
1427  3356 3549 3216 8402
1395  3356 701 19262
1362  8492 3356 209 20115
1357  3549 7843 7843 7843 10796
1336  3549 3356 6830 6830 6830
1259  2497 3356
1238  3356 9498
1229  812 6453 14080 10620
1229  3356 6453 14080 10620
1221  3356 9121 42926
1220  3549 3356 29314
1203  3549 3356 680 680 680 680 680
1194  2497 3356 5650 7011
1165  2497 3356 9498
1151  8001 4436 7843 10796
1150  3549 3356 15412 18101 18101 18101 18101 17803
1106  8492 3356 6762 7303
1105  3549 3356 55410 45528
1098  3549 3356 15412 18101 17803
1073  3549 7843 7843 7843
1072  3549 3356 7713 17974
1069  3549 3356 15290
1041  3356 3549
1032  3549 3356 11992
1030  3356 4323
1021  3549 6453 7843 11351
1020  8492 8928 3356 7843 11351
1016  2497 3356 11492
1014  3356 2907
1011  7018 3356 2907



2011.11.07 14:00 datafile - Most updates/as-path (complete as seen @ rviews)
Count AS_PATH
-----+----------------------------
3894  3356 6453 4755
3504  3549 3356
2930  812 6453 4755
2793  3549 6453 4755
2254  3549 3356 11492 11492 11492
2235  812 6453 14080 10620
1826  2497 6453 4755
1795  3549 3356 7029
1753  3356 3549
1689  7018 6453 14080 10620
1653  812 6453 4755 17488
1649  3549 3356 18566
1613  2497 3356
1568  3549 3356 6830 6830 6830
1496  7018 6453 4755
1419  3549 6453 14080 10620
1394  3356 701 19262
1389  3356 9121 42926
1382  3549 3356 21565
1293  3549 6453 4755 17488
1252  3549 3356 13407
1188  2497 3356 5650 7011
1156  7018 6453 4755 17488
1154  3356 6453 14080 10620
1127  3356 701 3216 8402
1106  8492 9002 3549 6762 7303
1104  3549 3356 4837 17623
1049  39756 3356 7018
1048  39756 3257 7018
1035  2497 6453 7713 17974
1008  3356 3320




From iljitsch at muada.com  Mon Nov  7 11:01:40 2011
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Mon, 7 Nov 2011 18:01:40 +0100
Subject: mtu question. more should be better, right?
In-Reply-To: <CAAiP322G=5AoEcu46NPOqOC3-wPoyXP5-dth5_YSTbO_vhAqoQ@mail.gmail.com>
References: <CAAiP322G=5AoEcu46NPOqOC3-wPoyXP5-dth5_YSTbO_vhAqoQ@mail.gmail.com>
Message-ID: <C0EE617A-4472-4918-830F-A2D4460EB6CD@muada.com>

On 7 Nov 2011, at 17:45 , Deric Kwok wrote:

> When I setup the server mtu as 9100. why I have to configure the
> switch mtu 9300 to make it working?

> What this extra 200 bytes is for what purpose? ls it standard?

To avoid problems you really want to set the MTU of all your IP devices on the same subnet to the same value. On the switches the MTU needs to be big enough to accommodate the MTU that the hosts and the routers use, but there's no harm in it being larger. (Although you may be using up memory for nothing.)

One complication is that not everyone has the same understanding of packet sizes. For IP the MTU is the size of the largest IP packet that can be carried, but layer 2 people sometimes add 14 or 18 bytes to that and layer 1 people maybe even 38. (14 = ethernet header, 18 = ethernet header + frame check sequence, 38 = header, FCS, preamble, start of frame delimiter and interframe gap.)

> What is disadvantage of setting our all internal networks (host /
> equipment) mtu more than 1500?

Mostly that you'll be hitting path MTU discovery more often. However, this will not cause many issues unlike the case where you use an MTU _smaller_ than 1500. Don't set a larger MTU on slow networks (certainly not on 10 Mbps) because long packets sit in queues for a long time at low speeds, getting in the way of interactive traffic such as VoIP. Above 11k the ethernet frame check sequence catches fewer errors.

From bhmccie at gmail.com  Mon Nov  7 11:13:25 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Mon, 07 Nov 2011 11:13:25 -0600
Subject: real data [Re: General Internet Instability]
In-Reply-To: <F20FE5E0-5E0E-462F-A79D-2419A59D21F3@puck.nether.net>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
 <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
 <1320683227.2220.108.camel@Andromeda> <4EB80A29.1070006@gmail.com>
 <F20FE5E0-5E0E-462F-A79D-2419A59D21F3@puck.nether.net>
Message-ID: <4EB811B5.60302@gmail.com>

Jared,
     This is good stuff and I'm understanding how you interpret the 
data. So this confirms what we are seeing. How do we take this towards a 
root cause? Mash it with the Juniper threads and see where it goes?

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/07/2011 11:01 AM, Jared Mauch wrote:
> Here's some real data for those interested.  It seems a quick view seems many TATA<->  Level3 and TATA<->  GBLX sets of instability.
>
> Combined with the overall update levels seen over that 30 minutes, we saw ~1.566M updates at route views.
>
> Compared with the 24h prior (2011.11.06 14:15 as reference) we see ~17-20x the updates in the same time period.  Now take your control plane and make it work 17-20x as hard, and you can see why we had some even general instability.
>
> I don't have better tools for doing a more detailed analysis at this time, but this should get you started in talking to others about what happened.  (There were no stand-out prefixes for this time-period, they all had about the same number of updates per prefix).
>
> #Updates|Filename
> --------+-----------------
>     42041 20111106.1415.out
>    727711 20111107.1400.out
>    838894 20111107.1415.out
>
> 2011.11.07 14:15 datafile - Most updates/as-path (complete as seen @ rviews)
> Count AS_PATH
> -----+----------------------------
> 4563  3549 3356
> 3172  3549 3356 11492
> 2912  8492 3356 6453 4755
> 2729  812 6453 4755
> 2695  3549 6453 14080 10620
> 2504  3549 3356 11492 11492 11492
> 2421  3549 3356 7029
> 2362  3356 209 721 27064
> 2244  3356 209 20115
> 2130  3356 209 22561
> 2044  7018 6453 14080 10620
> 2000  3356 209
> 1934  3549 3356 2907
> 1909  3356 15412 18101
> 1821  3549 6453 4755
> 1807  3356 6453 4755
> 1660  8492 3356 174
> 1634  3549 3356 18566
> 1619  3549 3356 4837 17623
> 1617  7018 6453 4755
> 1581  2497 6453 7545 7545 7545
> 1496  8492 3356 209 721 27064
> 1478  2497 6453 4755
> 1437  8492 8928 3356 11492 11492 11492
> 1427  3356 3549 3216 8402
> 1395  3356 701 19262
> 1362  8492 3356 209 20115
> 1357  3549 7843 7843 7843 10796
> 1336  3549 3356 6830 6830 6830
> 1259  2497 3356
> 1238  3356 9498
> 1229  812 6453 14080 10620
> 1229  3356 6453 14080 10620
> 1221  3356 9121 42926
> 1220  3549 3356 29314
> 1203  3549 3356 680 680 680 680 680
> 1194  2497 3356 5650 7011
> 1165  2497 3356 9498
> 1151  8001 4436 7843 10796
> 1150  3549 3356 15412 18101 18101 18101 18101 17803
> 1106  8492 3356 6762 7303
> 1105  3549 3356 55410 45528
> 1098  3549 3356 15412 18101 17803
> 1073  3549 7843 7843 7843
> 1072  3549 3356 7713 17974
> 1069  3549 3356 15290
> 1041  3356 3549
> 1032  3549 3356 11992
> 1030  3356 4323
> 1021  3549 6453 7843 11351
> 1020  8492 8928 3356 7843 11351
> 1016  2497 3356 11492
> 1014  3356 2907
> 1011  7018 3356 2907
>
>
>
> 2011.11.07 14:00 datafile - Most updates/as-path (complete as seen @ rviews)
> Count AS_PATH
> -----+----------------------------
> 3894  3356 6453 4755
> 3504  3549 3356
> 2930  812 6453 4755
> 2793  3549 6453 4755
> 2254  3549 3356 11492 11492 11492
> 2235  812 6453 14080 10620
> 1826  2497 6453 4755
> 1795  3549 3356 7029
> 1753  3356 3549
> 1689  7018 6453 14080 10620
> 1653  812 6453 4755 17488
> 1649  3549 3356 18566
> 1613  2497 3356
> 1568  3549 3356 6830 6830 6830
> 1496  7018 6453 4755
> 1419  3549 6453 14080 10620
> 1394  3356 701 19262
> 1389  3356 9121 42926
> 1382  3549 3356 21565
> 1293  3549 6453 4755 17488
> 1252  3549 3356 13407
> 1188  2497 3356 5650 7011
> 1156  7018 6453 4755 17488
> 1154  3356 6453 14080 10620
> 1127  3356 701 3216 8402
> 1106  8492 9002 3549 6762 7303
> 1104  3549 3356 4837 17623
> 1049  39756 3356 7018
> 1048  39756 3257 7018
> 1035  2497 6453 7713 17974
> 1008  3356 3320
>
>
>    

From jra at baylink.com  Mon Nov  7 12:14:04 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 7 Nov 2011 13:14:04 -0500 (EST)
Subject: General Internet Instability
In-Reply-To: <F21D4282-E69F-4A21-834D-55ED5AD1F84D@ukbroadband.com>
Message-ID: <13715771.1878.1320689644662.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Leigh Porter" <leigh.porter at ukbroadband.com>

> Just blame Shub Internet..
> 
> Oh no, I've said it now!

Nah; Brad took down everything but the webserver years ago.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From dnewman at networktest.com  Mon Nov  7 12:41:32 2011
From: dnewman at networktest.com (David Newman)
Date: Mon, 07 Nov 2011 10:41:32 -0800
Subject: mtu question. more should be better, right?
In-Reply-To: <CAAiP322G=5AoEcu46NPOqOC3-wPoyXP5-dth5_YSTbO_vhAqoQ@mail.gmail.com>
References: <CAAiP322G=5AoEcu46NPOqOC3-wPoyXP5-dth5_YSTbO_vhAqoQ@mail.gmail.com>
Message-ID: <4EB8265C.1080202@networktest.com>

On 11/7/11 8:45 AM, Deric Kwok wrote:

> When I setup the server mtu as 9100. why I have to configure the
> switch mtu 9300 to make it working?
> 
> What this extra 200 bytes is for what purpose? ls it standard?

MTUs above 2000 bytes are nonstandard. The most recent Ethernet spec,
802.3-2008, defines a maxBasicFrameSize of 1518 octets and a
maxEnvelopeFrameSize size of 2000 octets to accommodate various encap
mechanisms.

> What is disadvantage of setting our all internal networks (host /
> equipment) mtu more than 1500?

In a single data center at 1-Gbit/s rates or above, probably none,
provided all devices support and use the same MTU. In other scenarios
jumbos can lead to the various problems Iljitsch mentioned.

dn



From lbstreamer at gmail.com  Mon Nov  7 13:27:12 2011
From: lbstreamer at gmail.com (Louis P)
Date: Mon, 07 Nov 2011 20:27:12 +0100
Subject: Historical records of IP allocations
In-Reply-To: <F6A73811-0251-40A7-A504-E32359362DA2@cs.ucla.edu>
References: <4EB6CB74.6060003@gmail.com>
 <0737E427-68A2-4AC6-8F7A-1B2B81D45AC3@cs.ucla.edu>
 <F6A73811-0251-40A7-A504-E32359362DA2@cs.ucla.edu>
Message-ID: <4EB83110.6050302@gmail.com>

Ripe Routing History seems to be efficient, showing me the AS and for 
how long the prefix was announced.
This question showed me how pointless can be geoip databases (lots of 
users in this range are also redirected to Neetherland version of Yahoo 
and Youtube, me, I get some ad in russian).
I don't understand why not whois-ing RIRs to obtain country.

Thank you all for your replies (and thanks to people who kept traces of 
records).
Louis P

Le 07/11/2011 07:34, Lucas Wang a ?crit :
> We started keeping track of whois databases from March 20th this year,
> and our earliest data shows it belongs to a Russian company called DIMEDIA LLC.
> Now the latest whois shows it belongs to "OVH Telecom" located in France.
>
> On Nov 6, 2011, at 10:58 AM, Louis P wrote:
>
>> Hello,
>> Does anyone know if it's possible to get old records (AS numbers...) of an IP allocation ?
>> I found on RIPE these data : ftp://ftp.ripe.net/pub/stats/ripencc/
>> But only the country and allocation date are included.
>>
>> The IP range I would like to have more information about is 109.190.0.0/17 (it was Russian before and now French).
>>
>> Thanks in advance,
>> Regards,
>> Louis P.



From jvanoppen at spectrumnet.us  Mon Nov  7 13:52:59 2011
From: jvanoppen at spectrumnet.us (John van Oppen)
Date: Mon, 7 Nov 2011 19:52:59 +0000
Subject: TATA problems?
In-Reply-To: <1320678667.4104.1.camel@teh-desktop>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
Message-ID: <AF24AE2D4A4D334FB9B667985E2AE7630191B2A9@mail1-sea.office.spectrumnet.us>

We saw several customers go away this morning as well.   Our network itself is cisco so we did not see anything directly. 

John van Oppen
@ AS11404.


-----Original Message-----
From: Tom Hill [mailto:tom at ninjabadger.net] 
Sent: Monday, November 07, 2011 7:09 AM
To: nanog at nanog.org
Subject: Re: TATA problems?

On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
> We seem to be having some problems with our tata links - first seen in 
> EU about 45 minutes ago, now we're seeing problems in NA.  I'm focused 
> on DNS, so I'm seeing a lot of timeouts/servfails, but our networking 
> folks are talking about links dropping.
> 
> Anyone else seeing oddness on the NA Internet right now?
> 
> http://downrightnow.com/ confirms - something is up.

There are widespread issues across the Internet; certain versions of Juniper firmware have core dumped after seeing a particular BGP 'UPDATE'
message. 

(That's the running theory at least).

It's affected multiple service providers, globally, not just those connected to TATA.

Tom



From ebais at a2b-internet.com  Mon Nov  7 14:40:01 2011
From: ebais at a2b-internet.com (Erik Bais)
Date: Mon, 7 Nov 2011 21:40:01 +0100
Subject: General Internet Instability
In-Reply-To: <4EB80C3B.6050302@gmail.com>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
 <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
 <1320683227.2220.108.camel@Andromeda> <4EB80A29.1070006@gmail.com>
 <A297B31E-E0D7-47E5-A6A2-C061F2E1CEE5@puck.nether.net>
 <4EB80C3B.6050302@gmail.com>
Message-ID: <013601cc9d8d$6ccdd4c0$46697e40$@com>

I just got pointed towards the following : 
https://twitter.com/#!/JuniperNetworks/status/133637820081389568 

And a (re)post on Pastbin :  
http://pastebin.com/HBWiH92j
 
Juniper Networks replied to my post on Twitter:
https://twitter.com/#!/erikbais/status/133641575585677312 

That they are working on an official public URL for all to read. 

Regards,
Erik Bais
A2B Internet 




From mathews at hawaii.edu  Mon Nov  7 15:29:41 2011
From: mathews at hawaii.edu (Robert Mathews (OSIA))
Date: Mon, 07 Nov 2011 16:29:41 -0500
Subject: real data
In-Reply-To: <F20FE5E0-5E0E-462F-A79D-2419A59D21F3@puck.nether.net>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>
 <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD@puck.nether.net>
 <CAPQUSnMpNowr9nEZcC=JKygM7G+As03_M777XybSEkLqP4KMog@mail.gmail.com>
 <1320683227.2220.108.camel@Andromeda> <4EB80A29.1070006@gmail.com>
 <F20FE5E0-5E0E-462F-A79D-2419A59D21F3@puck.nether.net>
Message-ID: <8EA4C0C1-D6C4-4FA8-9AAD-CCDCC31554EF@hawaii.edu>


 On 11/7/2011 12:01 PM,  Jared Mauch wrote:
> ..... It seems a quick view seems many TATA <-> Level3 and TATA <-> GBLX sets of instability.
> 
> Combined with the overall update levels seen over that 30 minutes, we saw ~1.566M updates at route views.
> Compared with the 24h prior (2011.11.06 14:15 as reference) we see ~17-20x the updates in the same time period.  Now take your control plane and make it work 17-20x as hard, and you can see why we had some even general instability.
Jared:

Thanks, for posting this, and for sharing data.  
Too bad it is not Huawei that is involved.  It has precluded someone, somewhere, from framing this SNAFU, a coordinated global 
Cyber Event, instigated by the Chinese PLA. 8-;)  Then, there is still time for that. [again, tongue firmly planted into cheek]
--  
Dr. Robert Mathews, D.Phil.
Distinguished Senior Research Scholar - National Security Affairs & US Industrial Preparedness
University of Hawai'i (OSIA)

|--  Sent from "the mother-ship," high above the "blue planet."

From leigh.porter at ukbroadband.com  Mon Nov  7 16:09:55 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 7 Nov 2011 22:09:55 +0000
Subject: TATA problems?
In-Reply-To: <AF24AE2D4A4D334FB9B667985E2AE7630191B2A9@mail1-sea.office.spectrumnet.us>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>,
 <AF24AE2D4A4D334FB9B667985E2AE7630191B2A9@mail1-sea.office.spectrumnet.us>
Message-ID: <5492067E-903D-4A15-912F-E5328C5CE3F2@ukbroadband.com>

Any thoughts on just how wide read this was? Did every Juniper that receives Internet BGP updates with the affected software break? Or did it die out quite quickly?

-- 
Leigh


On 7 Nov 2011, at 19:55, "John van Oppen" <jvanoppen at spectrumnet.us> wrote:

> We saw several customers go away this morning as well.   Our network itself is cisco so we did not see anything directly. 
> 
> John van Oppen
> @ AS11404.
> 
> 
> -----Original Message-----
> From: Tom Hill [mailto:tom at ninjabadger.net] 
> Sent: Monday, November 07, 2011 7:09 AM
> To: nanog at nanog.org
> Subject: Re: TATA problems?
> 
> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
>> We seem to be having some problems with our tata links - first seen in 
>> EU about 45 minutes ago, now we're seeing problems in NA.  I'm focused 
>> on DNS, so I'm seeing a lot of timeouts/servfails, but our networking 
>> folks are talking about links dropping.
>> 
>> Anyone else seeing oddness on the NA Internet right now?
>> 
>> http://downrightnow.com/ confirms - something is up.
> 
> There are widespread issues across the Internet; certain versions of Juniper firmware have core dumped after seeing a particular BGP 'UPDATE'
> message. 
> 
> (That's the running theory at least).
> 
> It's affected multiple service providers, globally, not just those connected to TATA.
> 
> Tom
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From bhmccie at gmail.com  Mon Nov  7 16:07:34 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Mon, 07 Nov 2011 16:07:34 -0600
Subject: TATA problems?
In-Reply-To: <5492067E-903D-4A15-912F-E5328C5CE3F2@ukbroadband.com>
References: <CAPQUSnPkHAV-O9u+mF=NOh0NcYPrtau6U80Mu-BUV3ASY4b-gw@mail.gmail.com>
 <1320678667.4104.1.camel@teh-desktop>,
 <AF24AE2D4A4D334FB9B667985E2AE7630191B2A9@mail1-sea.office.spectrumnet.us>
 <5492067E-903D-4A15-912F-E5328C5CE3F2@ukbroadband.com>
Message-ID: <4EB856A6.6070907@gmail.com>

This was posted on pastebin earlier today in case it helps.

1. View Bulletin PSN-2011-08-327
2. Title   MX Series MPC crash in Ktree::createFourWayNode after BGP UPDATE
3. Products Affected       This issue can affect any MX Series router 
with port concentrators based on the Trio chipset -- such as the MPC or 
embedded into the MX80 -- with active protocol-based route prefix 
additions/deletions occurring.
4. Platforms Affected
5. Security
6. JUNOS 11.x
7. MX-series
8. JUNOS 10.x
9. SIRT Security Advisory
10. SIRT Security Notice
11. Revision Number 1
12. Issue Date      2011-08-08
13.
14. PSN Issue :
15. MPCs (Modular Port Concentrators) installed in an MX Series router 
may crash upon receipt of very specific and unlikely route prefix 
install/delete actions, such as a BGP routing update. The set of route 
prefix updates is non-deterministic and exceedingly unlikely to occur. 
Junos versions affected include 10.0, 10.1, 10.2, 10.3, 10.4 prior to 
10.4R6, and 11.1 prior to 11.1R4. The trigger for the MPC crash was 
determined to be a valid BGP UPDATE received from a registered network 
service provider, although this one UPDATE was determined to not be 
solely responsible for the crashes. A complex sequence of preconditions 
is required to trigger this crash. Both IPv4 and IPv6 routing prefix 
updates can trigger this MPC crash.
16.
17. There is no indication that this issue was triggered maliciously. 
Given the complexity of conditions required to trigger this issue, the 
probability of exploiting this defect is extremely low.
18.
19. The assertions (crash) all occurred in the code used to store 
routing information, called Ktree, on the MPC. Due to the order and mix 
of adds and deletes to the tree, certain combinations of address adds 
and deletes can corrupt the data structures within the MPC, which in 
turn can cause this line card crash. The MPC recovers and returns to 
service quickly, and without operator intervention.
20.
21. This issue only affects MX Series routers with port concentrators 
based on the Trio chipset, such as the MPC or embedded into the MX80. No 
other product or platform is vulnerable to this issue.
22.
23. Solution:
24. The Ktree code has been updated and enhanced to ensure that 
combinations and permutations of routing updates will not corrupt the 
state of the line card. Extensive testing has been performed to validate 
an exceedingly large combination and permutation of route prefix 
additions and deletions.
25.
26. All Junos OS software releases built on or after 2011-08-03 have 
fixed this specific issue. Releases containing the fix specifically 
include: 10.0S18, 10.4R6, 11.1R4, 11.2R1, and all subsequent releases 
(i.e. all releases built after 11.2R1).
27.
28. This issue is being tracked as PR 610864. While this PR may not be 
viewable by customers, it can be used as a reference when discussing the 
issue with JTAC.
29.
30. KB16765 - "In which releases are vulnerabilities fixed?" describes 
which release vulnerabilities are fixed as per our End of Engineering 
and End of Life support policies.
31.
32. Workarounds
33. No known workaround exists for this issue.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/07/2011 04:09 PM, Leigh Porter wrote:
> Any thoughts on just how wide read this was? Did every Juniper that receives Internet BGP updates with the affected software break? Or did it die out quite quickly?
>
>    

From stu at spacehopper.org  Mon Nov  7 16:12:48 2011
From: stu at spacehopper.org (Stuart Henderson)
Date: Mon, 7 Nov 2011 22:12:48 +0000 (UTC)
Subject: IPv6 beta support for Android phones
References: <CAD6AjGQAU28=hnBJNmc1jPCQi907L26MbnhvUnJ69K6CHo=mKw@mail.gmail.com>
 <1320597177.6199.8.camel@teh-desktop>
 <CAD6AjGTTBnJhAdpcxGW0VWaym-Lcw9eHot4Mw=xNKULyEDUyvg@mail.gmail.com>
 <D181DDABABE57E4DB72FEE003314786442BBDD@EALPO1.ukbroadband.com>
Message-ID: <slrnjbglv0.8o0.stu@naiad.spacehopper.org>

On 2011-11-07, Leigh Porter <leigh.porter at ukbroadband.com> wrote:
>> 
>> LTE does not have the dual attachment problem since there is the
>> concept of having v4 and v6 in one attachment, but it does not change
>> the fact that there are not enough IPv4 addresses to go around,
>> especially from a strategic planning perspective (let's design this
>> once for 5 to 10+ year life ...)
>> 
>
> Most networks seem to dish out address space behind a LSN box these days.
>
> I have three dongle things from three networks in the UK, none of them give me a public address.

Though there is at least one UK provider giving out fixed addresses
(single and routed netblocks) on 3g




From joe at nethead.com  Mon Nov  7 16:28:25 2011
From: joe at nethead.com (Joe Hamelin)
Date: Mon, 7 Nov 2011 14:28:25 -0800
Subject: Cell-based OOB management devices
In-Reply-To: <CAD6AjGTH0N3_V-gnP3m0D6bS5hLYJCOfT_gyNeKzw9fP+FYdGw@mail.gmail.com>
References: <FCD26398C5EDE746BFC47F43EA52A173054DA958@dino.ad.hostasaurus.com>
 <CAD6AjGTH0N3_V-gnP3m0D6bS5hLYJCOfT_gyNeKzw9fP+FYdGw@mail.gmail.com>
Message-ID: <CAO0-hXao5Z2hqFFFx84JgiUT-a4z-nSy-RdF6VA_yxM5ngEdRQ@mail.gmail.com>

>
> On Nov 6, 2011 10:15 PM, "David Hubbard" <dhubbard at dino.hostasaurus.com>
> wrote:
> >
> > Hi all, I am looking at cellular-based devices as a higher
> > speed alternative to dial-up backup access methods for
> > out of band management during emergencies.
>

I've used the Digi devices for Clearwire site OOB and in many retail
situations where they are use for backup connection and for when the wire
line hasn't been delivered yet.  They do come with a static IP address if
you request (and pay?) for it. They can come from the shared mobile IP
range (RFC 2002) so that you can keep the static IP as you move between
tower sites.  You can also get them "piped" right in to your net via a VPN,
although I suspect that is only affordable for a very large install base.

Real world 3G bandwidth is about 1Mb/s down and 300Kb/s down.  RTT (ping)
is around 185ms to a local IXP (which kinda sucks for terminal support, but
still better than a POTS modem.)

 --
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

From ed at edgeoc.net  Mon Nov  7 16:38:14 2011
From: ed at edgeoc.net (Edward Salonia)
Date: Mon, 7 Nov 2011 22:38:14 +0000
Subject: Cell-based OOB  management devices
Message-ID: <291656980-1320705496-cardhu_decombobulator_blackberry.rim.net-2132388056-@b4.c2.bise6.blackberry>

I would look into Uplogix. I've seen them demo their products at Cisco Live a couple of times and they seem very good.
- You can connect a cellular modem to them.
- They can store backup device configs.
- They can store IOS images.
- They can even xmodem an image to a device if it gets stuck in ROMMON.
- Some of this can even be automated by their device.


------Original Message------
From: David Hubbard
To: nanog at nanog.org
Subject: Cell-based OOB  management devices
Sent: Nov 7, 2011 1:14 AM

Hi all, I am looking at cellular-based devices as a higher
speed alternative to dial-up backup access methods for
out of band management during emergencies.  I was
wondering if anyone had experiences with such devices
they could share?

Devices I've found include Sierra Wireless AirLink Raven X,
Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G.  I
have no experience with any but they all appear to support
the Sprint network which I assume would be ideal due to
not having usage caps on data (currently).  The Opengear
device runs linux and has four serial ports, a usb port
for additional storage and ethernet, so it seems to have
some small advantages over the others since it could double
as an emergency self-contained management station you can
SSH into and run diagnostics from.  All appear to have
VPN/gateway support.

What none of them are clear on is how you would connect
to it over cellular since I assume you're just paying for
a typical data plan and it will randomly obtain IP 
addresses.  Maybe some type of dynamic dns service so you
can easily figure out your device's current IP?  How
stable is the access to the device?  Any idea if any of
them can do ipv6?

Thanks!

David



From ebarrios at gobarrios.com  Mon Nov  7 16:56:58 2011
From: ebarrios at gobarrios.com (ebarrios at gobarrios.com)
Date: Mon, 07 Nov 2011 15:56:58 -0700
Subject: Cell-based OOB management devices
Message-ID: <20111107155658.c33affd8db45087daf3b7a3394399b61.6e1c0fcce3.wbe@email02.secureserver.net>


From jra at baylink.com  Mon Nov  7 17:07:18 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 7 Nov 2011 18:07:18 -0500 (EST)
Subject: [outages] Time Warner Cable outage
In-Reply-To: <1A8A762BD508624A8BDAB9F5E1638F946014CE15BD@comsrv01.fg.local>
Message-ID: <17336195.1942.1320707238908.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Dustin Rhodes" <DRhodes at fiberutilities.com>

> Sounded like someone was broadcasting a BGP route with an invalid
> attribute and caused BGP session restarts or Core Dumps/crashes on any
> Juniper router running version 10.4

Well, it *is* getting on towards Christmas...

Cheers,
-- jr '*really*, Juniper?' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From jra at baylink.com  Mon Nov  7 20:41:52 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 7 Nov 2011 21:41:52 -0500 (EST)
Subject: [outages] More notes
In-Reply-To: <CAHsqw9sw1BbPMNUftpNUfoX7o2KVJNGPJHzN0itNxeE0JR6ADQ@mail.gmail.com>
Message-ID: <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jonathan Lassoff" <jof at thejof.com>

> <tangential sidenote>
> It's too bad that Junipers bugs aren't listed publicly. For clueful
> network operations, having this information available to them could
> have enabled them to properly weigh the risk of evaluating and
> certifying versions of their operating systems.

The reason it's called "gambling" is that sometimes, you lose.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From clayton at haydel.org  Mon Nov  7 20:43:13 2011
From: clayton at haydel.org (clayton at haydel.org)
Date: Mon, 7 Nov 2011 21:43:13 -0500
Subject: XO blocking individual IP's
Message-ID: <741f8279bada1343342d857e18f7495d.squirrel@emailmg.ipower.com>


I'm hoping someone has had the same experiences, and is further toward a
resolution on this than I am. About 6 months ago, we noticed that XO was
blackholing one specific IP out of a /24.  Traces to that IP stopped on
XO's network, traces to anything else out of the block went through fine.
XO finally admitted that they had a new security system that identifies
suspicious traffic and automatically blocks the IP for 30 minutes.  We had
to get the IP in question "whitelisted" by their security guys.  The
traffic was all legit, it was just on a high port # that they considered
suspicious.

There have several more cases like this, and XO has not been forthcoming
with information. We're either looking to be exempted from this filtering
or at least get a detailed description of how the system works.  I'm not
sure how they think this is acceptable from a major transit provider.
Anybody else had similar problems?


Clayton Haydel



From jra at baylink.com  Mon Nov  7 20:51:42 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 7 Nov 2011 21:51:42 -0500 (EST)
Subject: XO blocking individual IP's
In-Reply-To: <741f8279bada1343342d857e18f7495d.squirrel@emailmg.ipower.com>
Message-ID: <1822304.1989.1320720702784.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: clayton at haydel.org

> There have several more cases like this, and XO has not been forthcoming
> with information. We're either looking to be exempted from this filtering
> or at least get a detailed description of how the system works. I'm not
> sure how they think this is acceptable from a major transit provider.

"transit provider".  Is XO the end-access provider for either you or the 
destination site?  Or are both of those on some other connection, and XO 
is a bystander along the way?

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From clayton at haydel.org  Mon Nov  7 21:06:25 2011
From: clayton at haydel.org (clayton at haydel.org)
Date: Mon, 7 Nov 2011 22:06:25 -0500
Subject: XO blocking individual IP's
In-Reply-To: <1822304.1989.1320720702784.JavaMail.root@benjamin.baylink.com>
References: <1822304.1989.1320720702784.JavaMail.root@benjamin.baylink.com>
Message-ID: <8cd9ddd28acb187bf24131339f00e806.squirrel@emailmg.ipower.com>


> "transit provider".  Is XO the end-access provider for either you or the
> destination site?  Or are both of those on some other connection, and XO
> is a bystander along the way?

We're a direct customer.  The IP's that I've seen them block have been
both on our network and on remote networks, so I suspect their filtering
would affect any traffic that happened to pass over XO.


Clayton Haydel



From nickellman at gmail.com  Mon Nov  7 21:37:55 2011
From: nickellman at gmail.com (brian nikell)
Date: Mon, 7 Nov 2011 20:37:55 -0700
Subject: [outages] More notes
In-Reply-To: <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com>
References: <CAHsqw9sw1BbPMNUftpNUfoX7o2KVJNGPJHzN0itNxeE0JR6ADQ@mail.gmail.com>
 <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAMKfM=gyKttBxgzYWA8zK=wbTEG0=te4eJEtwZO=g8cDoY2tVw@mail.gmail.com>

Actually, Juniper does disclose code bugs. Though not always to the public
at first, importantly to Juniper customers. Juniper had advised all of
their customers last August of this bug, however Level3 chose to continue
running it on their peer routers. Thus if Level3 and its clue(full)
management might have listened to their operators & network engineers....

cheers

On Mon, Nov 7, 2011 at 7:41 PM, Jay Ashworth <jra at baylink.com> wrote:

> ----- Original Message -----
> > From: "Jonathan Lassoff" <jof at thejof.com>
>
> > <tangential sidenote>
> > It's too bad that Junipers bugs aren't listed publicly. For clueful
> > network operations, having this information available to them could
> > have enabled them to properly weigh the risk of evaluating and
> > certifying versions of their operating systems.
>
> The reason it's called "gambling" is that sometimes, you lose.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth                  Baylink
> jra at baylink.com
> Designer                     The Things I Think                       RFC
> 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land
> Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647
> 1274
>
>


-- 
-B

From blake at pfankuch.me  Mon Nov  7 22:34:23 2011
From: blake at pfankuch.me (Blake T. Pfankuch)
Date: Tue, 8 Nov 2011 04:34:23 +0000
Subject: XO blocking individual IP's
In-Reply-To: <741f8279bada1343342d857e18f7495d.squirrel@emailmg.ipower.com>
References: <741f8279bada1343342d857e18f7495d.squirrel@emailmg.ipower.com>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C846D95307F@SHSBS.shenrons-house.local>

Oh yes!  Good lord I about went insane with this.  I was working with a customer single homed to cBeyond.  I spent 3 hours on the phone with cBeyond to figure out what was going on, it looks like a broken route.  Come to find out it was an XO "security null".  The engineer on the phone from cBeyond said to me "Well, I have learned 2 things today.  1, XO nulls for 'security purposes' at random.  2, I am no longer shocked by any ridiculous policy I will ever come across again."

In this case majority traffic was going from cBeyond to anywhere (via XO) and being eaten, however it was VERY tough to diagnose as all parties involved assumed this would not be occurring between source and destination without good public documentation or at least any record of this happening to someone else.  Also I guess we all assumed that major bandwidth players don't filter anything.

I personally think its good on paper, but very bad real life until there is a way to notify the end customer of the violation quickly.  This issue literally took 3 full weeks to figure out what was going on.  Yes this works great in a colo datacenter as you have the customer contact info (hopefully).  But in the case where my customers provider was having the IP filtered by their transit it was hell to diagnose.  In my case the customer had a single infected machine that was making outbound connections on TCP3389 in the range of about 100 connections every 5 minutes and because of this was entirely being "security nulled".

Blake

-----Original Message-----
From: clayton at haydel.org [mailto:clayton at haydel.org] 
Sent: Monday, November 07, 2011 7:43 PM
To: nanog at nanog.org
Subject: XO blocking individual IP's


I'm hoping someone has had the same experiences, and is further toward a resolution on this than I am. About 6 months ago, we noticed that XO was blackholing one specific IP out of a /24.  Traces to that IP stopped on XO's network, traces to anything else out of the block went through fine.
XO finally admitted that they had a new security system that identifies suspicious traffic and automatically blocks the IP for 30 minutes.  We had to get the IP in question "whitelisted" by their security guys.  The traffic was all legit, it was just on a high port # that they considered suspicious.

There have several more cases like this, and XO has not been forthcoming with information. We're either looking to be exempted from this filtering or at least get a detailed description of how the system works.  I'm not sure how they think this is acceptable from a major transit provider.
Anybody else had similar problems?


Clayton Haydel




From joly at punkcast.com  Tue Nov  8 00:42:20 2011
From: joly at punkcast.com (Joly MacFie)
Date: Tue, 8 Nov 2011 01:42:20 -0500
Subject: IPv6World:Asia - Deployment Experience with IPv6
Message-ID: <CAM9VJk1j6ZGS9Fkq=nb+39qtxHa6x1gkymtmM+LYdtj81jvpDw@mail.gmail.com>

For any of you who are working late, we are just about to start (2am-4am
EST) a live webcast of a "Deployment Experience with IPv6" event from Hong
Kong. Fred Baker is the keynote speaker.

Webcast: http://www.livestream.com/internetsocietychapters/
More info: http://isoc-ny.org/p2/?p=2630

-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-

From bortzmeyer at nic.fr  Tue Nov  8 02:21:37 2011
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 8 Nov 2011 09:21:37 +0100
Subject: [outages] More notes
In-Reply-To: <CAMKfM=gyKttBxgzYWA8zK=wbTEG0=te4eJEtwZO=g8cDoY2tVw@mail.gmail.com>
References: <CAHsqw9sw1BbPMNUftpNUfoX7o2KVJNGPJHzN0itNxeE0JR6ADQ@mail.gmail.com>
 <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com>
 <CAMKfM=gyKttBxgzYWA8zK=wbTEG0=te4eJEtwZO=g8cDoY2tVw@mail.gmail.com>
Message-ID: <20111108082137.GA20928@nic.fr>

On Mon, Nov 07, 2011 at 08:37:55PM -0700,
 brian nikell <nickellman at gmail.com> wrote 
 a message of 38 lines which said:

> Actually, Juniper does disclose code bugs. Though not always to the
> public at first, importantly to Juniper customers. Juniper had
> advised all of their customers last August of this bug, however
> Level3 chose to continue running it on their peer routers. Thus if
> Level3 and its clue(full) management might have listened to their
> operators & network engineers....

I disagree. The official bug statement from Juniper in August was
trying very hard to downplay the importance of the bug ("Given the
complexity of conditions required to trigger this issue, the
probability of exploiting this defect is extremely low"). No wonder so
few people (and not only at Level-3) did not upgrade.


From leigh.porter at ukbroadband.com  Tue Nov  8 02:52:38 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Tue, 8 Nov 2011 08:52:38 +0000
Subject: XO blocking individual IP's
In-Reply-To: <CC75EEBF17C7374EA8309102B7B10C846D95307F@SHSBS.shenrons-house.local>
References: <741f8279bada1343342d857e18f7495d.squirrel@emailmg.ipower.com>,
 <CC75EEBF17C7374EA8309102B7B10C846D95307F@SHSBS.shenrons-house.local>
Message-ID: <EAC4FD6F-2E16-44A1-BC64-C1A80679BA92@ukbroadband.com>

So if you want to launch a DoS attack against a specific IP address you spoof TCP3389 SYNs to networks single homed to XO and they will null it for you.

-- 
Leigh


On 8 Nov 2011, at 04:36, "Blake T. Pfankuch" <blake at pfankuch.me> wrote:

> Oh yes!  Good lord I about went insane with this.  I was working with a customer single homed to cBeyond.  I spent 3 hours on the phone with cBeyond to figure out what was going on, it looks like a broken route.  Come to find out it was an XO "security null".  The engineer on the phone from cBeyond said to me "Well, I have learned 2 things today.  1, XO nulls for 'security purposes' at random.  2, I am no longer shocked by any ridiculous policy I will ever come across again."
> 
> In this case majority traffic was going from cBeyond to anywhere (via XO) and being eaten, however it was VERY tough to diagnose as all parties involved assumed this would not be occurring between source and destination without good public documentation or at least any record of this happening to someone else.  Also I guess we all assumed that major bandwidth players don't filter anything.
> 
> I personally think its good on paper, but very bad real life until there is a way to notify the end customer of the violation quickly.  This issue literally took 3 full weeks to figure out what was going on.  Yes this works great in a colo datacenter as you have the customer contact info (hopefully).  But in the case where my customers provider was having the IP filtered by their transit it was hell to diagnose.  In my case the customer had a single infected machine that was making outbound connections on TCP3389 in the range of about 100 connections every 5 minutes and because of this was entirely being "security nulled".
> 
> Blake
> 
> -----Original Message-----
> From: clayton at haydel.org [mailto:clayton at haydel.org] 
> Sent: Monday, November 07, 2011 7:43 PM
> To: nanog at nanog.org
> Subject: XO blocking individual IP's
> 
> 
> I'm hoping someone has had the same experiences, and is further toward a resolution on this than I am. About 6 months ago, we noticed that XO was blackholing one specific IP out of a /24.  Traces to that IP stopped on XO's network, traces to anything else out of the block went through fine.
> XO finally admitted that they had a new security system that identifies suspicious traffic and automatically blocks the IP for 30 minutes.  We had to get the IP in question "whitelisted" by their security guys.  The traffic was all legit, it was just on a high port # that they considered suspicious.
> 
> There have several more cases like this, and XO has not been forthcoming with information. We're either looking to be exempted from this filtering or at least get a detailed description of how the system works.  I'm not sure how they think this is acceptable from a major transit provider.
> Anybody else had similar problems?
> 
> 
> Clayton Haydel
> 
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From bjorn at mork.no  Tue Nov  8 02:59:34 2011
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Tue, 08 Nov 2011 09:59:34 +0100
Subject: [outages] More notes
In-Reply-To: <20111108082137.GA20928@nic.fr> (Stephane Bortzmeyer's message of
 "Tue, 8 Nov 2011 09:21:37 +0100")
References: <CAHsqw9sw1BbPMNUftpNUfoX7o2KVJNGPJHzN0itNxeE0JR6ADQ@mail.gmail.com>
 <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com>
 <CAMKfM=gyKttBxgzYWA8zK=wbTEG0=te4eJEtwZO=g8cDoY2tVw@mail.gmail.com>
 <20111108082137.GA20928@nic.fr>
Message-ID: <87ipmvyop5.fsf@nemi.mork.no>

Stephane Bortzmeyer <bortzmeyer at nic.fr> writes:

>  ("Given the
> complexity of conditions required to trigger this issue, the
> probability of exploiting this defect is extremely low"). 

Which translates to

"This bug has such catastrophic consequenses that we do not want to
disclose how to trigger it."

Do you think any such bug would be discovered and/or disclosed *at all*
unless it already was triggered in the wild? And if it was triggered
once, what are the chances it will happen again?



Bj?rn


From seth.mos at dds.nl  Tue Nov  8 03:02:32 2011
From: seth.mos at dds.nl (Seth Mos)
Date: Tue, 08 Nov 2011 10:02:32 +0100
Subject: Performance Issues - PTR Records
In-Reply-To: <20111107.144648.74734213.sthaug@nethelp.no>
References: <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no>
 <20111107.144648.74734213.sthaug@nethelp.no>
Message-ID: <4EB8F028.8040607@dds.nl>

On 7-11-2011 14:46, sthaug at nethelp.no wrote:
>>> The practice of filling out the reverse zone with fake PTR record
>>> started before there was wide spread support for UPDATE/DNS.  There
>>> isn't any need for this to be done anymore.  Machines are capable
>>> of adding records for themselves.
>>
>> How do I setup this for DHCPv6-PD?  Say, I delegate 2001:db8:42::/48 to
>> the end user.  Should I delegate reverse DNS as well?  If so, to whom?
>>
>> Or is it the CPEs responibility to dynamically add records for whatever
>> addresses it sees on the internal LAN(s)?  Are there CPEs capable of
>> doing this?
>>
>> Or will the end systems themselves do the update against my DNS server?
>> If so, how do I authenticate that?
> 
> With my ISP hat on, I find the idea of customer CPEs updating their
> own PTR records to be completely unacceptable. So I guess I'll either
> live without the reverse DNS, or use a name server that can synthesize
> answers on the fly.

That seems like a really nice feature, create a reverse record to spoof
a mail server and the reverse DNS will match up.

If the domain does not employ SPF it will look legit, forward and
reverse won't match up ofcourse. Not sure how many mailservers have
issues with that if the reverse matches up.

Sounds like a fine way to employ a spam botnet.

Regards,

Seth


From bmanning at vacation.karoshi.com  Tue Nov  8 04:56:31 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 8 Nov 2011 10:56:31 +0000
Subject: where was my white knight....
Message-ID: <20111108105631.GB5979@vacation.karoshi.com.>


how would a sidr-enabled routing infrastructure have fared in yesterdays routing circus?

/bill


From marka at isc.org  Tue Nov  8 05:05:12 2011
From: marka at isc.org (Mark Andrews)
Date: Tue, 08 Nov 2011 22:05:12 +1100
Subject: Performance Issues - PTR Records
In-Reply-To: Your message of "Tue, 08 Nov 2011 10:02:32 BST."
 <4EB8F028.8040607@dds.nl>
References: <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no>
 <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl>
Message-ID: <20111108110512.72E8116E19F7@drugs.dv.isc.org>


In message <4EB8F028.8040607 at dds.nl>, Seth Mos writes:
> On 7-11-2011 14:46, sthaug at nethelp.no wrote:
> >>> The practice of filling out the reverse zone with fake PTR record
> >>> started before there was wide spread support for UPDATE/DNS.  There
> >>> isn't any need for this to be done anymore.  Machines are capable
> >>> of adding records for themselves.
> >>
> >> How do I setup this for DHCPv6-PD?  Say, I delegate 2001:db8:42::/48 to
> >> the end user.  Should I delegate reverse DNS as well?  If so, to whom?
> >>
> >> Or is it the CPEs responibility to dynamically add records for whatever
> >> addresses it sees on the internal LAN(s)?  Are there CPEs capable of
> >> doing this?
> >>
> >> Or will the end systems themselves do the update against my DNS server?
> >> If so, how do I authenticate that?
> > 
> > With my ISP hat on, I find the idea of customer CPEs updating their
> > own PTR records to be completely unacceptable. So I guess I'll either
> > live without the reverse DNS, or use a name server that can synthesize
> > answers on the fly.
> 
> That seems like a really nice feature, create a reverse record to spoof
> a mail server and the reverse DNS will match up.
> 
> If the domain does not employ SPF it will look legit, forward and
> reverse won't match up ofcourse. Not sure how many mailservers have
> issues with that if the reverse matches up.
> 
> Sounds like a fine way to employ a spam botnet.

Sounds like FUD.  Who has trusted the contents of a PTR record in the
last 2 decades?

> Regards,
> 
> Seth
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From bmanning at vacation.karoshi.com  Tue Nov  8 05:11:15 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 8 Nov 2011 11:11:15 +0000
Subject: Performance Issues - PTR Records
In-Reply-To: <20111108110512.72E8116E19F7@drugs.dv.isc.org>
References: <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no>
 <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl>
 <20111108110512.72E8116E19F7@drugs.dv.isc.org>
Message-ID: <20111108111115.GC5979@vacation.karoshi.com.>

On Tue, Nov 08, 2011 at 10:05:12PM +1100, Mark Andrews wrote:
> 
> In message <4EB8F028.8040607 at dds.nl>, Seth Mos writes:
> > On 7-11-2011 14:46, sthaug at nethelp.no wrote:
> > >>> The practice of filling out the reverse zone with fake PTR record
> > >>> started before there was wide spread support for UPDATE/DNS.  There
> > >>> isn't any need for this to be done anymore.  Machines are capable
> > >>> of adding records for themselves.
> > >>
> > >> How do I setup this for DHCPv6-PD?  Say, I delegate 2001:db8:42::/48 to
> > >> the end user.  Should I delegate reverse DNS as well?  If so, to whom?
> > >>
> > >> Or is it the CPEs responibility to dynamically add records for whatever
> > >> addresses it sees on the internal LAN(s)?  Are there CPEs capable of
> > >> doing this?
> > >>
> > >> Or will the end systems themselves do the update against my DNS server?
> > >> If so, how do I authenticate that?
> > > 
> > > With my ISP hat on, I find the idea of customer CPEs updating their
> > > own PTR records to be completely unacceptable. So I guess I'll either
> > > live without the reverse DNS, or use a name server that can synthesize
> > > answers on the fly.
> > 
> > That seems like a really nice feature, create a reverse record to spoof
> > a mail server and the reverse DNS will match up.
> > 
> > If the domain does not employ SPF it will look legit, forward and
> > reverse won't match up ofcourse. Not sure how many mailservers have
> > issues with that if the reverse matches up.
> > 
> > Sounds like a fine way to employ a spam botnet.
> 
> Sounds like FUD.  Who has trusted the contents of a PTR record in the
> last 2 decades?
> 
> > Regards,
> > 
> > Seth
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


	the same people who trust the contents of an A record in the
	last 2 decades.

/bill


From jeroen at unfix.org  Tue Nov  8 05:13:54 2011
From: jeroen at unfix.org (Jeroen Massar)
Date: Tue, 08 Nov 2011 12:13:54 +0100
Subject: Performance Issues - PTR Records
In-Reply-To: <20111108110512.72E8116E19F7@drugs.dv.isc.org>
References: <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no>
 <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl>
 <20111108110512.72E8116E19F7@drugs.dv.isc.org>
Message-ID: <4EB90EF2.3030100@unfix.org>

On 2011-11-08 12:05 , Mark Andrews wrote:
> In message <4EB8F028.8040607 at dds.nl>, Seth Mos writes:
[..]
> Sounds like FUD.  Who has trusted the contents of a PTR record in the
> last 2 decades?

Lots of tools (read: SSH, Spam-checks, oh and IRCd's ;) trust PTR, but
only if the reverse => forward => reverse. And you don't want to know
how many silly people enable the "if user comes from .in they must be
from Indonesia^WIndia thus block them" Apache option as recently
mentioned on this very thread.

Also, note that your precious operating system will likely store the
PTR, sometimes even without doing the reverse->forward->reverse check.

As such, you set up a PTR + Forward properly for a host, try to 'hack' a
box by password guessing, the log entries will only have the PTR
recorded, and you just drop the PTR+Forward from DNS (as they are under
your control) the admin comes in, sees all those nice hosts in their
logs but as it is gone from DNS will never ever find you. This
especially goes for 'who' (utmp) which makes that mistake. Fortunately
SSH at least logs both IP + hostname, the more info the better.


That said though the PTR->forward->PTR check is a proper check and a
really great way to figure out if the source SMTP host was actually set
up with at least some admin doing it the right way. If they can't be
bothered to set that up, why should you bother to accept that mail, or a
better choice, just score it a bit negatively at least.

Greets,
 Jeroen


From ryan at u13.net  Tue Nov  8 06:04:18 2011
From: ryan at u13.net (Ryan Rawdon)
Date: Tue, 8 Nov 2011 07:04:18 -0500
Subject: XO blocking individual IP's
In-Reply-To: <8cd9ddd28acb187bf24131339f00e806.squirrel@emailmg.ipower.com>
References: <1822304.1989.1320720702784.JavaMail.root@benjamin.baylink.com>
 <8cd9ddd28acb187bf24131339f00e806.squirrel@emailmg.ipower.com>
Message-ID: <F869422C-F42B-4CB8-B471-B23EBD41F4EE@u13.net>


On Nov 7, 2011, at 10:06 PM, clayton at haydel.org wrote:

> 
>> "transit provider".  Is XO the end-access provider for either you or the
>> destination site?  Or are both of those on some other connection, and XO
>> is a bystander along the way?
> 
> We're a direct customer.  The IP's that I've seen them block have been
> both on our network and on remote networks, so I suspect their filtering
> would affect any traffic that happened to pass over XO.
> 

While troubleshooting another issue last week, someone in the NOC at one of our ISPs mentioned that they had encountered something similar recently.

"This 
looks suspiciously like another XO issue we ran across in the last few 
months where they used a network security device that blocked 'suspicious' 
traffic on particular ports (although it was tcp based from what I could 
remember)."

In our case the symptoms looked like GBLX was eating traffic which hashed to a certain theoretical link (certain src-dst-srcport-dstport combinations) in a LAG or similar, but it was happening right near the XO-GBLX edge in the forward path so it's possible it was a security device at XO's edge.

From marka at isc.org  Tue Nov  8 06:27:31 2011
From: marka at isc.org (Mark Andrews)
Date: Tue, 08 Nov 2011 23:27:31 +1100
Subject: Performance Issues - PTR Records
In-Reply-To: Your message of "Tue, 08 Nov 2011 12:13:54 BST."
 <4EB90EF2.3030100@unfix.org>
References: <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no>
 <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl>
 <20111108110512.72E8116E19F7@drugs.dv.isc.org> <4EB90EF2.3030100@unfix.org>
Message-ID: <20111108122731.DF12116E2475@drugs.dv.isc.org>


In message <4EB90EF2.3030100 at unfix.org>, Jeroen Massar writes:
> On 2011-11-08 12:05 , Mark Andrews wrote:
> > In message <4EB8F028.8040607 at dds.nl>, Seth Mos writes:
> [..]
> > Sounds like FUD.  Who has trusted the contents of a PTR record in the
> > last 2 decades?
> 
> Lots of tools (read: SSH, Spam-checks, oh and IRCd's ;) trust PTR, but
> only if the reverse => forward => reverse. And you don't want to know
> how many silly people enable the "if user comes from .in they must be
> from Indonesia^WIndia thus block them" Apache option as recently
> mentioned on this very thread.

They arn't trusting the reverse record.  They are trusting the forward
record to verify the reverse record.  They know that the reverse record
is untrustworthy as the owner of the reverse zone can put whatever they
want there without spoofing anything.
 
> Also, note that your precious operating system will likely store the
> PTR, sometimes even without doing the reverse->forward->reverse check.

> As such, you set up a PTR + Forward properly for a host, try to 'hack' a
> box by password guessing, the log entries will only have the PTR
> recorded, and you just drop the PTR+Forward from DNS (as they are under
> your control) the admin comes in, sees all those nice hosts in their
> logs but as it is gone from DNS will never ever find you. This
> especially goes for 'who' (utmp) which makes that mistake. Fortunately
> SSH at least logs both IP + hostname, the more info the better.

Who trusts logs of names without actual addresses?   No one sane
does.

> That said though the PTR->forward->PTR check is a proper check and a
> really great way to figure out if the source SMTP host was actually set
> up with at least some admin doing it the right way. If they can't be
> bothered to set that up, why should you bother to accept that mail, or a
> better choice, just score it a bit negatively at least.

Which only works as a filter because ISP's decided to prevent home
users from putting valid PTR records in the DNS for their own
machines.  It has nothing to do with clue or knowlege.  

> Greets,
>  Jeroen
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From rdobbins at arbor.net  Tue Nov  8 06:34:47 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 8 Nov 2011 12:34:47 +0000
Subject: where was my white knight....
In-Reply-To: <20111108105631.GB5979@vacation.karoshi.com.>
References: <20111108105631.GB5979@vacation.karoshi.com.>
Message-ID: <E5584AA9-4B6F-421E-BD95-FEC487AC1E18@arbor.net>


On Nov 8, 2011, at 5:56 PM, <bmanning at vacation.karoshi.com> wrote:

> how would a sidr-enabled routing infrastructure have fared in yesterdays routing circus?

The effects of large amounts of route-churn on the auth chain - perhaps DANE? - might've been interesting . . .

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From jeroen at unfix.org  Tue Nov  8 08:25:04 2011
From: jeroen at unfix.org (Jeroen Massar)
Date: Tue, 08 Nov 2011 15:25:04 +0100
Subject: Performance Issues - PTR Records
In-Reply-To: <20111108122731.DF12116E2475@drugs.dv.isc.org>
References: <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no>
 <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl>
 <20111108110512.72E8116E19F7@drugs.dv.isc.org> <4EB90EF2.3030100@unfix.org>
 <20111108122731.DF12116E2475@drugs.dv.isc.org>
Message-ID: <4EB93BC0.9090503@unfix.org>

On 2011-11-08 13:27 , Mark Andrews wrote:
> In message <4EB90EF2.3030100 at unfix.org>, Jeroen Massar writes:
>> On 2011-11-08 12:05 , Mark Andrews wrote:
>>> In message <4EB8F028.8040607 at dds.nl>, Seth Mos writes:
>> [..]
>>> Sounds like FUD.  Who has trusted the contents of a PTR record in the
>>> last 2 decades?
>>
>> Lots of tools (read: SSH, Spam-checks, oh and IRCd's ;) trust PTR, but
>> only if the reverse => forward => reverse. And you don't want to know
>> how many silly people enable the "if user comes from .in they must be
>> from Indonesia^WIndia thus block them" Apache option as recently
>> mentioned on this very thread.
> 
> They arn't trusting the reverse record.  They are trusting the forward
> record to verify the reverse record. They know that the reverse record
> is untrustworthy as the owner of the reverse zone can put whatever they
> want there without spoofing anything.

Of course that is the case. The PTR itself is useless, but in combo with
checking it with the forward it is a very valuable resource.

(Add DNSSEC to the mix and you are even sure that nobody spoofed it on
the wire for you ;)

>> Also, note that your precious operating system will likely store the
>> PTR, sometimes even without doing the reverse->forward->reverse check.
> 
>> As such, you set up a PTR + Forward properly for a host, try to 'hack' a
>> box by password guessing, the log entries will only have the PTR
>> recorded, and you just drop the PTR+Forward from DNS (as they are under
>> your control) the admin comes in, sees all those nice hosts in their
>> logs but as it is gone from DNS will never ever find you. This
>> especially goes for 'who' (utmp) which makes that mistake. Fortunately
>> SSH at least logs both IP + hostname, the more info the better.
> 
> Who trusts logs of names without actual addresses?   No one sane
> does.

Well, only one decade back some people from this very list mentioned
that to a certain OS that is used quite a lot by a lot of people:

http://www.freebsd.org/cgi/query-pr.cgi?pr=22595

And today that is still the case:
http://www.freebsd.org/cgi/man.cgi?query=utmp&sektion=5

Note there is just ut_host there is no address being stored, I hope you
yourself btw don't use any FreeBSD based devices as otherwise that
little attempt at an insult goes for you too ;)

>> That said though the PTR->forward->PTR check is a proper check and a
>> really great way to figure out if the source SMTP host was actually set
>> up with at least some admin doing it the right way. If they can't be
>> bothered to set that up, why should you bother to accept that mail, or a
>> better choice, just score it a bit negatively at least.
> 
> Which only works as a filter because ISP's decided to prevent home
> users from putting valid PTR records in the DNS for their own
> machines.  It has nothing to do with clue or knowlege.  

I don't think ISPs 'decide' to not let users set up reverse DNS, it is
generally a 'feature' for which they can ask more moneyz.

If ISPs would allow it (which I am for btw) then they only pass the test
anyway if they can properly setup reverse->forward->reverse.
Which is likely the case anyway for quite some ISPs who populate
reverses with a matching forward&reverse based on the IP.

Greets,
 Jeroen


From jra at baylink.com  Tue Nov  8 08:27:40 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 8 Nov 2011 09:27:40 -0500 (EST)
Subject: XO blocking individual IP's
In-Reply-To: <8cd9ddd28acb187bf24131339f00e806.squirrel@emailmg.ipower.com>
Message-ID: <28839839.2035.1320762460523.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: clayton at haydel.org

> > "transit provider". Is XO the end-access provider for either you or the
> > destination site? Or are both of those on some other connection, and XO
> > is a bystander along the way?
> 
> We're a direct customer. The IP's that I've seen them block have been
> both on our network and on remote networks, so I suspect their
> filtering would affect any traffic that happened to pass over XO.

Ah, ok.  Well, that certainly gives them standing to be filtering the traffic;
whether you think their reasoning is justified becomes a different level of
question at that point.

I concur with you that their filtering probably isn't justified, but I suspect
you'd find your contract permits it.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From antonio.ferretti at telecomitalia.it  Tue Nov  8 08:34:36 2011
From: antonio.ferretti at telecomitalia.it (Ferretti Antonio)
Date: Tue, 8 Nov 2011 15:34:36 +0100
Subject: Juniper MX960 Mqchip packet lenght error
Message-ID: <7F682CB8F5E45A4899F807AA4FEA854213DD9A3D@GRFMBX707RM001.griffon.local>

Hi all,

After upgrading Juniper MX960 from 4x10Gbe DPCE to 16x10Gbe MPC, I see strange log messages like this:

Fpc10 MQCHIP(0) LI Packet length error, pt entry 22

Seems to be only a "cosmetic" message, but today my team found some traffic dropped on interface on this card (before we only request check about log message).
Has anyone the same problem?

My software release is Junos 10.3R3.7.

Thanks in advance.

Antonio Ferretti
Network Engineer
Telecom Italia Sparkle
Backbone IP&Data Operations
Seabone 2nd Level Support
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

[cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo Ambiente_foglia.jpg
Type: image/jpeg
Size: 677 bytes
Desc: logo Ambiente_foglia.jpg
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111108/7eb36bcc/attachment.jpg>

From antonio.ferretti at telecomitalia.it  Tue Nov  8 09:33:00 2011
From: antonio.ferretti at telecomitalia.it (Ferretti Antonio)
Date: Tue, 8 Nov 2011 16:33:00 +0100
Subject: R: Juniper MX960 Mqchip packet lenght error
In-Reply-To: <19992_1320765182_4EB946FE_19992_10550_1_26812F15C2B5A8438D1C9BFCDEF73FEC2571539680@PMEXCB1A.intranet-paris.francetelecom.fr>
References: <7F682CB8F5E45A4899F807AA4FEA854213DD9A3D@GRFMBX707RM001.griffon.local>
 <19992_1320765182_4EB946FE_19992_10550_1_26812F15C2B5A8438D1C9BFCDEF73FEC2571539680@PMEXCB1A.intranet-paris.francetelecom.fr>
Message-ID: <7F682CB8F5E45A4899F807AA4FEA854213DD9AB2@GRFMBX707RM001.griffon.local>

Thx David,

PR587266 seems to be related to "maximum-packet-lenght" command that is not present in my config.

Biggest problem in this case are dropped packet on interface:

Physical interface: xe-10/0/1, Enabled, Physical link is Up
  Interface index: 363, SNMP ifIndex: 645, Generation: 483
  Description: No Description
  Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 10Gbps, Loopback: None, Source filtering: Disabled,
  Flow control: Enabled
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x4000
  Link flags     : None
  CoS queues     : 8 supported, 8 maximum usable queues
  Hold-times     : Up 0 ms, Down 0 ms
  Current address: 00:24:dc:49:be:73, Hardware address: 00:24:dc:49:be:73
  Last flapped   : 2011-10-27 03:11:07 UTC (1w5d 12:18 ago)
  Statistics last cleared: 2011-11-08 13:15:03 UTC (02:14:38 ago)
  Traffic statistics:
   Input  bytes  :        4674308593808           5182909688 bps
   Output bytes  :        6092283580895           6656998280 bps
   Input  packets:           8393093736              1149495 pps
   Output packets:           6971170539               941600 pps
   IPv6 transit statistics:
    Input  bytes  :            23569859
    Output bytes  :                   0
    Input  packets:              197870
    Output packets:                   0
  Dropped traffic statistics due to STP State:
   Input  bytes  :                    0
   Output bytes  :                    0
   Input  packets:                    0
   Output packets:                    0
  Input errors:
    Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3 incompletes: 0, L2 channel errors: 0,
    L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0
  Output errors:
    Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0, FIFO errors: 0, HS link CRC errors: 0,
    MTU errors: 0, Resource errors: 0
  Egress queues: 8 supported, 8 in use
  Queue counters:       Queued packets  Transmitted packets      Dropped packets
    0 be                    6973872756           6887958719      85914037
    1 ef                      25695717             25695717      0
    2 ef1                      2062122              2062122      0
    3 ef2                     21430966             21430966      0
    4 af                       2605818              2605818      0
    5 af1                      1577987              1577987      0
    6 nc                       5928647              5928647      0
    7 nc1                     24705296             24705296      0

I'm wondering if is something related to CoS that is managed in different way from the two type of linecard.

Regards

Antonio Ferretti
Network Engineer
Telecom Italia Sparkle
TIS.AD.NDO.O Backbone IP&Data Operations
Seabone 2nd Level Support
Via di Macchia Palocco, 223
00125 Roma, Italia
-----Messaggio originale-----
Da: david.roy at orange.com [mailto:david.roy at orange.com]
Inviato: marted? 8 novembre 2011 16.13
A: Ferretti Antonio; nanog at nanog.org
Oggetto: RE: Juniper MX960 Mqchip packet lenght error

Hi,

See the PR587266. Maybe you have Syslog/log statement in a FW filter term.

Regards
David



David Roy
Orange - IP Domestic Backbone - TAC
Tel.   +33(0)299876472
Mob. +33(0)685522213
Email. david.roy at orange.com
Skype : davidroy.35
JNCIE-SP #703

Guest Haiku :
IS-IS screams,
BGP peers are flapping:
I want my mommy!



-----Message d'origine-----
De : Ferretti Antonio [mailto:antonio.ferretti at telecomitalia.it]
Envoy? : mardi 8 novembre 2011 15:35
? : nanog at nanog.org
Objet : Juniper MX960 Mqchip packet lenght error

Hi all,

After upgrading Juniper MX960 from 4x10Gbe DPCE to 16x10Gbe MPC, I see strange log messages like this:

Fpc10 MQCHIP(0) LI Packet length error, pt entry 22

Seems to be only a "cosmetic" message, but today my team found some traffic dropped on interface on this card (before we only request check about log message).
Has anyone the same problem?

My software release is Junos 10.3R3.7.

Thanks in advance.

Antonio Ferretti
Network Engineer
Telecom Italia Sparkle
Backbone IP&Data Operations
Seabone 2nd Level Support
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

[cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario.


********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.



From suess13 at cfl.rr.com  Tue Nov  8 09:42:58 2011
From: suess13 at cfl.rr.com (Suess13)
Date: Tue, 8 Nov 2011 10:42:58 -0500
Subject: NANOG Digest, Vol 46, Issue 15
In-Reply-To: <0F7F9A82BB0DBB4396A9F8386D0E0612071F65A3@pos-exch1.corp.positivenetworks.net>
References: <mailman.13480.1320681914.1873.nanog@nanog.org>
 <0F7F9A82BB0DBB4396A9F8386D0E0612071F65A3@pos-exch1.corp.positivenetworks.net>
Message-ID: <FA3B3805-814B-4BAF-8477-86F81675EB56@cfl.rr.com>

Juniper core dump issue, patch is on the way.



On Nov 7, 2011, at 11:41 AM, "Steve Dispensa" <dispensa at phonefactor.com> wrote:

> Level 3 was down in KC, Chi, and San Jose (at least) for us between
> about 8:10 and 8:40, plus or minus. Brought down SureWest in KC too.
> 
> -Steve
> 
>> -----Original Message-----
>> From: nanog-request at nanog.org [mailto:nanog-request at nanog.org]
>> Sent: Monday, November 07, 2011 10:05 AM
>> To: nanog at nanog.org
>> Subject: NANOG Digest, Vol 46, Issue 15
>> 
>> Send NANOG mailing list submissions to
>>    nanog at nanog.org
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>    https://mailman.nanog.org/mailman/listinfo/nanog
>> or, via email, send a message with subject or body 'help' to
>>    nanog-request at nanog.org
>> 
>> You can reach the person managing the list at
>>    nanog-owner at nanog.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of NANOG digest..."
>> 
>> 
>> Today's Topics:
>> 
>>   1. Re: Time Warner Telecom problems (Jon Lewis)
>>   2. Re: Performance Issues - PTR Records (Leigh Porter)
>>   3. Re: Time Warner Telecom problems (Ray Van Dolson)
>>   4. General Internet Instability (Jared Mauch)
>>   5. Re: TATA problems? (Pierre-Yves Maunier)
>>   6. Re: TATA problems? (Leigh Porter)
>>   7. Re: Time Warner Telecom problems (Joe Greco)
>>   8. Re: TATA problems? (Kelly Kane)
>>   9. Re: Time Warner Telecom problems (Blake Hudson)
>>  10. RE: Time Warner Telecom problems (Thomas York)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Mon, 7 Nov 2011 10:12:30 -0500 (EST)
>> From: Jon Lewis <jlewis at lewis.org>
>> To: Peter Pauly <ppauly at gmail.com>
>> Cc: nanog at nanog.org
>> Subject: Re: Time Warner Telecom problems
>> Message-ID: <Pine.LNX.4.61.1111071005540.24418 at soloth.lewis.org>
>> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>> 
>> On Mon, 7 Nov 2011, Peter Pauly wrote:
>> 
>>> Gizmodo is reporting problems at Time Warner Telecom .... we're
>> suffering
>>> from it too and calls to the NOC have not been answered so far...
> does
>>> anyone have any further information?
>>> 
>>> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
>> 
>> I noticed just a little while ago that we're having a lot of DNS fail.
>> Initial findings were that several of the root-servers we were trying
> to
>> reach via our TWTelecom link were unreachable after 2 hops into TWT.
>> 
>>  4  64-128-130-233.static.twtelecom.NET (64.128.130.233)  2.399 ms
> 2.298
>> ms  2.338 ms
>>  5  mia2-pr1-xe-1-3-0-0.us.twtelecom.net (66.192.253.18)  11.571 ms
>> 11.552 ms  9.467 ms
>>  6  * * *
>>  7  * * *
>>  8  * * *
>> 
>> For instance, a.root-servers.net is pingable from a rackspace server,
> but
>> not from our network (unless I shut off TWT, at which point it is, but
>> it's apparently not the same a.root-servers.net instance rackspace
> sees).
>> I assume this is one of the root-servers being anycast.
>> 
>> Shutting off our BGP with TWT didn't appear to help (though the
>> root-servers became reachable)...so I assume there's more going on
> than
>> just TWT routing fail.
>> 
>> ----------------------------------------------------------------------
>>  Jon Lewis, MCP :)           |  I route
>>  Senior Network Engineer     |  therefore you are
>>  Atlantic Net                |
>> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 2
>> Date: Mon, 7 Nov 2011 15:29:30 +0000
>> From: Leigh Porter <leigh.porter at ukbroadband.com>
>> To: Bj?rn Mork <bjorn at mork.no>
>> Cc: "nanog at nanog.org" <nanog at nanog.org>
>> Subject: Re: Performance Issues - PTR Records
>> Message-ID: <53A4963F-4969-4A60-BF06-E690C7324863 at ukbroadband.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> 
>> 
>> On 7 Nov 2011, at 14:03, "Bj?rn Mork" <bjorn at mork.no> wrote:
>> 
>>> Leigh Porter <leigh.porter at ukbroadband.com> writes:
>>> 
>>>> Indeed, there is no way I would allow that either. But really,
>>>> providing a reverse zone and forward zone to match is a case of
> five
>>>> minutes and a shell script or a DNS that as Steinar said, will
>>>> synthesise results.
>>>> 
>>>> It's really not all that difficult..
>>> 
>>> No, not at all.  It's just totally pointless.  Any IPv6 address is
> just
>>> as pretty as a synthesized name.  Maybe even prettier. Do you prefer
>>> "2001:db8:1::2" or
> "20010db8000100000000000000000002.rev.example.com"?
>>> 
>>> If we're going to provide any reverse DNS for end users, then it is
>>> because we can create names which actually improves something.
>>> 
>>> 
>>> Bj?rn
>>> 
>>> 
>> 
>> Yup it is pointless.. Mine are all ipadrress.domain which is of
> course,
>> pointless.. I suppose at least somebody would glean that perhaps its a
>> home user rather than a business or server on that address but that's
> all.
>> 
>> With IPv6 arguably even more pointless as you say.
>> 
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 3
>> Date: Mon, 7 Nov 2011 07:28:18 -0800
>> From: Ray Van Dolson <rvandolson at esri.com>
>> To: nanog at nanog.org
>> Subject: Re: Time Warner Telecom problems
>> Message-ID: <20111107152817.GA29715 at esri.com>
>> Content-Type: text/plain; charset=us-ascii
>> 
>> On Mon, Nov 07, 2011 at 07:04:19AM -0800, Peter Pauly wrote:
>>> Gizmodo is reporting problems at Time Warner Telecom .... we're
>> suffering
>>> from it too and calls to the NOC have not been answered so far...
> does
>>> anyone have any further information?
>>> 
>>> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
>> 
>> FWIW, my home TWC connection dropped this morning for about 15 minutes
>> (Southern California around 6:30AM'ish).  Still could ping the default
>> gateway, but packets weren't traversing much beyond that.
>> 
>> Didn't investigate further, just headed into work.
>> 
>> Ray
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 4
>> Date: Mon, 7 Nov 2011 10:31:31 -0500
>> From: Jared Mauch <jared at puck.nether.net>
>> To: Tom Hill <tom at ninjabadger.net>
>> Cc: nanog at nanog.org
>> Subject: General Internet Instability
>> Message-ID: <B6567BC5-75E9-4E58-AFA9-5ADC0C2A7BDD at puck.nether.net>
>> Content-Type: text/plain; charset=us-ascii
>> 
>> On Nov 7, 2011, at 10:08 AM, Tom Hill wrote:
>> 
>>> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
>>>> We seem to be having some problems with our tata links - first seen
> in
>> EU
>>>> about 45 minutes ago, now we're seeing problems in NA.  I'm focused
> on
>> DNS,
>>>> so I'm seeing a lot of timeouts/servfails, but our networking folks
> are
>>>> talking about links dropping.
>>>> 
>>>> Anyone else seeing oddness on the NA Internet right now?
>>>> 
>>>> http://downrightnow.com/ confirms - something is up.
>>> 
>>> There are widespread issues across the Internet; certain versions of
>>> Juniper firmware have core dumped after seeing a particular BGP
> 'UPDATE'
>>> message.
>>> 
>>> (That's the running theory at least).
>>> 
>>> It's affected multiple service providers, globally, not just those
>>> connected to TATA.
>> 
>> 
>> Pretty much any major BGP event will impact multiple providers.
>> 
>> A threshold you should use to view the general instability (which I
> find
>> valuable, you may as well) is route views data.
>> 
>> If you look at the BGP UPDATES archive sizes, you can see when
> something
>> happens, e.g.:
>> 
>> http://archive.routeviews.org/bgpdata/2011.11/UPDATES/
>> 
>> Take a look at the size of the updates.20111107.1400.bz2 file and the
> 1415
>> file.  They are abnormally large compared to a normal period of time.
>> This shows there were a lot of updates out there being processed and a
>> reference to levels of instability.
>> 
>> If you are not feeding route views or similar community projects,
> please
>> consider doing so.  It helps paint the view for those doing analysis.
>> 
>> - Jared
>> 
>> 
>> ------------------------------
>> 
>> Message: 5
>> Date: Mon, 7 Nov 2011 16:33:15 +0100
>> From: Pierre-Yves Maunier <nanog at maunier.org>
>> To: Tom Hill <tom at ninjabadger.net>
>> Cc: nanog at nanog.org
>> Subject: Re: TATA problems?
>> Message-ID:
>> 
> <CAEGdXrM+2rFXG2=d80kO_1ObtAv=24npNqZsLCTXUxeKS9q9yA at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>> 
>> 2011/11/7 Tom Hill <tom at ninjabadger.net>
>> 
>>> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
>>>> We seem to be having some problems with our tata links - first
> seen in
>> EU
>>>> about 45 minutes ago, now we're seeing problems in NA.  I'm
> focused on
>>> DNS,
>>>> so I'm seeing a lot of timeouts/servfails, but our networking
> folks
>> are
>>>> talking about links dropping.
>>>> 
>>>> Anyone else seeing oddness on the NA Internet right now?
>>>> 
>>>> http://downrightnow.com/ confirms - something is up.
>>> 
>>> There are widespread issues across the Internet; certain versions of
>>> Juniper firmware have core dumped after seeing a particular BGP
> 'UPDATE'
>>> message.
>>> 
>>> (That's the running theory at least).
>>> 
>>> It's affected multiple service providers, globally, not just those
>>> connected to TATA.
>>> 
>>> Tom
>>> 
>>> 
>>> 
>> On our side all our 10.3R2.11 core dumped which made all our
> interfaces
>> flapped.
>> I've been told 10.4R1.9 is affected too.
>> 
>> --
>> Pierre-Yves Maunier
>> 
>> 
>> ------------------------------
>> 
>> Message: 6
>> Date: Mon, 7 Nov 2011 15:45:18 +0000
>> From: Leigh Porter <leigh.porter at ukbroadband.com>
>> To: Pierre-Yves Maunier <nanog at maunier.org>
>> Cc: "nanog at nanog.org" <nanog at nanog.org>
>> Subject: Re: TATA problems?
>> Message-ID: <7994AF08-0622-434F-974F-FC9269469176 at ukbroadband.com>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> 
>> My 10.4r1.9 boxes died also but I saw interfaces go down whilst bgpd
>> seemed stable.
>> 
>> --
>> Leigh
>> 
>> 
>> On 7 Nov 2011, at 15:34, "Pierre-Yves Maunier" <nanog at maunier.org>
> wrote:
>> 
>>> 2011/11/7 Tom Hill <tom at ninjabadger.net>
>>> 
>>>> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote:
>>>>> We seem to be having some problems with our tata links - first
> seen in
>> EU
>>>>> about 45 minutes ago, now we're seeing problems in NA.  I'm
> focused on
>>>> DNS,
>>>>> so I'm seeing a lot of timeouts/servfails, but our networking
> folks
>> are
>>>>> talking about links dropping.
>>>>> 
>>>>> Anyone else seeing oddness on the NA Internet right now?
>>>>> 
>>>>> http://downrightnow.com/ confirms - something is up.
>>>> 
>>>> There are widespread issues across the Internet; certain versions
> of
>>>> Juniper firmware have core dumped after seeing a particular BGP
>> 'UPDATE'
>>>> message.
>>>> 
>>>> (That's the running theory at least).
>>>> 
>>>> It's affected multiple service providers, globally, not just those
>>>> connected to TATA.
>>>> 
>>>> Tom
>>>> 
>>>> 
>>>> 
>>> On our side all our 10.3R2.11 core dumped which made all our
> interfaces
>>> flapped.
>>> I've been told 10.4R1.9 is affected too.
>>> 
>>> --
>>> Pierre-Yves Maunier
>>> 
>>> 
> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security
> System.
>>> For more information please visit http://www.messagelabs.com/email
>>> 
> ______________________________________________________________________
>> 
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 7
>> Date: Mon, 7 Nov 2011 09:54:25 -0600 (CST)
>> From: Joe Greco <jgreco at ns.sol.net>
>> To: ppauly at gmail.com (Peter Pauly)
>> Cc: nanog at nanog.org
>> Subject: Re: Time Warner Telecom problems
>> Message-ID: <201111071554.pA7FsPHb045359 at aurora.sol.net>
>> Content-Type: text/plain; charset=us-ascii
>> 
>>> Gizmodo is reporting problems at Time Warner Telecom .... we're
>> suffering
>>> from it too and calls to the NOC have not been answered so far...
> does
>>> anyone have any further information?
>>> 
>>> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
>> 
>> Actually, it looks to me like they mean "Time Warner", because that's
>> what they said.
>> 
>> The company once known as "Time Warner Telecom" has always been a
>> different entity, and hasn't been known as that in some time, now
>> being called "twtelecom."  Much of that company is what was once
>> known as inc.net, a Milwaukee area provider of the '90's.
>> 
>> Time Warner Cable appears to have experienced an implosion this
> morning,
>> being out of service for about 11 minutes.  During that time, packets
>> originating here in Milwaukee quickly died in Chicago;
>> 
>> 1  76.46.192.1  8.320 ms  9.900 ms  7.974 ms
>> 2  24.160.230.32  7.967 ms  5.975 ms  8.479 ms
>> 3  24.160.229.132  8.471 ms  7.969 ms  10.991 ms
>> 4  24.160.229.193  9.972 ms  9.973 ms
>>    24.160.229.197  9.985 ms
>> 5  * * *
>> 6  * * *
>> 
>> while packets destined for RR all seemed to be headed out to SJC, from
>> what I can tell.
>> 
>> ... JG
>> --
>> Joe Greco - sol.net Network Services - Milwaukee, WI -
> http://www.sol.net
>> "We call it the 'one bite at the apple' rule. Give me one chance [and]
>> then I
>> won't contact you again." - Direct Marketing Ass'n position on e-mail
>> spam(CNN)
>> With 24 million small businesses in the US alone, that's way too many
>> apples.
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 8
>> Date: Mon, 7 Nov 2011 07:55:33 -0800
>> From: Kelly Kane <kelly at hawknetworks.com>
>> To: Tim Vollebregt <tim at interworx.nl>
>> Cc: nanog at nanog.org
>> Subject: Re: TATA problems?
>> Message-ID:
>> 
> <CAKfXD0zrH9TJkN=7doGe1uAq8zxVszyvtJYfLLTbiC6+UMy4ww at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>> 
>> On Mon, Nov 7, 2011 at 07:06, Tim Vollebregt <tim at interworx.nl> wrote:
>>> 
>>> On #IX there are rumours about Junos version 10.3R2.11 being core
> dumped
>> and
>>> rebooted, which makes sense.
>> 
>> Perhaps related to Juniper PSN-2011-08-327? Did the whole router
>> reboot, or just the service module?
>> 
>> We saw one TATA session, and one Abovenet session flap.
>> 
>> Kelly
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 9
>> Date: Mon, 07 Nov 2011 10:02:13 -0600
>> From: Blake Hudson <blake at ispn.net>
>> To: nanog at nanog.org
>> Subject: Re: Time Warner Telecom problems
>> Message-ID: <4EB80105.8060703 at ispn.net>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>> 
>> 
>> Joe Greco wrote the following on 11/7/2011 9:54 AM:
>>>> Gizmodo is reporting problems at Time Warner Telecom .... we're
>> suffering
>>>> from it too and calls to the NOC have not been answered so far...
> does
>>>> anyone have any further information?
>>>> 
>>>> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
>>> Actually, it looks to me like they mean "Time Warner", because
> that's
>>> what they said.
>>> 
>>> The company once known as "Time Warner Telecom" has always been a
>>> different entity, and hasn't been known as that in some time, now
>>> being called "twtelecom."  Much of that company is what was once
>>> known as inc.net, a Milwaukee area provider of the '90's.
>>> 
>>> Time Warner Cable appears to have experienced an implosion this
> morning,
>>> being out of service for about 11 minutes.  During that time,
> packets
>>> originating here in Milwaukee quickly died in Chicago;
>> 
>> Using the looking glass from TWtelecom, we saw 30-60min outage
> (roughly
>> 8:30AM to 9:30AM CST) between the Kansas City location and our own
>> server room in Kansas City. Other TWtelecom locations appeared to be
>> unaffected. Perhaps TWtelecom is served by Timewarner or shares
>> equipment in KC. Either way, none of our KC customers who were served
>> via TWtelecom or Timewarner were able to reach us. Packets would hit
>> Level 3 Communications and die in either direction at the border
> between
>> L3 and TW. FWIW, TW was showing a good BGP route to us and vise versa.
>> http://lglass.twtelecom.net/
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 10
>> Date: Mon, 7 Nov 2011 11:04:59 -0500
>> From: "Thomas York" <straterra at fuhell.com>
>> To: "'Blake Hudson'" <blake at ispn.net>,    <nanog at nanog.org>
>> Subject: RE: Time Warner Telecom problems
>> Message-ID: <c23401cc9d67$046baea0$0d430be0$@fuhell.com>
>> Content-Type: text/plain;    charset="utf-8"
>> 
>> FWIW, We saw issues here in Indianapolis between TWTC and L3 up until
> a
>> few minutes ago.
>> 
>> --Thomas York
>> 
>> -----Original Message-----
>> From: Blake Hudson [mailto:blake at ispn.net]
>> Sent: Monday, November 07, 2011 11:02 AM
>> To: nanog at nanog.org
>> Subject: Re: Time Warner Telecom problems
>> 
>> 
>> Joe Greco wrote the following on 11/7/2011 9:54 AM:
>>>> Gizmodo is reporting problems at Time Warner Telecom .... we're
>>>> suffering from it too and calls to the NOC have not been answered
> so
>>>> far...  does anyone have any further information?
>>>> 
>>>> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us
>>> Actually, it looks to me like they mean "Time Warner", because
> that's
>>> what they said.
>>> 
>>> The company once known as "Time Warner Telecom" has always been a
>>> different entity, and hasn't been known as that in some time, now
>>> being called "twtelecom."  Much of that company is what was once
> known
>>> as inc.net, a Milwaukee area provider of the '90's.
>>> 
>>> Time Warner Cable appears to have experienced an implosion this
>>> morning, being out of service for about 11 minutes.  During that
> time,
>>> packets originating here in Milwaukee quickly died in Chicago;
>> 
>> Using the looking glass from TWtelecom, we saw 30-60min outage
> (roughly
>> 8:30AM to 9:30AM CST) between the Kansas City location and our own
> server
>> room in Kansas City. Other TWtelecom locations appeared to be
> unaffected.
>> Perhaps TWtelecom is served by Timewarner or shares equipment in KC.
>> Either way, none of our KC customers who were served via TWtelecom or
>> Timewarner were able to reach us. Packets would hit Level 3
> Communications
>> and die in either direction at the border between
>> L3 and TW. FWIW, TW was showing a good BGP route to us and vise versa.
>> http://lglass.twtelecom.net/
>> 
>> 
>> 
>> 
>> 
>> End of NANOG Digest, Vol 46, Issue 15
>> *************************************
> 


From mleber at he.net  Tue Nov  8 12:01:04 2011
From: mleber at he.net (Mike Leber)
Date: Tue, 08 Nov 2011 10:01:04 -0800
Subject: where was my white knight....
In-Reply-To: <20111108105631.GB5979@vacation.karoshi.com.>
References: <20111108105631.GB5979@vacation.karoshi.com.>
Message-ID: <4EB96E60.9090707@he.net>


We saw an increase in IPv6 traffic which correlated time wise with the 
onset of this IPv4 incident.

Happy eyeballs in action, automatically shifting what it could.

Mike.

On 11/8/11 2:56 AM, bmanning at vacation.karoshi.com wrote:
> how would a sidr-enabled routing infrastructure have fared in yesterdays routing circus?
>
> /bill
>


From Valdis.Kletnieks at vt.edu  Tue Nov  8 12:05:27 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 08 Nov 2011 13:05:27 -0500
Subject: [outages] More notes
In-Reply-To: Your message of "Tue, 08 Nov 2011 09:21:37 +0100."
 <20111108082137.GA20928@nic.fr>
References: <CAHsqw9sw1BbPMNUftpNUfoX7o2KVJNGPJHzN0itNxeE0JR6ADQ@mail.gmail.com>
 <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com>
 <CAMKfM=gyKttBxgzYWA8zK=wbTEG0=te4eJEtwZO=g8cDoY2tVw@mail.gmail.com>
 <20111108082137.GA20928@nic.fr>
Message-ID: <6995.1320775527@turing-police.cc.vt.edu>

On Tue, 08 Nov 2011 09:21:37 +0100, Stephane Bortzmeyer said:
> I disagree. The official bug statement from Juniper in August was
> trying very hard to downplay the importance of the bug ("Given the
> complexity of conditions required to trigger this issue, the
> probability of exploiting this defect is extremely low"). No wonder so
> few people (and not only at Level-3) did not upgrade.

August (and if that's when the *fix* came out, the bug is even older).

September.

October.

November.  So maybe the probability *is* low.

And if JunOS is anything like CIsco IOS, a lot of shops didn't upgrade because
the newer release has *other* issues in their environments.  Nobody wants to
upgrade to fix a once-ever-few-months bug if it also buys them a daily crash in
something else.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111108/af1eae98/attachment.bin>

From bmanning at vacation.karoshi.com  Tue Nov  8 12:14:59 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 8 Nov 2011 18:14:59 +0000
Subject: where was my white knight....
In-Reply-To: <4EB96E60.9090707@he.net>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net>
Message-ID: <20111108181459.GA13752@vacation.karoshi.com.>


 that was/is kindof orthoginal to the question... would the sidr plan
for routing security have been a help in this event?  nice to know 
unsecured IPv6 took some of the load when the unsecured IPv4 path
failed. 

 the answer seems to be NO, it would not have helped and would have actually
contributed to network instability with large numbers of validation requests
sent to the sidr/ca nodes...

/bill

On Tue, Nov 08, 2011 at 10:01:04AM -0800, Mike Leber wrote:
> 
> We saw an increase in IPv6 traffic which correlated time wise with the 
> onset of this IPv4 incident.
> 
> Happy eyeballs in action, automatically shifting what it could.
> 
> Mike.
> 
> On 11/8/11 2:56 AM, bmanning at vacation.karoshi.com wrote:
> >how would a sidr-enabled routing infrastructure have fared in yesterdays 
> >routing circus?
> >
> >/bill
> >


From rdobbins at arbor.net  Tue Nov  8 12:22:25 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 8 Nov 2011 18:22:25 +0000
Subject: where was my white knight....
In-Reply-To: <20111108181459.GA13752@vacation.karoshi.com.>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net> <20111108181459.GA13752@vacation.karoshi.com.>
Message-ID: <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net>


On Nov 9, 2011, at 1:14 AM, <bmanning at vacation.karoshi.com> wrote:

> that was/is kindof orthoginal to the question... would the sidr plan for routing security have been a help in this event? 

SIDR is intended to provide route-origination validation - it isn't intended to be nor can it possibly be a remedy for vendor-specific implementation problems.

Validation storm-control is something which must be accounted for in SIDR/DANE architecture, implementation, and deployment.  But at the end of the day, vendors are still responsible for their own code.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From rdobbins at arbor.net  Tue Nov  8 12:25:36 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 8 Nov 2011 18:25:36 +0000
Subject: where was my white knight....
In-Reply-To: <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net> <20111108181459.GA13752@vacation.karoshi.com.>
 <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net>
Message-ID: <3FF79D55-9167-4969-B612-A49666A98A1D@arbor.net>

On Nov 9, 2011, at 1:22 AM, Dobbins, Roland wrote:

> Validation storm-control is something which must be accounted for in SIDR/DANE architecture, implementation, and deployment.  But at the end of the day, vendors are still responsible for their own code.

To be clear, I was alluding to some discussion centering around DANE or a DANE-like mechanism to handle SIDR-type route validation.  Recursive dependencies make this a non-starter, IMHO.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From nick at foobar.org  Tue Nov  8 12:48:12 2011
From: nick at foobar.org (Nick Hilliard)
Date: Tue, 08 Nov 2011 18:48:12 +0000
Subject: where was my white knight....
In-Reply-To: <20111108181459.GA13752@vacation.karoshi.com.>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net> <20111108181459.GA13752@vacation.karoshi.com.>
Message-ID: <4EB9796C.9080009@foobar.org>

On 08/11/2011 18:14, bmanning at vacation.karoshi.com wrote:
>  the answer seems to be NO, it would not have helped and would have actually
> contributed to network instability with large numbers of validation requests
> sent to the sidr/ca nodes...

i'm curious about sidr cold bootup, specifically when you are attempting to
validate prefixes from an rpki CA or cache to which you do not necessarily
have network connectivity because your igp is not yet fully up.  The
phrases "layering violation" and "chicken and egg" come to mind.

Nick


From bmanning at vacation.karoshi.com  Tue Nov  8 12:54:02 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 8 Nov 2011 18:54:02 +0000
Subject: where was my white knight....
In-Reply-To: <3FF79D55-9167-4969-B612-A49666A98A1D@arbor.net>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net> <20111108181459.GA13752@vacation.karoshi.com.>
 <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net>
 <3FF79D55-9167-4969-B612-A49666A98A1D@arbor.net>
Message-ID: <20111108185402.GB13752@vacation.karoshi.com.>

On Tue, Nov 08, 2011 at 06:25:36PM +0000, Dobbins, Roland wrote:
> On Nov 9, 2011, at 1:22 AM, Dobbins, Roland wrote:
> 
> > Validation storm-control is something which must be accounted for in SIDR/DANE architecture, implementation, and deployment.  But at the end of the day, vendors are still responsible for their own code.
> 
> To be clear, I was alluding to some discussion centering around DANE or a DANE-like mechanism to handle SIDR-type route validation.  Recursive dependencies make this a non-starter, IMHO.
> 

	well... your still stuck w/ knowing where your CA is...

/bill


From bmanning at vacation.karoshi.com  Tue Nov  8 12:55:09 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 8 Nov 2011 18:55:09 +0000
Subject: where was my white knight....
In-Reply-To: <4EB9796C.9080009@foobar.org>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net> <20111108181459.GA13752@vacation.karoshi.com.>
 <4EB9796C.9080009@foobar.org>
Message-ID: <20111108185509.GC13752@vacation.karoshi.com.>

On Tue, Nov 08, 2011 at 06:48:12PM +0000, Nick Hilliard wrote:
> On 08/11/2011 18:14, bmanning at vacation.karoshi.com wrote:
> >  the answer seems to be NO, it would not have helped and would have actually
> > contributed to network instability with large numbers of validation requests
> > sent to the sidr/ca nodes...
> 
> i'm curious about sidr cold bootup, specifically when you are attempting to
> validate prefixes from an rpki CA or cache to which you do not necessarily
> have network connectivity because your igp is not yet fully up.  The
> phrases "layering violation" and "chicken and egg" come to mind.
> 
> Nick

	yeah...there is that.

/bill


From jbates at brightok.net  Tue Nov  8 13:03:24 2011
From: jbates at brightok.net (Jack Bates)
Date: Tue, 08 Nov 2011 13:03:24 -0600
Subject: [outages] More notes
In-Reply-To: <6995.1320775527@turing-police.cc.vt.edu>
References: <CAHsqw9sw1BbPMNUftpNUfoX7o2KVJNGPJHzN0itNxeE0JR6ADQ@mail.gmail.com>
 <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com>
 <CAMKfM=gyKttBxgzYWA8zK=wbTEG0=te4eJEtwZO=g8cDoY2tVw@mail.gmail.com>
 <20111108082137.GA20928@nic.fr> <6995.1320775527@turing-police.cc.vt.edu>
Message-ID: <4EB97CFC.3020508@brightok.net>

On 11/8/2011 12:05 PM, Valdis.Kletnieks at vt.edu wrote:
>
> And if JunOS is anything like CIsco IOS, a lot of shops didn't upgrade because
> the newer release has *other* issues in their environments.  Nobody wants to
> upgrade to fix a once-ever-few-months bug if it also buys them a daily crash in
> something else.
>
>

Juniper runs a quarterly (roughly major) 10.1, 10.2, 10.3, 10.4, ....

R is patch revisions for the major release. They are usually good at 
fixing and not breaking things on the R release. My last upgrade a bit 
ago was R7.5 of 10.4 (which has more revisions than older 10 releases, 
probably due to the fact that it will be the long term support release 
and gets non-critical patches as well).


Jack


From randy at psg.com  Tue Nov  8 13:16:10 2011
From: randy at psg.com (Randy Bush)
Date: Tue, 08 Nov 2011 20:16:10 +0100
Subject: where was my white knight....
In-Reply-To: <20111108181459.GA13752@vacation.karoshi.com.>
Message-ID: <m21utiv30l.wl%randy@psg.com>

> the answer seems to be NO, it would not have helped and would have
> actually contributed to network instability with large numbers of
> validation requests sent to the sidr/ca nodes...

utter bullshit.  maybe you would benefit by actually reading the doccos
and understanding the protocols.


From randy at psg.com  Tue Nov  8 13:19:14 2011
From: randy at psg.com (Randy Bush)
Date: Tue, 08 Nov 2011 20:19:14 +0100
Subject: where was my white knight....
In-Reply-To: <4EB9796C.9080009@foobar.org>
Message-ID: <m2zkg6tob1.wl%randy@psg.com>

> i'm curious about sidr cold bootup, specifically when you are
> attempting to validate prefixes from an rpki CA or cache to which you
> do not necessarily have network connectivity because your igp is not
> yet fully up.  The phrases "layering violation" and "chicken and egg"
> come to mind.

what comes to my mind is that NotFound is the default and it is
recommended to route on it.

i know boys are not allowed to read the manual, but this is starting
to get boring.

randy


From joshua.klubi at gmail.com  Tue Nov  8 13:59:43 2011
From: joshua.klubi at gmail.com (joshua.klubi at gmail.com)
Date: Tue, 8 Nov 2011 19:59:43 +0000
Subject: Logs Bank
Message-ID: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>

Hi, 

If I may ask, is there any OSS that can serve as a log bank or log server, where it aggregate logs from  different sources , and the logs can be accessed using the web from any location on the network and can do graphical presentations based on.the frequency or content os the logs.

Thank you

Joshua

-- 
Sent from my Nokia N9

From jna at retina.net  Tue Nov  8 14:00:30 2011
From: jna at retina.net (John Adams)
Date: Tue, 8 Nov 2011 12:00:30 -0800
Subject: Logs Bank
In-Reply-To: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
References: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
Message-ID: <72D9A217-326A-4089-9289-A5D67285949E@retina.net>

You probably want spunk, but if you want to do aggregation in an OSS fashion, scribe or flume is the way to go.

-John

Sent from my iPhone

On Nov 8, 2011, at 11:59, joshua.klubi at gmail.com wrote:

> Hi, 
> 
> If I may ask, is there any OSS that can serve as a log bank or log server, where it aggregate logs from  different sources , and the logs can be accessed using the web from any location on the network and can do graphical presentations based on.the frequency or content os the logs.
> 
> Thank you
> 
> Joshua
> 
> -- 
> Sent from my Nokia N9


From lstewart at superb.net  Tue Nov  8 14:00:49 2011
From: lstewart at superb.net (Landon Stewart)
Date: Tue, 8 Nov 2011 12:00:49 -0800
Subject: Logs Bank
In-Reply-To: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
References: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
Message-ID: <CABgOHgvDS3J-_kk93fvFsKemjjS6EFPoiBD-of7rtXiORRRXZg@mail.gmail.com>

On 8 November 2011 11:59, <joshua.klubi at gmail.com> wrote:

> Hi,
>
> If I may ask, is there any OSS that can serve as a log bank or log server,
> where it aggregate logs from  different sources , and the logs can be
> accessed using the web from any location on the network and can do
> graphical presentations based on.the frequency or content os the logs.
>

Do you mean like Splunk?  http://www.splunk.com

-- 
Landon Stewart <LStewart at SUPERB.NET>
SuperbHosting.Net by Superb Internet Corp.
Toll Free (US/Canada): 888-354-6128 x 4199
Direct: 206-438-5879
Web hosting and more "Ahead of the Rest": http://www.superbhosting.net

From charles at knownelement.com  Tue Nov  8 14:00:59 2011
From: charles at knownelement.com (Charles N Wyble)
Date: Tue, 08 Nov 2011 14:00:59 -0600
Subject: Logs Bank
In-Reply-To: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
References: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
Message-ID: <d99630b3-f7bc-4042-902e-8c43cbf3b83c@email.android.com>

Yes. Check out rsyslog and logstash. 

joshua.klubi at gmail.com wrote:

>Hi,
>
>If I may ask, is there any OSS that can serve as a log bank or log
>server, where it aggregate logs from  different sources , and the logs
>can be accessed using the web from any location on the network and can
>do graphical presentations based on.the frequency or content os the
>logs.
>
>Thank you
>
>Joshua
>
>--
>Sent from my Nokia N9

-- 
Charles N Wyble @charlesnw charles at knownelement.com 

Building a cost effective, open, secure bit moving platform for tomorrows default free zone.


From dr at cluenet.de  Tue Nov  8 14:05:34 2011
From: dr at cluenet.de (Daniel Roesen)
Date: Tue, 8 Nov 2011 21:05:34 +0100
Subject: Juniper MX960 Mqchip packet lenght error
In-Reply-To: <7F682CB8F5E45A4899F807AA4FEA854213DD9A3D@GRFMBX707RM001.griffon.local>
References: <7F682CB8F5E45A4899F807AA4FEA854213DD9A3D@GRFMBX707RM001.griffon.local>
Message-ID: <20111108200534.GA17751@srv03.cluenet.de>

On Tue, Nov 08, 2011 at 03:34:36PM +0100, Ferretti Antonio wrote:
> After upgrading Juniper MX960 from 4x10Gbe DPCE to 16x10Gbe MPC, I see strange log messages like this:
> 
> Fpc10 MQCHIP(0) LI Packet length error, pt entry 22
> 
> Seems to be only a "cosmetic" message,

PR/593386 "and others". Wenth thru that half a year ago. :)

> but today my team found some traffic dropped on interface on this card
> (before we only request check about log message).
> Has anyone the same problem?

Yes. We were told: cosmetic only, and we saw no impact.

Trigger was a "then log" in the lo0.0 firewall filter.

> My software release is Junos 10.3R3.7.

Would match. Above PR is fixed in 10.3R4, 10.4R4, 11.1R2 and newer

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0


From subscribedlists at derekbodner.com  Tue Nov  8 14:05:34 2011
From: subscribedlists at derekbodner.com (Derek Bodner)
Date: Tue, 08 Nov 2011 15:05:34 -0500
Subject: Logs Bank
In-Reply-To: <72D9A217-326A-4089-9289-A5D67285949E@retina.net>
References: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
 <72D9A217-326A-4089-9289-A5D67285949E@retina.net>
Message-ID: <4EB98B8E.4060402@derekbodner.com>


On 11/08/2011 03:00 PM, John Adams wrote:
> You probably want spunk, but if you want to do aggregation in an OSS fashion, scribe or flume is the way to go.
>
>

Agree with Splunk, while not open source, is the most functional of 
these products.  Be warned, while they offer a free license, once you 
start using it you'll be hooked, and their pricing beyond the free 
license is borderline extortionist.


From alter3d at alter3d.ca  Tue Nov  8 14:06:19 2011
From: alter3d at alter3d.ca (Peter Kristolaitis)
Date: Tue, 08 Nov 2011 15:06:19 -0500
Subject: Logs Bank
In-Reply-To: <d99630b3-f7bc-4042-902e-8c43cbf3b83c@email.android.com>
References: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
 <d99630b3-f7bc-4042-902e-8c43cbf3b83c@email.android.com>
Message-ID: <4EB98BBB.5000306@alter3d.ca>

Octopussy (8pussy.org) is another option as well.   Natively ties into 
various network monitoring packages (Nagios, Zabbix) for alerting 
capabilities.

- Peter


On 11/8/2011 3:00 PM, Charles N Wyble wrote:
> Yes. Check out rsyslog and logstash.
>
> joshua.klubi at gmail.com wrote:
>
>> Hi,
>>
>> If I may ask, is there any OSS that can serve as a log bank or log
>> server, where it aggregate logs from  different sources , and the logs
>> can be accessed using the web from any location on the network and can
>> do graphical presentations based on.the frequency or content os the
>> logs.
>>
>> Thank you
>>
>> Joshua
>>
>> --
>> Sent from my Nokia N9



From davidj at mckendrick.ca  Tue Nov  8 14:06:52 2011
From: davidj at mckendrick.ca (David)
Date: Tue, 08 Nov 2011 14:06:52 -0600
Subject: Logs Bank
In-Reply-To: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
References: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
Message-ID: <1320782812.2807.38.camel@beast.deigratia.ca>

http://www.8pussy.org/dokuwiki/doku.php -- free. open source.
http://logstash.net/ -- free. open source.
http://splunk.com (already mentioned, of course) -- pay to play. And
expensive, too. 

There are far more out there.



From davidj at mckendrick.ca  Tue Nov  8 14:09:02 2011
From: davidj at mckendrick.ca (David)
Date: Tue, 08 Nov 2011 14:09:02 -0600
Subject: Logs Bank
In-Reply-To: <1320782812.2807.38.camel@beast.deigratia.ca>
References: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
 <1320782812.2807.38.camel@beast.deigratia.ca>
Message-ID: <1320782942.2807.40.camel@beast.deigratia.ca>

Oh! And http://graylog2.org/ -- free, open source.
That's the last of the ones I can muster up.

On Tue, 2011-11-08 at 14:06 -0600, David wrote:
> http://www.8pussy.org/dokuwiki/doku.php -- free. open source.
> http://logstash.net/ -- free. open source.
> http://splunk.com (already mentioned, of course) -- pay to play. And
> expensive, too. 
> 
> There are far more out there.
> 
> 




From sylvie at newnog.org  Tue Nov  8 14:08:45 2011
From: sylvie at newnog.org (Sylvie LaPerriere)
Date: Tue, 8 Nov 2011 12:08:45 -0800
Subject: [NANOG-announce] Call for Communications Committee (CC) Volunteers
Message-ID: <CA+Py6b9SR0M6w+zR7Y3BZezuKhvbd9kfidTY8NJ-D-W8S+VFxw@mail.gmail.com>

NANOGers:



The NANOG Communications
Committee<http://www.nanog.org/governance/communications/>,
as defined by the NANOG Bylaws, is a committee that is responsible for the
NANOG mailing list, and other forms of electronic communication among the
NANOG community as agreed with the Board of Directors.



The Communications Committee is responsible for the administration and
minimal moderation of the NANOG list, nanog at nanog.org,  Also, the committee
is responsible for the administration of other mailing lists and other
forms of electronic communications among the NANOG community.



The NANOG Board is seeking volunteers who are, or willing to become,
members and are willing to serve on the Communications Committee.



Please submit your name and interest statement to Board at nanog.org


Thanks!


Sylvie LaPerriere

NANOG Chair   -  www.nanog.org
-------------- next part --------------
_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

From andy-nanog at bash.sh  Tue Nov  8 14:44:45 2011
From: andy-nanog at bash.sh (Andrew Mulholland)
Date: Tue, 8 Nov 2011 20:44:45 +0000
Subject: Logs Bank
In-Reply-To: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
References: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
Message-ID: <CAK80FnKmGiZ2Eey1bjwb3G+mE_HdCNnZfWjRSd=1vAGH8Xf_=g@mail.gmail.com>

To answer your question.

"yes"

However, with almost everything I can think of, there will be an element of
development required in order to achieve the results you're after. - at a
previous work place a few years ago we fed all event logs into hadoop, from
where we produced reports, initially just into excel files,  and then later
created a webapp which produced near realtime stats/reports/graphs.

I've not looked recently at LogStash, or 8pussy, but primary concern would
be how well they deal with huge log volumes, how they scale when one server
is not big enough to hold all the logs any more, how they deal with many
users searching at the same time etc.

If you want to actually just get on with crunching logs, and drawing graphs
in a timely fashion, Splunk is proven, and works well up to big scale (we
were feeding almost 1TB/day of logs into it at my last company)...


Splunk is not cheap, but when considering the cost of development +
suppport if you went down the route of task of rolling something equivalent
in capabilities, its not bad value.

thanks

Andrew


On Tue, Nov 8, 2011 at 7:59 PM, <joshua.klubi at gmail.com> wrote:

> Hi,
>
> If I may ask, is there any OSS that can serve as a log bank or log server,
> where it aggregate logs from  different sources , and the logs can be
> accessed using the web from any location on the network and can do
> graphical presentations based on.the frequency or content os the logs.
>
> Thank you
>
> Joshua
>
> --
> Sent from my Nokia N9
>

From nick at foobar.org  Tue Nov  8 14:51:00 2011
From: nick at foobar.org (Nick Hilliard)
Date: Tue, 08 Nov 2011 20:51:00 +0000
Subject: where was my white knight....
In-Reply-To: <m2zkg6tob1.wl%randy@psg.com>
References: <m2zkg6tob1.wl%randy@psg.com>
Message-ID: <4EB99634.7060803@foobar.org>

On 08/11/2011 19:19, Randy Bush wrote:
> what comes to my mind is that NotFound is the default and it is
> recommended to route on it.

I understand what the manual says (actually, i read it).  I'm just curious
as to how this is going to work in real life.  Let's say you have a router
cold boot with a bunch of ibgp peers, a transit or two and an rpki cache
which is located on a non-connected network - e.g. small transit pop / AS
boundary scenario.  The cache is not necessarily going to be reachable
until it sees an update for its connected network.  Until this happens,
there will be no connectivity from the router to the cache, and
consequently prefixes received in from the transit may be subject to an
incorrect and potentially inconsistent routing policy with respect to the
rest of the network.  Ok, they'll be revalidated once the cache comes on
line, but what do you do with them in the interim?  Route traffic to them,
knowing that they might or might not be correct?  Drop until the cache
comes online from the point of view of the router?  Forward potentially
incorrect UPDATEs to your other ibgp peers, and forward validated updates
when the cache comes on-line again?  If so, then what if your incorrect new
policy takes precedence over an existing path in your ibgp mesh?  And what
if your RP is low on memory from storing an unvalidated adj-rib-in?

You could argue to have a local cache in every pop but may not be feasible
either - a cache will require storage with a high write life-cycle (i.e.
forget about using lots of types of flash), and you cannot be guaranteed
that this is going to be available on a router.

Look, i understand that you're designing rpki <-> interactivity such that
things will at least work in some fashion when your routers lose sight of
their rpki caches.  The problem is that this approach weakens rpki's
strengths - e.g. the ability to help stop youtube-like incidents from
recurring by ignoring invalid prefix injection.

Nick


From leigh.porter at ukbroadband.com  Tue Nov  8 15:08:26 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Tue, 8 Nov 2011 21:08:26 +0000
Subject: where was my white knight....
In-Reply-To: <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net>
 <20111108181459.GA13752@vacation.karoshi.com.>,
 <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net>
Message-ID: <84EFCC3F-52DB-48DB-83B4-93CC16C3CB4C@ukbroadband.com>


On 8 Nov 2011, at 18:24, "Dobbins, Roland" <rdobbins at arbor.net> wrote:

> 
> On Nov 9, 2011, at 1:14 AM, <bmanning at vacation.karoshi.com> wrote:
> 
>> that was/is kindof orthoginal to the question... would the sidr plan for routing security have been a help in this event? 
> 
> SIDR is intended to provide route-origination validation - it isn't intended to be nor can it possibly be a remedy for vendor-specific implementation problems.
> 
> Validation storm-control is something which must be accounted for in SIDR/DANE architecture, implementation, and deployment.  But at the end of the day, vendors are still responsible for their own code.
> 
> 

Indeed, we can expect new and exciting ways to blow up networks with SIDR. 


--
Leigh


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From morrowc.lists at gmail.com  Tue Nov  8 15:22:48 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 8 Nov 2011 16:22:48 -0500
Subject: where was my white knight....
In-Reply-To: <4eb971e6.11fc960a.4e29.3c18SMTPIN_ADDED@mx.google.com>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net>
 <4eb971e6.11fc960a.4e29.3c18SMTPIN_ADDED@mx.google.com>
Message-ID: <CAL9jLaZnfP+ipxtBh96jW8f+0wwrErg2bcoBAJ9JaWYNyFrQ0g@mail.gmail.com>

On Tue, Nov 8, 2011 at 1:14 PM,  <bmanning at vacation.karoshi.com> wrote:
>
> ?that was/is kindof orthoginal to the question... would the sidr plan
> for routing security have been a help in this event? ?nice to know
> unsecured IPv6 took some of the load when the unsecured IPv4 path
> failed.
>

if all routing goes boom, would secure routing have saved you?
no... all routing went boom.

> ?the answer seems to be NO, it would not have helped and would have actually
> contributed to network instability with large numbers of validation requests
> sent to the sidr/ca nodes.

I think actually it wouldn't have caused more validation requests, the
routers have (in some form of the plan) a cache from their local
cache, they use this for origin validation... there's not a
requirement to refresh up the entire chain. (I think).

-chris

>
> /bill
>
> On Tue, Nov 08, 2011 at 10:01:04AM -0800, Mike Leber wrote:
>>
>> We saw an increase in IPv6 traffic which correlated time wise with the
>> onset of this IPv4 incident.
>>
>> Happy eyeballs in action, automatically shifting what it could.
>>
>> Mike.
>>
>> On 11/8/11 2:56 AM, bmanning at vacation.karoshi.com wrote:
>> >how would a sidr-enabled routing infrastructure have fared in yesterdays
>> >routing circus?
>> >
>> >/bill
>> >
>
>


From morrowc.lists at gmail.com  Tue Nov  8 15:25:54 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 8 Nov 2011 16:25:54 -0500
Subject: where was my white knight....
In-Reply-To: <4EB9796C.9080009@foobar.org>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net>
 <20111108181459.GA13752@vacation.karoshi.com.>
 <4EB9796C.9080009@foobar.org>
Message-ID: <CAL9jLaZeDHLrKJv4Xd7YnVdpsvjKb74290JmxuMXRKW=NxwJuQ@mail.gmail.com>

On Tue, Nov 8, 2011 at 1:48 PM, Nick Hilliard <nick at foobar.org> wrote:
> On 08/11/2011 18:14, bmanning at vacation.karoshi.com wrote:
>> ?the answer seems to be NO, it would not have helped and would have actually
>> contributed to network instability with large numbers of validation requests
>> sent to the sidr/ca nodes...
>
> i'm curious about sidr cold bootup, specifically when you are attempting to
> validate prefixes from an rpki CA or cache to which you do not necessarily
> have network connectivity because your igp is not yet fully up. ?The
> phrases "layering violation" and "chicken and egg" come to mind.

'lazy validation' - prefer to get at least somewhat converged, then validate.

>


From morrowc.lists at gmail.com  Tue Nov  8 15:30:38 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 8 Nov 2011 16:30:38 -0500
Subject: where was my white knight....
In-Reply-To: <84EFCC3F-52DB-48DB-83B4-93CC16C3CB4C@ukbroadband.com>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net>
 <20111108181459.GA13752@vacation.karoshi.com.>
 <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net>
 <84EFCC3F-52DB-48DB-83B4-93CC16C3CB4C@ukbroadband.com>
Message-ID: <CAL9jLaaPhNU_ga8nB++tkPNCkm__RaN2kovJPf2tTRU=4AoX8A@mail.gmail.com>

On Tue, Nov 8, 2011 at 4:08 PM, Leigh Porter
<leigh.porter at ukbroadband.com> wrote:
>
> On 8 Nov 2011, at 18:24, "Dobbins, Roland" <rdobbins at arbor.net> wrote:
>
>> Validation storm-control is something which must be accounted for in SIDR/DANE architecture, implementation, and deployment. ?But at the end of the day, vendors are still responsible for their own code.
>>
>>
>
> Indeed, we can expect new and exciting ways to blow up networks with SIDR.

or, the same old ways... only with crypto!
really, there was some care taken in the process to create this and
NOT stomp all over how networks currently work.

comments welcome though.


From Valdis.Kletnieks at vt.edu  Tue Nov  8 15:32:48 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 08 Nov 2011 16:32:48 -0500
Subject: where was my white knight....
In-Reply-To: Your message of "Tue, 08 Nov 2011 20:51:00 GMT."
 <4EB99634.7060803@foobar.org>
References: <m2zkg6tob1.wl%randy@psg.com> <4EB99634.7060803@foobar.org>
Message-ID: <77240.1320787968@turing-police.cc.vt.edu>

On Tue, 08 Nov 2011 20:51:00 GMT, Nick Hilliard said:

> I understand what the manual says (actually, i read it).  I'm just curious
> as to how this is going to work in real life.  Let's say you have a router
> cold boot with a bunch of ibgp peers, a transit or two and an rpki cache
> which is located on a non-connected network 

Anybody who puts their rpki cache someplace that isn't accessible until they
get the rpki initialized gets what they deserve. Once you realize this, the
rest of the "what do we do for routing until it comes up" concern trolling in
the rest of that paragraph becomes pretty easy to sort out...

> You could argue to have a local cache in every pop but may not be feasible
> either - a cache will require storage with a high write life-cycle (i.e.
> forget about using lots of types of flash), and you cannot be guaranteed
> that this is going to be available on a router.

Caching just enough to validate the routes you need to get to a more capable
rpki server shouldn't have a high write life-cycle.  Heck, you could just manually
configure a host route pointing to the rpki server...

And it would hardly be the first time that people have been unable to deploy
feature XYZ because it wouldn't fit in the flash on older boxes still in
production.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111108/0c33517c/attachment.bin>

From bicknell at ufp.org  Tue Nov  8 15:36:01 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 8 Nov 2011 13:36:01 -0800
Subject: where was my white knight....
In-Reply-To: <CAL9jLaZnfP+ipxtBh96jW8f+0wwrErg2bcoBAJ9JaWYNyFrQ0g@mail.gmail.com>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net>
 <4eb971e6.11fc960a.4e29.3c18SMTPIN_ADDED@mx.google.com>
 <CAL9jLaZnfP+ipxtBh96jW8f+0wwrErg2bcoBAJ9JaWYNyFrQ0g@mail.gmail.com>
Message-ID: <20111108213600.GA70357@ussenterprise.ufp.org>

In a message written on Tue, Nov 08, 2011 at 04:22:48PM -0500, Christopher Morrow wrote:
> I think actually it wouldn't have caused more validation requests, the
> routers have (in some form of the plan) a cache from their local
> cache, they use this for origin validation... there's not a
> requirement to refresh up the entire chain. (I think).

I kinda think everyone is wrong here, but Chris is closer to accurate.
:P

When a router goes boom, the rest of the routers recalculate around
it.  Generally speaking all of the routers will have already had a
route with the same origin, and thus have hopefully cached a lookup
of the origin.  However, that lookup might have been done
days/weeks/months ago, in a stable network.

While I'm not familar with the nitty gritty details here, caches
expire for various reasons.  The mere act of the route changing
paths, if it moved to a device with a stale cache, would trigger a
new lookup, right?

Basically I would expect any routing change to generate a set of
new lookups proportial to the cache expiration rules.

What am I missing?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111108/30b6170c/attachment.bin>

From jra at baylink.com  Tue Nov  8 15:52:49 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 8 Nov 2011 16:52:49 -0500 (EST)
Subject: OT: Ars: Cicso v Adekeye
Message-ID: <14406628.2099.1320789169512.JavaMail.root@benjamin.baylink.com>

http://arstechnica.com/tech-policy/news/2011/07/a-pound-of-flesh-how-ciscos-unmitigated-gall-derailed-one-mans-life.ars/1

-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From leigh.porter at ukbroadband.com  Tue Nov  8 16:15:03 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Tue, 8 Nov 2011 22:15:03 +0000
Subject: where was my white knight....
In-Reply-To: <20111108213600.GA70357@ussenterprise.ufp.org>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net>
 <4eb971e6.11fc960a.4e29.3c18SMTPIN_ADDED@mx.google.com>
 <CAL9jLaZnfP+ipxtBh96jW8f+0wwrErg2bcoBAJ9JaWYNyFrQ0g@mail.gmail.com>,
 <20111108213600.GA70357@ussenterprise.ufp.org>
Message-ID: <EC25E871-6472-4F1B-85D2-588F8EB12C11@ukbroadband.com>


On 8 Nov 2011, at 21:37, "Leo Bicknell" <bicknell at ufp.org> wrote:

> In a message written on Tue, Nov 08, 2011 at 04:22:48PM -0500, Christopher Morrow wrote:
>> I think actually it wouldn't have caused more validation requests, the
>> routers have (in some form of the plan) a cache from their local
>> cache, they use this for origin validation... there's not a
>> requirement to refresh up the entire chain. (I think).
> 
> I kinda think everyone is wrong here, but Chris is closer to accurate.
> :P
> 
> When a router goes boom, the rest of the routers recalculate around
> it.  Generally speaking all of the routers will have already had a
> route with the same origin, and thus have hopefully cached a lookup
> of the origin.  However, that lookup might have been done
> days/weeks/months ago, in a stable network.
> 
> While I'm not familar with the nitty gritty details here, caches
> expire for various reasons.  The mere act of the route changing
> paths, if it moved to a device with a stale cache, would trigger a
> new lookup, right?
> 
> Basically I would expect any routing change to generate a set of
> new lookups proportial to the cache expiration rules.

Which may very well fail because all the routing is hosed. I'm not all that familiar with the potential implementation issues, but I would think that network-local caches would be in order. 

Even with local caches, I would expect a high incidence of change to trigger something sensible to mitigate this kind of craziness from happening. I am sure enough people have had incorrectly scaled RADIUS farms blow up when a load of DSLAMS vanish and come back again not to repeat such storms.


--
Leigh Porter


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From nick at foobar.org  Tue Nov  8 16:19:24 2011
From: nick at foobar.org (Nick Hilliard)
Date: Tue, 08 Nov 2011 22:19:24 +0000
Subject: where was my white knight....
In-Reply-To: <77240.1320787968@turing-police.cc.vt.edu>
References: <m2zkg6tob1.wl%randy@psg.com> <4EB99634.7060803@foobar.org>
 <77240.1320787968@turing-police.cc.vt.edu>
Message-ID: <4EB9AAEC.9000308@foobar.org>

On 08/11/2011 21:32, Valdis.Kletnieks at vt.edu wrote:
> Anybody who puts their rpki cache someplace that isn't accessible until they
> get the rpki initialized gets what they deserve.

One solution is to have directly-connected rpki caches available to all 
your bgp edge routers throughout your entire network.  This may turn out to 
be expensive capex-wise, and will turn out to be yet another critical 
infrastructure item to maintain, increasing opex.

Alternatively, you host rpki caches on all your AS-edge routers => upgrades 
- and lots of currently-sold kit will simply not handle this sort of thing 
properly.

> Once you realize this, the rest of the "what do we do for routing until
> it comes up" concern trolling in the rest of that paragraph becomes
> pretty easy to sort out...

I humbly apologise for expressing concern about the wisdom of imposing a 
hierarchical, higher-layer validation structure for forwarding-info 
management on a pre-existing lower layer fully distributed system which is 
already pretty damned complex...

What's that principle called again?  Was it "Keep It Complex, Stupid"?  I 
can't seem to remember :-)

> Caching just enough to validate the routes you need to get to a more capable
> rpki server shouldn't have a high write life-cycle.

Lots of older flash isn't going to like this => higher implementation cost 
due to upgrades.

> Heck, you could just manually
> configure a host route pointing to the rpki server...

Yep, hard coding things - good idea, that.

> And it would hardly be the first time that people have been unable to deploy
> feature XYZ because it wouldn't fit in the flash on older boxes still in
> production.

This is one of several points I'm making: there is a cost factor here, and 
it's not clear how large it is.

Nick


From rdobbins at arbor.net  Tue Nov  8 16:26:30 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 8 Nov 2011 22:26:30 +0000
Subject: where was my white knight....
In-Reply-To: <CAL9jLaZnfP+ipxtBh96jW8f+0wwrErg2bcoBAJ9JaWYNyFrQ0g@mail.gmail.com>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net>
 <4eb971e6.11fc960a.4e29.3c18SMTPIN_ADDED@mx.google.com>
 <CAL9jLaZnfP+ipxtBh96jW8f+0wwrErg2bcoBAJ9JaWYNyFrQ0g@mail.gmail.com>
Message-ID: <AC68E194-AD8A-47B8-BAD7-4EB14321617B@arbor.net>


On Nov 9, 2011, at 4:22 AM, Christopher Morrow wrote:

>  the routers have (in some form of the plan) a cache

A cache that's persistent across reboots?

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From rdobbins at arbor.net  Tue Nov  8 16:29:06 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 8 Nov 2011 22:29:06 +0000
Subject: where was my white knight....
In-Reply-To: <4EB9AAEC.9000308@foobar.org>
References: <m2zkg6tob1.wl%randy@psg.com> <4EB99634.7060803@foobar.org>
 <77240.1320787968@turing-police.cc.vt.edu> <4EB9AAEC.9000308@foobar.org>
Message-ID: <FDF72F5C-BEA5-479D-9467-AA9FEEC9FCA3@arbor.net>


On Nov 9, 2011, at 5:19 AM, Nick Hilliard wrote:

> One solution is to have directly-connected rpki caches available to all your bgp edge routers throughout your entire network. 

They don't have to be directly-connected - they could be on the DCN, which ought to have at least some static 'hints' to critical resources.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From bicknell at ufp.org  Tue Nov  8 16:32:09 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 8 Nov 2011 14:32:09 -0800
Subject: where was my white knight....
In-Reply-To: <4EB9AAEC.9000308@foobar.org>
References: <m2zkg6tob1.wl%randy@psg.com> <4EB99634.7060803@foobar.org>
 <77240.1320787968@turing-police.cc.vt.edu> <4EB9AAEC.9000308@foobar.org>
Message-ID: <20111108223209.GA72991@ussenterprise.ufp.org>

In a message written on Tue, Nov 08, 2011 at 10:19:24PM +0000, Nick Hilliard wrote:
> One solution is to have directly-connected rpki caches available to all 
> your bgp edge routers throughout your entire network.  This may turn out to 
> be expensive capex-wise, and will turn out to be yet another critical 
> infrastructure item to maintain, increasing opex.

Couldn't you just have a couple of these boxes on your network and
route them in your IGP, removing any BGP dependancy?  KISS.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111108/94ee8381/attachment-0001.bin>

From bmanning at vacation.karoshi.com  Tue Nov  8 16:32:25 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 8 Nov 2011 22:32:25 +0000
Subject: where was my white knight....
In-Reply-To: <m21utiv30l.wl%randy@psg.com>
References: <20111108181459.GA13752@vacation.karoshi.com.>
 <m21utiv30l.wl%randy@psg.com>
Message-ID: <20111108223225.GA14045@vacation.karoshi.com.>

On Tue, Nov 08, 2011 at 08:16:10PM +0100, Randy Bush wrote:
> > the answer seems to be NO, it would not have helped and would have
> > actually contributed to network instability with large numbers of
> > validation requests sent to the sidr/ca nodes...
> 
> utter bullshit.  maybe you would benefit by actually reading the doccos
> and understanding the protocols.

	are they actually coherent enough to be read & understood?
	
/bill


From waehlisch at ieee.org  Tue Nov  8 16:38:12 2011
From: waehlisch at ieee.org (Matthias Waehlisch)
Date: Tue, 8 Nov 2011 23:38:12 +0100
Subject: where was my white knight....
In-Reply-To: <20111108223225.GA14045@vacation.karoshi.com.>
References: <20111108181459.GA13752@vacation.karoshi.com.>
 <m21utiv30l.wl%randy@psg.com>
 <20111108223225.GA14045@vacation.karoshi.com.>
Message-ID: <Pine.WNT.4.64.1111082334510.21568@mw-PC>


On Tue, 8 Nov 2011, bmanning at vacation.karoshi.com wrote:

> On Tue, Nov 08, 2011 at 08:16:10PM +0100, Randy Bush wrote:
> > > the answer seems to be NO, it would not have helped and would have
> > > actually contributed to network instability with large numbers of
> > > validation requests sent to the sidr/ca nodes...
> > 
> > utter bullshit.  maybe you would benefit by actually reading the doccos
> > and understanding the protocols.
> 
> 	are they actually coherent enough to be read & understood?
> 	
  I think so: at least a Bachelor student of my got along with them for 
his thesis.

  Btw: There is also a very nice overview by Geoff published in Cisco 
IPJ:

  * 
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_14-2/142_bgp.html



Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehlisch at ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net


From morrowc.lists at gmail.com  Tue Nov  8 16:46:59 2011
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 8 Nov 2011 17:46:59 -0500
Subject: where was my white knight....
In-Reply-To: <AC68E194-AD8A-47B8-BAD7-4EB14321617B@arbor.net>
References: <20111108105631.GB5979@vacation.karoshi.com.>
 <4EB96E60.9090707@he.net>
 <4eb971e6.11fc960a.4e29.3c18SMTPIN_ADDED@mx.google.com>
 <CAL9jLaZnfP+ipxtBh96jW8f+0wwrErg2bcoBAJ9JaWYNyFrQ0g@mail.gmail.com>
 <AC68E194-AD8A-47B8-BAD7-4EB14321617B@arbor.net>
Message-ID: <CAL9jLaY8wGXVprjfh2UbRsMCrqrRH_ua_6B4AMdB9y4GyBDbcA@mail.gmail.com>

On Tue, Nov 8, 2011 at 5:26 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:
>
> On Nov 9, 2011, at 4:22 AM, Christopher Morrow wrote:
>
>> ?the routers have (in some form of the plan) a cache
>
> A cache that's persistent across reboots?
>

not across reboots, but in this case routers didn't necessarily reboot
(parts of them did though).
in the case of a reboot, sure, pull from your local cache, no 'walk up
the chian' is required here.


From BEJones at semprautilities.com  Tue Nov  8 17:06:39 2011
From: BEJones at semprautilities.com (Jones, Barry)
Date: Tue, 8 Nov 2011 15:06:39 -0800
Subject: Firewalls - Ease of Use and Maintenance?
Message-ID: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>

Hello all.
I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate.

Feel free to ping me offline - and thank you for the assistance.

----------------------------------------
Barry Jones - CISSP GSNA
Project Manager II
Sempra Energy Utilities
(760) 271-6822

P please don't print this e-mail unless you really need to.
----------------------------------------


From bhmccie at gmail.com  Tue Nov  8 17:32:20 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Tue, 08 Nov 2011 17:32:20 -0600
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <4EB9BC04.5010103@gmail.com>

You've worked with all the big dogs. What are you looking for? 
Alternative options?

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/08/2011 05:06 PM, Jones, Barry wrote:
> Hello all.
> I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate.
>
> Feel free to ping me offline - and thank you for the assistance.
>
> ----------------------------------------
> Barry Jones - CISSP GSNA
> Project Manager II
> Sempra Energy Utilities
> (760) 271-6822
>
> P please don't print this e-mail unless you really need to.
> ----------------------------------------
>
>    

From bmanning at vacation.karoshi.com  Tue Nov  8 17:37:03 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 8 Nov 2011 23:37:03 +0000
Subject: comments due 2dec2011
Message-ID: <20111108233703.GC14045@vacation.karoshi.com.>


http://www.nist.gov/itl/cloud/index.cfm

/bill


From blake at pfankuch.me  Tue Nov  8 19:53:20 2011
From: blake at pfankuch.me (Blake T. Pfankuch)
Date: Wed, 9 Nov 2011 01:53:20 +0000
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C846D95604A@SHSBS.shenrons-house.local>

As Hammer stated, you hit all the big ones.

ASA's are a classic fallback because of the stability implied by the cisco name.  Complaints about them tend to be cost on getting all the shiny bits attached to them (IDS, IPS, Content filtering).  This coming from a Cisco partner.  I am not a Netscreen fan myself due to past experiences and sour tastes.  Checkpoint's are OK, but I don't like the application need for configuring on SMB appliances.  

Add to the list Sonicwall.  We use them primarily for our customers at work and are partners with them as well.  They have appliances that go from 10 office size to Active/Active HA pairing that can do multi gbit of throughput.  They support all the standard features you look for IPSEC VPN, SSLVPN, L2TP, VLAN Interfaces, Dynamic routing support (OSPF and RIP in small models, BGP in the larger) LDAP auth for all of the above, content filtering, IPS, IDS, Anti Spyware stateful blah blah and centralized management.  Some of the newer things that are gaining popularity that you can license is the App Visualization (think netflow in a web UI with good filters), WAN Acceleration modules via a VMware Appliance, RBL Filtering (which can be applied to just about anything), DPI-SSL inspection for https traffic, Active/Active HA, Physical port redundancy per appliance, list goes on.  Configuration logic is similar to a ASA, however takes a little to get used to.  The nice thing is everything in the config is name based and searchable within the WebUI and you can talk non technical people through making changes in the config if you have to.  

The feature list is growing every day, and I almost prefer them anymore just because of the simplicity as well as the scalability.

Ping me if you have more questions or want a few example setups.

Blake

-----Original Message-----
From: Jones, Barry [mailto:BEJones at semprautilities.com] 
Sent: Tuesday, November 08, 2011 4:07 PM
To: nanog at nanog.org
Subject: Firewalls - Ease of Use and Maintenance?

Hello all.
I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate.

Feel free to ping me offline - and thank you for the assistance.

----------------------------------------
Barry Jones - CISSP GSNA
Project Manager II
Sempra Energy Utilities
(760) 271-6822

P please don't print this e-mail unless you really need to.
----------------------------------------



From Ben.Kessler at zenetra.com  Tue Nov  8 20:09:09 2011
From: Ben.Kessler at zenetra.com (R. Benjamin Kessler)
Date: Wed, 9 Nov 2011 02:09:09 +0000
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <0CFF54003CD92945994CF0C0F90D81B6AF86DE@EXCH1-FWA1.zenetra.local>

We work with many vendor's firewalls and our current "favorites" are Palo Alto Networks - they're very full-featured and easy to manage.

www.paloaltonetworks.com

I don't want to get all "sales-weasel" on you but we can help if you want more info as we are one of their premier partners.

P.S. - we're also Juniper and Cisco partners too but we prefer the Palo Altos for firewalls these days.

Let me know how I can help

-Ben


R. Benjamin Kessler
CCIE #8762, CISSP, CCSE
President / Chief Network Geek
Zenetra Corporation
Email: ben.kessler at zenetra.com
http://www.zenetra.com
Office: 260-271-4330 << Note: New Number
Cell: 260-437-5774
Fax: 866-388-6652



-----Original Message-----
From: Jones, Barry [mailto:BEJones at semprautilities.com] 
Sent: Tuesday, November 08, 2011 6:07 PM
To: nanog at nanog.org
Subject: Firewalls - Ease of Use and Maintenance?

Hello all.
I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate.

Feel free to ping me offline - and thank you for the assistance.

----------------------------------------
Barry Jones - CISSP GSNA
Project Manager II
Sempra Energy Utilities
(760) 271-6822

P please don't print this e-mail unless you really need to.
----------------------------------------



From randy at psg.com  Tue Nov  8 21:14:35 2011
From: randy at psg.com (Randy Bush)
Date: Wed, 09 Nov 2011 04:14:35 +0100
Subject: where was my white knight....
In-Reply-To: <4EB99634.7060803@foobar.org>
References: <m2zkg6tob1.wl%randy@psg.com>
	<4EB99634.7060803@foobar.org>
Message-ID: <m2mxc6t2as.wl%randy@psg.com>

> I understand what the manual says (actually, i read it).

cheating!!!!

> I'm just curious as to how this is going to work in real life.  Let's
> say you have a router cold boot with a bunch of ibgp peers, a transit
> or two and an rpki cache which is located on a non-connected network -
> e.g. small transit pop / AS boundary scenario.  The cache is not
> necessarily going to be reachable until it sees an update for its
> connected network.

once again, 
  o when you have no connection to a cache or no covering roa for a
    a prefix, the result is specified as NotFound
  o we recommend you route on NotFound

so the result is the same as today.

> Until this happens, there will be no connectivity from the router to
> the cache

false

> Look, i understand that you're designing rpki <-> interactivity such that
> things will at least work in some fashion when your routers lose sight of
> their rpki caches.  The problem is that this approach weakens rpki's
> strengths - e.g. the ability to help stop youtube-like incidents from
> recurring by ignoring invalid prefix injection.

you can't have you cake and eat it to.  you can not detect invalid
originations until you have the data to do so.

randy


From randy at psg.com  Tue Nov  8 21:28:54 2011
From: randy at psg.com (Randy Bush)
Date: Wed, 09 Nov 2011 04:28:54 +0100
Subject: where was my white knight....
In-Reply-To: <20111108223225.GA14045@vacation.karoshi.com.>
Message-ID: <m2hb2et1mx.wl%randy@psg.com>

fwiw, we have not tested the scaling of rpki-rtr performance as much as
we might have.  we synthesized an rpki cache with roas for all the
prefixes in a current table, 370k of them or whatever, and let routers
load that cache from zip to full.  for low-end routers and a mediocre
cache server, either local or across noam, it took less than five
seconds.  this was small enough that we moved on to other stuff.

randy


From randy at psg.com  Tue Nov  8 21:33:41 2011
From: randy at psg.com (Randy Bush)
Date: Wed, 09 Nov 2011 04:33:41 +0100
Subject: where was my white knight....
In-Reply-To: <84EFCC3F-52DB-48DB-83B4-93CC16C3CB4C@ukbroadband.com>
Message-ID: <m2fwhyt1ey.wl%randy@psg.com>

> Indeed, we can expect new and exciting ways to blow up networks with
> SIDR.

the black helicopters spraying fud are especially vicious


From owen at delong.com  Tue Nov  8 21:54:00 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 8 Nov 2011 19:54:00 -0800
Subject: where was my white knight....
In-Reply-To: <m2hb2et1mx.wl%randy@psg.com>
References: <m2hb2et1mx.wl%randy@psg.com>
Message-ID: <B1E9C76A-7F84-4521-9129-617953BD362D@delong.com>


On Nov 8, 2011, at 7:28 PM, Randy Bush wrote:

> fwiw, we have not tested the scaling of rpki-rtr performance as much as
> we might have.  we synthesized an rpki cache with roas for all the
> prefixes in a current table, 370k of them or whatever, and let routers
> load that cache from zip to full.  for low-end routers and a mediocre
> cache server, either local or across noam, it took less than five
> seconds.  this was small enough that we moved on to other stuff.
> 
> randy

Did you do this on routers that already had fully converged tables, or,
did you bootstrap the table load into the routers at the same time
as would be the case in a power failure, post-crash reboot, software
upgrade, etc.?

If only the former, may I suggest that at least doing some level of the
latter might prove a useful exercise?

I apologize for this mildly operational question. Y'all can go back to
Randy's fud-laiden black helicopters now.

Owen



From jof at thejof.com  Tue Nov  8 22:47:48 2011
From: jof at thejof.com (Jonathan Lassoff)
Date: Tue, 8 Nov 2011 20:47:48 -0800
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <CAHsqw9sSk+6dPygnGCbc0jRHbdxJGd9+R+A3vKkSeTHX8MoeDQ@mail.gmail.com>

It really depends on what constraints you have. Do you care about:
cost? performance? support?

Personally, for cost-constrained applications of 1 Gbit/s or less
(assuming modestly-sized packets, not all-DNS for example), I like
OpenBSD/pf or Linux/netfilter and generic x86 64-bit servers.
It's cheap, deeply customizable and since everything touches a CPU, it
allows for deep traffic inspection.

The tradeoff is that there's no support from major vendors, but there
are many smaller but very experienced consulting shops that can
integrate any patches and fix and issues that may arise.


What kinds of things are you looking for?

Cheers,
jof

On Tue, Nov 8, 2011 at 3:06 PM, Jones, Barry
<BEJones at semprautilities.com> wrote:
> Hello all.
> I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate.
>
> Feel free to ping me offline - and thank you for the assistance.
>
> ----------------------------------------
> Barry Jones - CISSP GSNA
> Project Manager II
> Sempra Energy Utilities
> (760) 271-6822
>
> P please don't print this e-mail unless you really need to.
> ----------------------------------------
>
>


From seth.mos at dds.nl  Wed Nov  9 02:13:30 2011
From: seth.mos at dds.nl (Seth Mos)
Date: Wed, 09 Nov 2011 09:13:30 +0100
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <4EBA362A.6050401@dds.nl>

On 9-11-2011 0:06, Jones, Barry wrote:
> Hello all.
> I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate.

I am biased because I am a pfSense developer.

pfSense is a free open source FreeBSD based firewall with the pf packet
filter. http://www.pfsense.org

It supports various features and installable packages that might fill
your needs. Commercial support is also available.

One of the reasons I use it at work is because it is by far the cheapest
solution to gigabit redundant (Active/Passive) firewalls. It runs on x86
machines from the low end PCengines.ch Alix 2D3 to something like a dual
core Intel Atom for or the higher end on a "normal" server.

It is administered entirely via the webUI, saves the config in a XML
file you can backup and then restore on pretty much any other hardware
you have around should it need to be replaced.

The (readable) XML file was also really easy to provision things like
hundreds of VPN tunnels instead of clicking through the UI.

The PHP command interface allows you to perform scripting operations on
the XML as well which comes in handy on mass mutations.

Kind regards,

Seth


From tom at ninjabadger.net  Wed Nov  9 04:07:17 2011
From: tom at ninjabadger.net (Tom Hill)
Date: Wed, 09 Nov 2011 10:07:17 +0000
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBA362A.6050401@dds.nl>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <4EBA362A.6050401@dds.nl>
Message-ID: <1320833243.1990.1.camel@teh-desktop>

On Wed, 2011-11-09 at 09:13 +0100, Seth Mos wrote:
> I am biased because I am a pfSense developer.
> 
> pfSense is a free open source FreeBSD based firewall with the pf
> packet filter. http://www.pfsense.org

I'm a very happy user of m0n0wall and I know pfSense is often seen as
the more 'grown up' variant.

Still though, I hear bad things of the IPv6 support in pfSense. It's
"available" but not stock-standard & supported.

How does the pfSense developer attitude towards filtering the entire
Internet, IPv6 included, currently stand?

Tom



From seth.mos at dds.nl  Wed Nov  9 05:01:01 2011
From: seth.mos at dds.nl (Seth Mos)
Date: Wed, 09 Nov 2011 12:01:01 +0100
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <1320833243.1990.1.camel@teh-desktop>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <4EBA362A.6050401@dds.nl> <1320833243.1990.1.camel@teh-desktop>
Message-ID: <4EBA5D6D.6050408@dds.nl>

On 9-11-2011 11:07, Tom Hill wrote:
> On Wed, 2011-11-09 at 09:13 +0100, Seth Mos wrote:
>> I am biased because I am a pfSense developer.
>>
>> pfSense is a free open source FreeBSD based firewall with the pf
>> packet filter. http://www.pfsense.org
> 
> I'm a very happy user of m0n0wall and I know pfSense is often seen as
> the more 'grown up' variant.
> 
> Still though, I hear bad things of the IPv6 support in pfSense. It's
> "available" but not stock-standard & supported.

That is correct, it is in the 2.1 branch. Our code has diverged a lot
from m0n0wall where it came from so porting it was not easy. Instead I
wrote the code from scratch.

I wrote the IPv6 code in pfSense 2.1 for the last year and I've been
using it in production for quite a while now. Since February this year
to be precise.

It is true that until 2.1 is released somewhere next year the latest
official release is pfSense 2.0.

The people running Commercial support do support 2.1 with IPv6 if you
need it though. There are already a number of customers running it in
production because they needed IPv6 support.

The biggest holdup is lack of commercial VPN client support for
dual-stack. Viscosity, TunnelBlick I am looking at you. We do ship a
working Windows OpenVPN dual stack client solution in the Client
exporter on 2.1.

Working dual stack for your VPN solution is kind of important if you
expect to be able to reach your corporate servers. Much grief/fun to be
had here. If the corporate LAN advertises quad A records then it will
confuse your VPN clients if they have a v4 VPN address but only a v6
internet address.

> How does the pfSense developer attitude towards filtering the entire
> Internet, IPv6 included, currently stand?

I do not quite understand your question. If you are referring to a
default deny policy on incoming traffic, then yes.

The default rule is to deny incoming traffic over IPv6 as it did over
IPv4. You will need to create rules to allow it through. Default LAN
rule is allow both IPv4 and IPv6 out. Ofcourse you can alter the
firewall rules as you see fit.

If I misunderstood your question then please verify.

Kind regards,

Seth


From nick at foobar.org  Wed Nov  9 05:43:10 2011
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Nov 2011 11:43:10 +0000
Subject: where was my white knight....
In-Reply-To: <m2mxc6t2as.wl%randy@psg.com>
References: <m2zkg6tob1.wl%randy@psg.com> <4EB99634.7060803@foobar.org>
 <m2mxc6t2as.wl%randy@psg.com>
Message-ID: <4EBA674E.6030409@foobar.org>

On 09/11/2011 03:14, Randy Bush wrote:
> once again, 
>   o when you have no connection to a cache or no covering roa for a
>     a prefix, the result is specified as NotFound
>   o we recommend you route on NotFound
> 
> so the result is the same as today.

Well no, not really because when the cache becomes reachable again, you
need to revalidate everything which got a NotFound.  This will cause extra
bgp churn where revalidation caused a local policy change.

Even if you have a local cache, this will still cause problems due to the
problem you summarised in draft-ietf-sidr-origin-ops, section 6:

"Like the DNS, the global RPKI presents only a loosely consistent view,
depending on timing, updating, fetching, etc.  Thus, one cache or router
may have different data about a particular prefix than another cache or
router.  There is no 'fix' for this, it is the nature of distributed data
with distributed caches."

Local caches may miss updates due to interior unreachability.  Routers will
not revalidate after cache updates.  So this loosely consistent view will
propagate into your routers' bgp views.  Do I really want this?  Or, more
to the point, is a perpetually inconsistent bgp network view better or
worse than the occasional more serious reachability problem that rpki is
attempting to solve?  This isn't clear to me.

>> Until this happens, there will be no connectivity from the router to
>> the cache
> 
> false

Not false in the scenario I described.  Please read what I said, not what
your straw man whispers in your ear. :-)

Nick



From tom at ninjabadger.net  Wed Nov  9 05:45:29 2011
From: tom at ninjabadger.net (Tom Hill)
Date: Wed, 09 Nov 2011 11:45:29 +0000
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBA5D6D.6050408@dds.nl>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <4EBA362A.6050401@dds.nl> <1320833243.1990.1.camel@teh-desktop>
 <4EBA5D6D.6050408@dds.nl>
Message-ID: <1320839134.1990.8.camel@teh-desktop>

On Wed, 2011-11-09 at 12:01 +0100, Seth Mos wrote:
> That is correct, it is in the 2.1 branch. Our code has diverged a lot
> from m0n0wall where it came from so porting it was not easy. Instead I
> wrote the code from scratch.
> 
> I wrote the IPv6 code in pfSense 2.1 for the last year and I've been
> using it in production for quite a while now. Since February this year
> to be precise.
> 
> It is true that until 2.1 is released somewhere next year the latest
> official release is pfSense 2.0.
> 
> The people running Commercial support do support 2.1 with IPv6 if you
> need it though. There are already a number of customers running it in
> production because they needed IPv6 support.

TH: This is good news. I look forward to the general availability of 2.1
in this case. An "official" release supporting v6 properly is long
over-due for pfSense; users have been complaining about the lack of
support for *years*.

> The biggest holdup is lack of commercial VPN client support for
> dual-stack. Viscosity, TunnelBlick I am looking at you. We do ship a
> working Windows OpenVPN dual stack client solution in the Client
> exporter on 2.1.
> 
> Working dual stack for your VPN solution is kind of important if you
> expect to be able to reach your corporate servers. Much grief/fun to be
> had here. If the corporate LAN advertises quad A records then it will
> confuse your VPN clients if they have a v4 VPN address but only a v6
> internet address.

TH: Indeed, but the more you push on it the better it will become
(hopefully). VPN clients/concentrators in the FOSS world is already a
minefield of incompatibilities and other such problems.

> > How does the pfSense developer attitude towards filtering the entire
> > Internet, IPv6 included, currently stand?
> 
> I do not quite understand your question. If you are referring to a
> default deny policy on incoming traffic, then yes.
> 
> The default rule is to deny incoming traffic over IPv6 as it did over
> IPv4. You will need to create rules to allow it through. Default LAN
> rule is allow both IPv4 and IPv6 out. Ofcourse you can alter the
> firewall rules as you see fit.
> 
> If I misunderstood your question then please verify.

TH: In the past, the pfSense developer's attitude to IPv6 support has
been pretty poor. I have mentioned above that customers have been asking
for such support for years (i.e. since m0n0wall had it) and the response
has been 'it's not important yet', which really wasn't true.

But, despite that, it sounds like it's finally getting better. And that
can only be good news.

Tom



From rsk at gsp.org  Wed Nov  9 06:22:27 2011
From: rsk at gsp.org (Richard Kulawiec)
Date: Wed, 9 Nov 2011 07:22:27 -0500
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <20111109122227.GA5320@gsp.org>


You will find it very difficult to beat pf on OpenBSD for efficiency,
features, flexibility, robustness, and security.  Maintenance is very
easy: edit a configuration file, reload, done.

---rsk


From nderitualex at gmail.com  Wed Nov  9 06:32:45 2011
From: nderitualex at gmail.com (Alex Nderitu)
Date: Wed, 09 Nov 2011 15:32:45 +0300
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <20111109122227.GA5320@gsp.org>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org>
Message-ID: <4EBA72ED.2010909@gmail.com>

On 11/09/2011 03:22 PM, Richard Kulawiec wrote:
> You will find it very difficult to beat pf on OpenBSD for efficiency,
> features, flexibility, robustness, and security.  Maintenance is very
> easy: edit a configuration file, reload, done.
>
> ---rsk
>
>
An important feature lacking for now as far as I know is content/web 
filtering especially for corporates wishing to block inappropriate/time 
wasting content like facebook. Addition of this would place it a par 
with the best like Sonicwall and Fortinet.

Alex


From jgreco at ns.sol.net  Wed Nov  9 06:38:01 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Wed, 9 Nov 2011 06:38:01 -0600 (CST)
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBA72ED.2010909@gmail.com>
Message-ID: <201111091238.pA9Cc1rN080840@aurora.sol.net>

> On 11/09/2011 03:22 PM, Richard Kulawiec wrote:
> > You will find it very difficult to beat pf on OpenBSD for efficiency,
> > features, flexibility, robustness, and security.  Maintenance is very
> > easy: edit a configuration file, reload, done.
>
> An important feature lacking for now as far as I know is content/web 
> filtering especially for corporates wishing to block inappropriate/time 
> wasting content like facebook. Addition of this would place it a par 
> with the best like Sonicwall and Fortinet.

I would probably disagree with Richard's statement; most organizations
are looking for something that's a little more of a product/appliance
and a little less of a one-off solution/generic UNIX box.

That having been said, if you AREN'T put off by "edit a configuration
file", then maybe you won't be put off by "install Squid, add squidGuard
(IIRC), and configure transparent proxying" and you're pretty much all
the way there.  Oh, and you get caching acceleration for free.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From rsk at gsp.org  Wed Nov  9 07:11:45 2011
From: rsk at gsp.org (Richard Kulawiec)
Date: Wed, 9 Nov 2011 08:11:45 -0500
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBA72ED.2010909@gmail.com>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA72ED.2010909@gmail.com>
Message-ID: <20111109131145.GA7981@gsp.org>

On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:
> An important feature lacking for now as far as I know is content/web
> filtering especially for corporates wishing to block
> inappropriate/time wasting content like facebook. 

1. That's not a firewall function.  That's a censorship function.

2. You can of course easily do that via a variety of means, including
BOGUS'ing the domains in DNS, blocking port 80 traffic to their network
allocations, running an HTTP proxy that blocks them, etc.  I presume
that any minimally-competent censor could easily devise a first-order
solution (using the software packages supplied with OpenBSD) in an afternoon.

---rsk


From nick at foobar.org  Wed Nov  9 07:24:20 2011
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Nov 2011 13:24:20 +0000
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <20111109122227.GA5320@gsp.org>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org>
Message-ID: <4EBA7F04.6000105@foobar.org>

On 09/11/2011 12:22, Richard Kulawiec wrote:
> You will find it very difficult to beat pf on OpenBSD for efficiency,
> features, flexibility, robustness, and security.  Maintenance is very
> easy: edit a configuration file, reload, done.

There are several areas where pf falls down.  One is auto-synchronisation
from primary to backup firewall (not really a pf problem, but it's
important for production firewall systems).  Another is ipv6 fragments,
although this was mostly fixed in a commit on 20110329 (released in 5.0),
which unfortunately has not yet made its way to freebsd yet.  A third is
openbsd's poor ethernet hardware interrupt handling.  Again, this has
improved recently, but it's still lags seriously behind linux / freebsd.

Having said that, it's still my least disfavoured stateful packet filtering
system.

Nick


From jgreco at ns.sol.net  Wed Nov  9 08:00:01 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Wed, 9 Nov 2011 08:00:01 -0600 (CST)
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <20111109131145.GA7981@gsp.org>
Message-ID: <201111091400.pA9E01lg081698@aurora.sol.net>

> On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:
> > An important feature lacking for now as far as I know is content/web
> > filtering especially for corporates wishing to block
> > inappropriate/time wasting content like facebook. 
> 
> 1. That's not a firewall function.  That's a censorship function.

A "firewall" is pretty much a censorship function, you're using it to
disallow certain types of traffic on your network.  It's simply a matter
of what layer you find most convenient to block things...  a firewall
is better closer to the bottom of the OSI layer model, a proxy is better
closer to the top of the OSI layer model.

Is it "censorship" not to want unwanted connection attempts to our
gear, and block unsolicited TCP connections inbound?

Is it "censorship" not to want unwanted exploit attempts to our
gear, and run everything through ClamAV, and use blocklists to
prevent users inadvertently pulling content from known malware sites?

There's no functional differentiation between blocking content for
one reason and blocking it for another.  There's certainly a huge
difference in the POLICY decisions that drive those blocking decisions,
but the technology to do them is essentially identical.  You can,
after all, block facebook on your firewall at the IP level and I think
we would both agree that that is "censorship" but also something a
firewall is completely capable of.  It's just neater and more practical
to do at a higher level, for when facebook changes IP addresses (etc),
so a higher level block is really more appropriate.

> 2. You can of course easily do that via a variety of means, including
> BOGUS'ing the domains in DNS, blocking port 80 traffic to their network
> allocations, running an HTTP proxy that blocks them, etc.  I presume
> that any minimally-competent censor could easily devise a first-order
> solution (using the software packages supplied with OpenBSD) in an afternoon.

It's a little trickier to do in practice.  I kind of wish pfSense
included such functionality by default, it'd be so killer.  :-)
Last I checked, it was possible-but-a-fair-bit-of-messing-around.

Still, vote++ for pfSense.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From bhmccie at gmail.com  Wed Nov  9 08:52:52 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Wed, 09 Nov 2011 08:52:52 -0600
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <201111091400.pA9E01lg081698@aurora.sol.net>
References: <201111091400.pA9E01lg081698@aurora.sol.net>
Message-ID: <4EBA93C4.8010809@gmail.com>

I think that firewall/censorship is all semantics. The real question is 
the scale of the environment and the culture of your shop and areas of 
ownership.

I work in a large enterprise. Combining "functions" such as L3 
firewalling with content filtering with url filtering with XXX can be 
difficult.

1. Can the platform actually handle all the traffic?
2. Does one group own ALL the separate functions? If not, RBAC becomes 
an important (and sometimes political) issue.
3. How easy is it to troubleshoot?

Although modern hardware is quickly catching up with all the glorious 
software features people want these days, in our environment we found it 
easier and saner to separate these functions. They were owned by 
different groups and the number of FWs we deploy vs the number of 
content filters didn't add up to make sense when aggregating functions 
was discussed.

In a smaller operation a Fortinet or other product that consolidates 
these efforts may make sense. In a larger operation in depends on many 
outside factors.

I've had the (dis)pleasure of working with PIX/FWSM/ASA since Vietnam. 
I've worked with Netscreen/Juniper, IPTables, PFsense, CheckPoint over 
Nokia, CheckPoint over Winblows, CheckPoint over UTM, Fortinet, 
Sonicwall (say Uncle!) and others. They all have their pros and cons and 
in the end it is specific to your shops needs.

More of a UNIX guy? BSD FWs. No we aren't going to talk about how BSD 
isn't UNIX. That's a different mailing list.
More of a Linux guy and need to make sure you have a vendor to yell at? 
CheckPoint. IPSO/SPLAT/GAEA is all Linux.
Not a UNIX/Linux guy and you need a more reliable vendor? And a 
traditionally safer bet? "No one ever got fired for buying Cisco."
Need to save money? Consolidate functions? Confident of the capabilities 
of the product? Fortinet.

And the list goes on and on and on....


-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/09/2011 08:00 AM, Joe Greco wrote:
>> On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:
>>      
>>> An important feature lacking for now as far as I know is content/web
>>> filtering especially for corporates wishing to block
>>> inappropriate/time wasting content like facebook.
>>>        
>> 1. That's not a firewall function.  That's a censorship function.
>>      
> A "firewall" is pretty much a censorship function, you're using it to
> disallow certain types of traffic on your network.  It's simply a matter
> of what layer you find most convenient to block things...  a firewall
> is better closer to the bottom of the OSI layer model, a proxy is better
> closer to the top of the OSI layer model.
>
> Is it "censorship" not to want unwanted connection attempts to our
> gear, and block unsolicited TCP connections inbound?
>
> Is it "censorship" not to want unwanted exploit attempts to our
> gear, and run everything through ClamAV, and use blocklists to
> prevent users inadvertently pulling content from known malware sites?
>
> There's no functional differentiation between blocking content for
> one reason and blocking it for another.  There's certainly a huge
> difference in the POLICY decisions that drive those blocking decisions,
> but the technology to do them is essentially identical.  You can,
> after all, block facebook on your firewall at the IP level and I think
> we would both agree that that is "censorship" but also something a
> firewall is completely capable of.  It's just neater and more practical
> to do at a higher level, for when facebook changes IP addresses (etc),
> so a higher level block is really more appropriate.
>
>    
>> 2. You can of course easily do that via a variety of means, including
>> BOGUS'ing the domains in DNS, blocking port 80 traffic to their network
>> allocations, running an HTTP proxy that blocks them, etc.  I presume
>> that any minimally-competent censor could easily devise a first-order
>> solution (using the software packages supplied with OpenBSD) in an afternoon.
>>      
> It's a little trickier to do in practice.  I kind of wish pfSense
> included such functionality by default, it'd be so killer.  :-)
> Last I checked, it was possible-but-a-fair-bit-of-messing-around.
>
> Still, vote++ for pfSense.
>
> ... JG
>    

From bhmccie at gmail.com  Wed Nov  9 09:00:50 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Wed, 09 Nov 2011 09:00:50 -0600
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBA93C4.8010809@gmail.com>
References: <201111091400.pA9E01lg081698@aurora.sol.net>
 <4EBA93C4.8010809@gmail.com>
Message-ID: <4EBA95A2.1060004@gmail.com>

OH yeah!

MANAGEMENT: If you have a few FWs and you manage them independently life 
is grand. But what if you have 20? 50? 100? and if 30-40 percent of the 
policy is the same?

Cisco: NOTHING. Don't let them lie to you.
CheckPoint: Provider 1 and SmartManager.
Juniper: Not sure.
BSD/PFSense: Nothing I know of
Others: ???

Disclaimer: We are currently a CheckPoint/FWSM/PIX/ASA/Juniper shop. 
This is the byproduct of mergers/acquisitions/etc. We have standardized 
on CheckPoint and are phasing out the other vendors as they sunset. A 
major factor in the decision was management. In the end, if you separate 
the functions like we do, a FW is a FW is a FW. L3/4 isn't that 
complicated these days. It's L7 FWs that get the attention. So if the 
product is stable and has a good MTBF then it's not a huge difference to 
us as far as the capability of the FW to perform it's function. They all 
do it well.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/09/2011 08:52 AM, -Hammer- wrote:
> I think that firewall/censorship is all semantics. The real question 
> is the scale of the environment and the culture of your shop and areas 
> of ownership.
>
> I work in a large enterprise. Combining "functions" such as L3 
> firewalling with content filtering with url filtering with XXX can be 
> difficult.
>
> 1. Can the platform actually handle all the traffic?
> 2. Does one group own ALL the separate functions? If not, RBAC becomes 
> an important (and sometimes political) issue.
> 3. How easy is it to troubleshoot?
>
> Although modern hardware is quickly catching up with all the glorious 
> software features people want these days, in our environment we found 
> it easier and saner to separate these functions. They were owned by 
> different groups and the number of FWs we deploy vs the number of 
> content filters didn't add up to make sense when aggregating functions 
> was discussed.
>
> In a smaller operation a Fortinet or other product that consolidates 
> these efforts may make sense. In a larger operation in depends on many 
> outside factors.
>
> I've had the (dis)pleasure of working with PIX/FWSM/ASA since Vietnam. 
> I've worked with Netscreen/Juniper, IPTables, PFsense, CheckPoint over 
> Nokia, CheckPoint over Winblows, CheckPoint over UTM, Fortinet, 
> Sonicwall (say Uncle!) and others. They all have their pros and cons 
> and in the end it is specific to your shops needs.
>
> More of a UNIX guy? BSD FWs. No we aren't going to talk about how BSD 
> isn't UNIX. That's a different mailing list.
> More of a Linux guy and need to make sure you have a vendor to yell 
> at? CheckPoint. IPSO/SPLAT/GAEA is all Linux.
> Not a UNIX/Linux guy and you need a more reliable vendor? And a 
> traditionally safer bet? "No one ever got fired for buying Cisco."
> Need to save money? Consolidate functions? Confident of the 
> capabilities of the product? Fortinet.
>
> And the list goes on and on and on....
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>    
>
> On 11/09/2011 08:00 AM, Joe Greco wrote:
>>> On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:
>>>      
>>>> An important feature lacking for now as far as I know is content/web
>>>> filtering especially for corporates wishing to block
>>>> inappropriate/time wasting content like facebook.
>>>>        
>>> 1. That's not a firewall function.  That's a censorship function.
>>>      
>> A "firewall" is pretty much a censorship function, you're using it to
>> disallow certain types of traffic on your network.  It's simply a matter
>> of what layer you find most convenient to block things...  a firewall
>> is better closer to the bottom of the OSI layer model, a proxy is better
>> closer to the top of the OSI layer model.
>>
>> Is it "censorship" not to want unwanted connection attempts to our
>> gear, and block unsolicited TCP connections inbound?
>>
>> Is it "censorship" not to want unwanted exploit attempts to our
>> gear, and run everything through ClamAV, and use blocklists to
>> prevent users inadvertently pulling content from known malware sites?
>>
>> There's no functional differentiation between blocking content for
>> one reason and blocking it for another.  There's certainly a huge
>> difference in the POLICY decisions that drive those blocking decisions,
>> but the technology to do them is essentially identical.  You can,
>> after all, block facebook on your firewall at the IP level and I think
>> we would both agree that that is "censorship" but also something a
>> firewall is completely capable of.  It's just neater and more practical
>> to do at a higher level, for when facebook changes IP addresses (etc),
>> so a higher level block is really more appropriate.
>>
>>    
>>> 2. You can of course easily do that via a variety of means, including
>>> BOGUS'ing the domains in DNS, blocking port 80 traffic to their network
>>> allocations, running an HTTP proxy that blocks them, etc.  I presume
>>> that any minimally-competent censor could easily devise a first-order
>>> solution (using the software packages supplied with OpenBSD) in an afternoon.
>>>      
>> It's a little trickier to do in practice.  I kind of wish pfSense
>> included such functionality by default, it'd be so killer.  :-)
>> Last I checked, it was possible-but-a-fair-bit-of-messing-around.
>>
>> Still, vote++ for pfSense.
>>
>> ... JG
>>    

From gcroft at shoremortgage.com  Wed Nov  9 09:04:06 2011
From: gcroft at shoremortgage.com (Gregory Croft)
Date: Wed, 09 Nov 2011 10:04:06 -0500
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
Message-ID: <CAE00096.15A55%gcroft@shoremortgage.com>

Hi, I'm at a smaller company that wanted not only firewall capabilities but
application level filtering.

We went with the Palo Alto Networks.
Story is the Palo Alto founder was formerly of Netscreen/Juniper.

Anyhow. We've not had any issues with the PA500's that we use in our
environment. They also just released a smaller unit (PA200) for small
offices. 

Very easy to use/operate. My only complaint is the time it takes to commit
changes. 

If you have any specific questions, shoot me an email.

Hope that helps.
Greg






On 11/8/11 6:06 PM, "Jones, Barry" <BEJones at semprautilities.com> wrote:

> Hello all.
> I am potentially looking at firewall products and wanted suggestions as to the
> easiest firewalls to install, configure and maintain? I have a few small
> networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I
> have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each
> have strong and not as strong features for ease of use. Like everyone, I'm
> resource challenged and need an easy solution to stand up and operate.
> 
> Feel free to ping me offline - and thank you for the assistance.
> 
> ----------------------------------------
> Barry Jones - CISSP GSNA
> Project Manager II
> Sempra Energy Utilities
> (760) 271-6822
> 
> P please don't print this e-mail unless you really need to.
> ----------------------------------------
> 



From jof at thejof.com  Wed Nov  9 09:18:45 2011
From: jof at thejof.com (Jonathan Lassoff)
Date: Wed, 9 Nov 2011 07:18:45 -0800
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBA7F04.6000105@foobar.org>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
Message-ID: <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>

On Wed, Nov 9, 2011 at 5:24 AM, Nick Hilliard <nick at foobar.org> wrote:
> On 09/11/2011 12:22, Richard Kulawiec wrote:
>> You will find it very difficult to beat pf on OpenBSD for efficiency,
>> features, flexibility, robustness, and security. ?Maintenance is very
>> easy: edit a configuration file, reload, done.
>
> There are several areas where pf falls down. ?One is auto-synchronisation
> from primary to backup firewall (not really a pf problem, but it's
> important for production firewall systems).

I've found that this works decently well, via pfsync. It sends out
multicast IP packets with multi-valued elements describing the state
of the flows it has in its table.

If you're having pf inspect TCP sequence numbers, there's a bit of a
race condition in failover with frequently or fast-moving TCP streams.
As the window of acceptable sequence numbers moves on the active
firewall, they're slightly delayed in getting replicated to the
backup(s) and installed in their state tables.
Consequently, on failover, it's possible for some flows to get blocked
and which have to be re-created.

I've hit this and dug into it recently, so if you're having a problem,
I'd be happy to chat offlist.

Cheers,
jof


From jcurran at arin.net  Wed Nov  9 09:33:04 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 9 Nov 2011 15:33:04 +0000
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
References: <4E9F20FF.1070203@arin.net>
Message-ID: <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>

NANOG Community -

    There is an Draft Policy for Inter-RIR Transfers presently in extended
    "Last Call" in the ARIN Policy Development Process.   The Last Call
    will run for one more week, and allows an opportunity for anyone in the
    Internet community to provide feedback regarding this proposed
    number resource policy.  Feedback, including statements in support
    or opposition, may be sent to the ARIN Public Policy Mailing List
    "arin-ppml at arin.net<mailto:arin-ppml at arin.net>"  (http://lists.arin.net/mailman/listinfo/arin-ppml
    to join or view archives)   A copy of the Last Call announcement,
    including the most recent changes and draft policy text, is attached
    to this email.  Feel free to forward this email to anyone in the Internet
    community that you feel may wish to comment in support or opposition
    to this draft policy.

Thanks!
/John

John Curran
President and CEO
ARIN

Begin forwarded message:

From: ARIN <info at arin.net<mailto:info at arin.net>>
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
Date: October 19, 2011 3:11:59 PM EDT
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>

The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
send an amended version of the following draft policy to an extended last call:

 ARIN-2011-1: ARIN Inter-RIR Transfers

The AC provided the following statement:

********
The Advisory Council reviewed the results of feedback from the ARIN
XXVIII Public Policy Meeting concerning Draft Policy 2011-1 Inter-RIR
Transfers.  While there were concerns regarding the presented wording,
there was significant continued support for a policy enabling
Inter-Regional transfers of IPv4 number resources from organizations able to make them available to any organization with valid requirements.

In addition to cumbersome wording, the presented text could not be
cleanly inserted into the NRPM.  The following is new language that
directly modifies section 8.3 "Transfers to Specified Recipients" to
allow such transfers to or from organizations in other regions.

The first paragraph is a modified version of the current 8.3 policy
language, envisioning resources being released to ARIN by the authorized
resources holder or additionally by another RIR to be transferred to a
specified recipient.  The second sentence was reorganized to emphasize
that it applies to an organization within the ARIN region that will
receive such a specified transfer, and to eliminate the single aggregate
language per 2011-10 which is also being sent to last call.

The new second paragraph adds language enabling transfers to a specified
recipient in another RIR's service region.  This language specifies that
such recipients justify their need to their RIR, following that RIR's
policies.  ARIN will verify that there is a compatible needs based
policy that the other RIR will use to evaluate the need of the recipient
and that both RIR's agree to the transfer. Implicit in the intent of
the language presented and in conformance with statements made, the size
of the block to be transferred is identified as /24 or larger, for
obvious practical reasons.

In accordance with concern for immediate adoption, the AC chose to
forward this version to last call.  Concerns expressed by some
stakeholders for further controls were noted by the AC, and are being
considered for future policy modification, assuaged in part by ARIN
staff assurances that if any significant abuse of this policy were to
occur, then the policy could easily be suspended.

The AC thanks everyone in the community for their help in crafting this
important policy and for your statements of support or other comments
during Last Call.
********

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. Last call for 2011-1 will
expire on 16 November 2011. After last call the AC will conduct their last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2011-1
ARIN Inter-RIR Transfers

Date/version: 14 October 2011

Policy statement:

8.3 Transfers to Specified Recipients

In addition to transfers under section 8.2, IPv4 number resources may be
released to ARIN by the authorized resource holder or another RIR, in
whole or in part, for transfer to another specified organizational
recipient.  Organizations in the ARIN region may receive transferred
number resources under RSA if they can demonstrate the need for such
resources in the amount which they can justify under current ARIN policies.

IPv4 address resources may be transferred to organizations in another
RIR's service region if they demonstrate need to their region's RIR,
according to that RIR's policies. Inter-regional transfers may take
place only via RIRs who agree to the transfer and share compatible,
needs-based policies. Such resources must be transferred in blocks of
/24 or larger and will become part of the resource holdings of the
recipient RIR.

Timetable for implementation: immediate
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From bicknell at ufp.org  Wed Nov  9 09:56:33 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 9 Nov 2011 07:56:33 -0800
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
Message-ID: <20111109155633.GA21891@ussenterprise.ufp.org>

In a message written on Wed, Nov 09, 2011 at 03:33:04PM +0000, John Curran wrote:
> 
>     There is an Draft Policy for Inter-RIR Transfers presently in extended
>     "Last Call" in the ARIN Policy Development Process.   The Last Call
>     will run for one more week, and allows an opportunity for anyone in the
>     Internet community to provide feedback regarding this proposed
>     number resource policy.  Feedback, including statements in support

I went and read a fair number of PPML messages via the web interface
as I no longer subscribe.  I also read the policy proposal.

I think the AC, and ARIN's policy process in general has come off
the rails.  There's a reason why I unsubscribed from PPML, and have
not participated for 2+ years.  I don't know exactly where things
went wrong, but somewhere they went very, very wrong.

But I don't have to summarize, Bill Sandiford (an AC Member) already
did that for me:
http://lists.arin.net/pipermail/arin-ppml/2011-November/023661.html

Which leads me to my thoughts on the process, from two areas:

1) The concept of Inter-RIR transfers is a bad idea.  Insuring
   "compatible" rules between RIR's will always be difficult at
   best.  There are technical difficulties for the RIR's, such
   as how reverse DNS is handled.  Most importantly, after going
   through all the pain of figuring out these details it's unlikely
   to help very many people at all.

2) The process followed to get here is totally broken.  Bill hit
   the nail on the head, and it's archived on ARIN's web site:
   Text in Sep: http://lists.arin.net/pipermail/arin-ppml/2011-September/023170.html
   Text in Oct: http://lists.arin.net/pipermail/arin-ppml/2011-October/023362.html

   Near as I can tell the feedback in the October meeting made the
   AC want to do a _total rewrite of the entire policy_, which they
   turned around in under a week and shoved directly into the last
   call process.

It's disgusting, and I'm glad I'm no longer involved.  It's a mockery of
the policy process ARIN has set up, and I'm baffled to this day why more
folks aren't upset about it.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111109/ef8d83e8/attachment.bin>

From bill at herrin.us  Wed Nov  9 10:19:28 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 9 Nov 2011 11:19:28 -0500
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
Message-ID: <CAP-guGVuW9z6Pvf-ojKQtaxo9ArS_Dnb7WMkpE_JjT3K=RzBAA@mail.gmail.com>

On Wed, Nov 9, 2011 at 10:33 AM, John Curran <jcurran at arin.net> wrote:
> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
> send an amended version of the following draft policy to an extended last call:
>
> ?ARIN-2011-1: ARIN Inter-RIR Transfers

Hi folks,

There has been some contentious debate about this draft policy. In
particular, it may provide a path for bleeding IPv4 addresses from
North America to other world regions without requiring reciprocal
access to other regions' IPv4 addresses for North American companies.

If this concerns you, and I hope it does, I urge you to educate
yourself on the matter and then voice your opinion on the ARIN public
policy mailing list.

Reference materials:

The policy as presently drafted:
http://lists.arin.net/pipermail/arin-ppml/2011-October/023362.html

The proposed policy's draft history:
https://www.arin.net/policy/proposals/2011_1.html

How to subscribe to the ARIN public policy mailing list:
http://lists.arin.net/mailman/listinfo/arin-ppml

A brief selection of issues raised in the debate:

http://lists.arin.net/pipermail/arin-ppml/2011-October/023441.html
http://lists.arin.net/pipermail/arin-ppml/2011-October/023464.html
http://lists.arin.net/pipermail/arin-ppml/2011-October/023467.html
http://lists.arin.net/pipermail/arin-ppml/2011-October/023500.html
http://lists.arin.net/pipermail/arin-ppml/2011-October/023511.html
http://lists.arin.net/pipermail/arin-ppml/2011-October/023527.html
http://lists.arin.net/pipermail/arin-ppml/2011-November/023661.html
http://lists.arin.net/pipermail/arin-ppml/2011-November/023667.html

Regards,
Bill Herrin




-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jcurran at arin.net  Wed Nov  9 10:28:56 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 9 Nov 2011 16:28:56 +0000
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in
 one week)
In-Reply-To: <20111109155633.GA21891@ussenterprise.ufp.org>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org>
Message-ID: <4AA3446B-5311-4AFF-BEB0-75139468DF2B@corp.arin.net>

On Nov 9, 2011, at 10:56 AM, Leo Bicknell wrote:

> 2) The process followed to get here is totally broken.  Bill hit
>   the nail on the head, and it's archived on ARIN's web site:
>   Text in Sep: http://lists.arin.net/pipermail/arin-ppml/2011-September/023170.html
>   Text in Oct: http://lists.arin.net/pipermail/arin-ppml/2011-October/023362.html
> 
>   Near as I can tell the feedback in the October meeting made the
>   AC want to do a _total rewrite of the entire policy_, which they
>   turned around in under a week and shoved directly into the last
>   call process.

Leo - 

  To be clear, the ARIN Advisory Council (ARIN AC) is definitely following 
  the current ARIN policy development process.  If they weren't, I would be 
  obligated to directly intervene.
 
  It is true that the present Policy Development process allows the AC ample 
  latitude in changing the policy proposals, with the requirement that if the 
  Advisory Council sends a draft policy to last call that is different from 
  the one presented at the public policy meeting, then the Advisory Council 
  will provide an explanation for all changes made to the text.

  My message to NANOG was to encourage folks to speak out on the PPML mailing
  list regarding their thoughts on the draft policy, as that is the forum 
  where the input will have the most impact.  I will note that ARIN also just
  completed an open consultation on a revised Policy Development Process, and
  while it has closed, I will take directly any suggestions that you have for
  changes to that process that you feel are necessary.

Thanks!
/John

John Curran
President and CEO
ARIN



From John_Brzozowski at Cable.Comcast.com  Wed Nov  9 10:32:39 2011
From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John)
Date: Wed, 9 Nov 2011 16:32:39 +0000
Subject: Comcast IPv6 Update
Message-ID: <CAE01557.1ABFB9%john_brzozowski@cable.comcast.com>

Update from http://www.comcast6.net
IPv6 Pilot Market Deployment Begins
Wednesday, November 9, 2011

Comcast has started our first pilot market deployment of IPv6 in limited areas of California and Colorado. This first phase supports directly connected CPE, where a single computer is directly connected to a cable device. A subsequent phase will support home gateway devices. To learn more, check out FAQs on the pilot market deployment<http://www.comcast6.net/pilotfaq.php> and the announcement<http://blog.comcast.com/2011/11/ipv6-deployment.html> and technical details<http://blog.comcast.com/2011/11/ipv6-deployment-technology.html> on our blog.

John
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski at cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================



From jeroen at unfix.org  Wed Nov  9 10:40:40 2011
From: jeroen at unfix.org (Jeroen Massar)
Date: Wed, 09 Nov 2011 17:40:40 +0100
Subject: Comcast IPv6 Update
In-Reply-To: <CAE01557.1ABFB9%john_brzozowski@cable.comcast.com>
References: <CAE01557.1ABFB9%john_brzozowski@cable.comcast.com>
Message-ID: <4EBAAD08.1010205@unfix.org>

On 2011-11-09 17:32 , Brzozowski, John wrote:
> Update from http://www.comcast6.net
> IPv6 Pilot Market Deployment Begins
> Wednesday, November 9, 2011
> 
> Comcast has started our first pilot market deployment of IPv6...

Congrats! One step closer to full deployment!

Greets,
 Jeroen


From sclark at netwolves.com  Wed Nov  9 10:47:31 2011
From: sclark at netwolves.com (Steve Clark)
Date: Wed, 09 Nov 2011 11:47:31 -0500
Subject: Comcast IPv6 Update
In-Reply-To: <4EBAAD08.1010205@unfix.org>
References: <CAE01557.1ABFB9%john_brzozowski@cable.comcast.com>
 <4EBAAD08.1010205@unfix.org>
Message-ID: <4EBAAEA3.1090905@netwolves.com>

On 11/09/2011 11:40 AM, Jeroen Massar wrote:
> On 2011-11-09 17:32 , Brzozowski, John wrote:
>> Update from http://www.comcast6.net
>> IPv6 Pilot Market Deployment Begins
>> Wednesday, November 9, 2011
>>
>> Comcast has started our first pilot market deployment of IPv6...
> Congrats! One step closer to full deployment!
>
> Greets,
>   Jeroen
>
Sort of interesting that you are only handing out a single address and not a prefix  - which seems contradictory
to all recommended practices.

Will this be a continued effort for ISP's to charge for extra routable addresses?

My $.02




-- 
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark at netwolves.com
http://www.netwolves.com

From cb.list6 at gmail.com  Wed Nov  9 10:49:09 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Wed, 9 Nov 2011 08:49:09 -0800
Subject: Comcast IPv6 Update
In-Reply-To: <4EBAAD08.1010205@unfix.org>
References: <CAE01557.1ABFB9%john_brzozowski@cable.comcast.com>
 <4EBAAD08.1010205@unfix.org>
Message-ID: <CAD6AjGQXT8mBGVnbF_vXnTpr1k=q+_4xEi2Jxm-ES+kMquw2dw@mail.gmail.com>

On Wed, Nov 9, 2011 at 8:40 AM, Jeroen Massar <jeroen at unfix.org> wrote:
> On 2011-11-09 17:32 , Brzozowski, John wrote:
>> Update from http://www.comcast6.net
>> IPv6 Pilot Market Deployment Begins
>> Wednesday, November 9, 2011
>>
>> Comcast has started our first pilot market deployment of IPv6...
>
> Congrats! One step closer to full deployment!
>

+1

Glad to hear some good news about IPv6 deployment.  Now, lets talk
about deployment in Seattle :)


From blake at pfankuch.me  Wed Nov  9 10:54:32 2011
From: blake at pfankuch.me (Blake T. Pfankuch)
Date: Wed, 9 Nov 2011 16:54:32 +0000
Subject: Comcast IPv6 Update
In-Reply-To: <CAE01557.1ABFB9%john_brzozowski@cable.comcast.com>
References: <CAE01557.1ABFB9%john_brzozowski@cable.comcast.com>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C846D956E03@SHSBS.shenrons-house.local>

This appears directed at the Home market.  Any word on the Business Class market even as a /128?

-----Original Message-----
From: Brzozowski, John [mailto:John_Brzozowski at Cable.Comcast.com] 
Sent: Wednesday, November 09, 2011 9:33 AM
To: NANOG
Subject: Comcast IPv6 Update

Update from http://www.comcast6.net
IPv6 Pilot Market Deployment Begins
Wednesday, November 9, 2011

Comcast has started our first pilot market deployment of IPv6 in limited areas of California and Colorado. This first phase supports directly connected CPE, where a single computer is directly connected to a cable device. A subsequent phase will support home gateway devices. To learn more, check out FAQs on the pilot market deployment<http://www.comcast6.net/pilotfaq.php> and the announcement<http://blog.comcast.com/2011/11/ipv6-deployment.html> and technical details<http://blog.comcast.com/2011/11/ipv6-deployment-technology.html> on our blog.

John
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski at cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================




From John_Brzozowski at Cable.Comcast.com  Wed Nov  9 10:54:45 2011
From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John)
Date: Wed, 9 Nov 2011 16:54:45 +0000
Subject: Comcast IPv6 Update
In-Reply-To: <4EBAAEA3.1090905@netwolves.com>
Message-ID: <CAE0193F.1ABFE6%john_brzozowski@cable.comcast.com>

This is not all we are pursuing, it is part of our incremental enablement
and deployment.  We have a non-trivial population of users that are
directly connected versus using a home router.  If you notice we also
mention that we will soon be sharing information about customer home
gateway plans.

Stay tuned.

John
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski at cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================




On 11/9/11 11:47 AM, "Steve Clark" <sclark at netwolves.com> wrote:

>
>  
>  
>    On 11/09/2011 11:40 AM, Jeroen Massar wrote:
>    
>      On 2011-11-09 17:32 , Brzozowski, John wrote:
>
>      
>        Update from http://www.comcast6.net
>IPv6 Pilot Market Deployment Begins
>Wednesday, November 9, 2011
>
>Comcast has started our first pilot market deployment of IPv6...
>
>      
>
>      Congrats! One step closer to full deployment!
>
>Greets,
> Jeroen
>
>
>    
>
>    Sort of interesting that you are only
>      handing out a single address and not a prefix  - which seems
>      contradictory
>      to all recommended practices.
>      
>      Will this be a continued effort for ISP's to charge for extra
>      routable addresses?
>      
>      My $.02
>      
>      
>      
>    
>    -- 
>      Stephen Clark
>      NetWolves
>      Sr. Software Engineer III
>      Phone: 813-579-3200
>      Fax: 813-882-0209
>      Email: steve.clark at netwolves.com
>      http://www.netwolves.com
>    
>  
>



From John_Brzozowski at Cable.Comcast.com  Wed Nov  9 10:56:03 2011
From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John)
Date: Wed, 9 Nov 2011 16:56:03 +0000
Subject: Comcast IPv6 Update
In-Reply-To: <CAD6AjGQXT8mBGVnbF_vXnTpr1k=q+_4xEi2Jxm-ES+kMquw2dw@mail.gmail.com>
Message-ID: <CAE01ACA.1ABFFD%john_brzozowski@cable.comcast.com>

:)

=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski at cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================




On 11/9/11 11:49 AM, "Cameron Byrne" <cb.list6 at gmail.com> wrote:

>On Wed, Nov 9, 2011 at 8:40 AM, Jeroen Massar <jeroen at unfix.org> wrote:
>> On 2011-11-09 17:32 , Brzozowski, John wrote:
>>> Update from http://www.comcast6.net
>>> IPv6 Pilot Market Deployment Begins
>>> Wednesday, November 9, 2011
>>>
>>> Comcast has started our first pilot market deployment of IPv6...
>>
>> Congrats! One step closer to full deployment!
>>
>
>+1
>
>Glad to hear some good news about IPv6 deployment.  Now, lets talk
>about deployment in Seattle :)



From Jason_Livingood at cable.comcast.com  Wed Nov  9 10:58:03 2011
From: Jason_Livingood at cable.comcast.com (Livingood, Jason)
Date: Wed, 9 Nov 2011 16:58:03 +0000
Subject: Comcast IPv6 Update
In-Reply-To: <CC75EEBF17C7374EA8309102B7B10C846D956E03@SHSBS.shenrons-house.local>
Message-ID: <CAE01AF8.41C4C%jason_livingood@cable.comcast.com>

On 11/9/11 11:54 AM, "Blake T. Pfankuch" <blake at pfankuch.me> wrote:


>This appears directed at the Home market.  Any word on the Business Class
>market even as a /128?

Business Class is coming later. It won't hurt to contact the Business
Class sales number and ask about IPv6 (and tell them to escalate it) - it
all helps get us internal support and buy in. It is definitely on our
radar though. 

- Jason



From matthew at walster.org  Wed Nov  9 12:07:34 2011
From: matthew at walster.org (Matthew Walster)
Date: Wed, 9 Nov 2011 18:07:34 +0000
Subject: Logs Bank
In-Reply-To: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
References: <grj7q0.lucy8m.1bqrm81-qmf@mx.google.com>
Message-ID: <CADLW2vzdHpGszXQf32A8nrS82K=1Wyr9_bthBFaNe2T4t+RjNg@mail.gmail.com>

On 8 November 2011 19:59, <joshua.klubi at gmail.com> wrote:
>
> If I may ask, is there any OSS that can serve as a log bank or log server,


<snip>

Do you mean OSS, or do you mean free?

</bugbear>

M

From nathan at atlasnetworks.us  Wed Nov  9 12:10:19 2011
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Wed, 9 Nov 2011 18:10:19 +0000
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBA72ED.2010909@gmail.com>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA72ED.2010909@gmail.com>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B5E2F71@ex-mb-1.corp.atlasnetworks.us>

> An important feature lacking for now as far as I know is content/web
> filtering especially for corporates wishing to block inappropriate/time
> wasting content like facebook. Addition of this would place it a par
> with the best like Sonicwall and Fortinet.
 
At a previous employer, we utilized a Fortigate 200B to replace multiple boxen (two firewalls, barracuda, etc).  I found it utterly underpowered for the featureset (even with much of it disabled), and its ability to utilize multiple WAN connections was extremely limited.  I realize this is only a low-to-midline example of their lineup, but I was consistently surprised by how easy it was to overwhelm the device, especially given the price-point.  The only thing I remember liking was the SSL-VPN functionality, but we couldn't use it because there was no Vista support at the time, so that was disabled too.

Now, perhaps they've made progress, or their higher end devices perform better - just sharing my experience with the 200B.

Nathan


From dmburgess at linktechs.net  Wed Nov  9 12:16:28 2011
From: dmburgess at linktechs.net (Dennis Burgess)
Date: Wed, 9 Nov 2011 12:16:28 -0600
Subject: Firewalls - Ease of Use and Maintenance?
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <4EB9BC04.5010103@gmail.com>
Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50BA68A49@ltiserver.lti.local>

Another alternative is RouterOS/MikroTik.  Plenty of high end solutions
and low end.   

-----------------------------------------------------------
Dennis Burgess, Mikrotik Certified Trainer 
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270 Website: http://www.linktechs.net
LIVE On-Line Mikrotik Training - Author of "Learn RouterOS"

> -----Original Message-----
> From: -Hammer- [mailto:bhmccie at gmail.com]
> Sent: Tuesday, November 08, 2011 5:32 PM
> To: nanog at nanog.org
> Subject: Re: Firewalls - Ease of Use and Maintenance?
> 
> You've worked with all the big dogs. What are you looking for?
> Alternative options?
> 
> -Hammer-
> 
> "I was a normal American nerd"
> -Jack Herer
> 
> 
> 
> On 11/08/2011 05:06 PM, Jones, Barry wrote:
> > Hello all.
> > I am potentially looking at firewall products and wanted suggestions
as to
> the easiest firewalls to install, configure and maintain? I have a few
small
> networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at
another.
> I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia),
and
> each have strong and not as strong features for ease of use. Like
everyone,
> I'm resource challenged and need an easy solution to stand up and
operate.
> >
> > Feel free to ping me offline - and thank you for the assistance.
> >
> > ----------------------------------------
> > Barry Jones - CISSP GSNA
> > Project Manager II
> > Sempra Energy Utilities
> > (760) 271-6822
> >
> > P please don't print this e-mail unless you really need to.
> > ----------------------------------------
> >
> >


From Valdis.Kletnieks at vt.edu  Wed Nov  9 12:29:43 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 09 Nov 2011 13:29:43 -0500
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: Your message of "Wed, 09 Nov 2011 08:00:01 CST."
 <201111091400.pA9E01lg081698@aurora.sol.net>
References: <201111091400.pA9E01lg081698@aurora.sol.net>
Message-ID: <9283.1320863383@turing-police.cc.vt.edu>

On Wed, 09 Nov 2011 08:00:01 CST, Joe Greco said:
> > On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:
> > > An important feature lacking for now as far as I know is content/web
> > > filtering especially for corporates wishing to block
> > > inappropriate/time wasting content like facebook. 

> > 1. That's not a firewall function.  That's a censorship function.

> Is it "censorship" not to want unwanted connection attempts to our
> gear, and block unsolicited TCP connections inbound?

> Is it "censorship" not to want unwanted exploit attempts to our
> gear, and run everything through ClamAV, and use blocklists to
> prevent users inadvertently pulling content from known malware sites?

I do believe that Alex was saying "blocking outbound access to time wasters
like Facebook" is a censorship function, not a firewall function.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111109/ee248022/attachment.bin>

From zeusdadog at gmail.com  Wed Nov  9 12:47:37 2011
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Wed, 9 Nov 2011 13:47:37 -0500
Subject: Anyone seen this kind of problem? SIP traffic not getting to
 destination but traceroute does
Message-ID: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>

We ran into a strange situation yesterday that I am still trying to
figure out.  We have many VoIP customers but yesterday suddenly select
few of them couldn't reach the SIP provider's network from our
network.

I could traceroute to the SIP providers server from the affected
clients' IP just fine.  I confirmed that the SIP traffic was leaving
our network out the interface to the upstream provider and the SIP
provider says they couldn't see the SIP traffic come into their border
router.

SIP traffic coming from SIP provider to the affected customer came
through fine.  It's just Us -> SIP server was a problem.

I thought there may be some strange BGP issue going on but we had
other customers within the same /24 as the affected customers and they
were connecting fine.

The traffic at the time traversed

Our network -> Qwest/century link -> Level 3 -> SIP provider

I changed the routing around so it would go through our other
upstream, AT&T, and it started working.  With AT&T, the route was

Our network -> AT&T -> Level 3 -> SIP provider

So my questions is, is it possible there is some kind of filter at
Qwest or Level 3 that is dropping traffic only for udp 5060 for select
few IPs?  That's the only explanation I can come up with other than
the whole Juniper BGP issue 2 days ago left something in between in a
strange state?  I read the post about XO doing filtering on transit
traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.


From nick at foobar.org  Wed Nov  9 12:58:59 2011
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Nov 2011 18:58:59 +0000
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
Message-ID: <4EBACD73.60609@foobar.org>

On 09/11/2011 15:18, Jonathan Lassoff wrote:
> I've found that this works decently well, via pfsync.

I meant config sync, not state sync.

Nick



From sean at seanharlow.info  Wed Nov  9 12:59:56 2011
From: sean at seanharlow.info (Sean Harlow)
Date: Wed, 9 Nov 2011 13:59:56 -0500
Subject: Anyone seen this kind of problem? SIP traffic not getting to
 destination but traceroute does
In-Reply-To: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
References: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
Message-ID: <1A009F7C-6D9C-4CD4-9206-3027D4ADEB70@seanharlow.info>

I can't say I have a specific answer to your question, but yesterday I was seeing major packet loss on outbound audio from all my VoIP customers using Qwest and going in to servers on L3.  It's entirely possible that SIP was also being lost, just the audio was the more notable and pressing issue.  It seems to be resolved at this point, but we have not yet heard from Qwest what the actual problem was.

This was with sites in Northeast Ohio and the Chicago area connecting to servers in New York and LA for what it's worth.
----------
Sean Harlow
sean at seanharlow.info

On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote:

> We ran into a strange situation yesterday that I am still trying to
> figure out.  We have many VoIP customers but yesterday suddenly select
> few of them couldn't reach the SIP provider's network from our
> network.
> 
> I could traceroute to the SIP providers server from the affected
> clients' IP just fine.  I confirmed that the SIP traffic was leaving
> our network out the interface to the upstream provider and the SIP
> provider says they couldn't see the SIP traffic come into their border
> router.
> 
> SIP traffic coming from SIP provider to the affected customer came
> through fine.  It's just Us -> SIP server was a problem.
> 
> I thought there may be some strange BGP issue going on but we had
> other customers within the same /24 as the affected customers and they
> were connecting fine.
> 
> The traffic at the time traversed
> 
> Our network -> Qwest/century link -> Level 3 -> SIP provider
> 
> I changed the routing around so it would go through our other
> upstream, AT&T, and it started working.  With AT&T, the route was
> 
> Our network -> AT&T -> Level 3 -> SIP provider
> 
> So my questions is, is it possible there is some kind of filter at
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
> few IPs?  That's the only explanation I can come up with other than
> the whole Juniper BGP issue 2 days ago left something in between in a
> strange state?  I read the post about XO doing filtering on transit
> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
> 



From preston.parcell at viawest.com  Wed Nov  9 13:04:01 2011
From: preston.parcell at viawest.com (Preston Parcell)
Date: Wed, 9 Nov 2011 11:04:01 -0800
Subject: Anyone seen this kind of problem? SIP traffic not getting to
 destination but traceroute does
In-Reply-To: <1A009F7C-6D9C-4CD4-9206-3027D4ADEB70@seanharlow.info>
References: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
 <1A009F7C-6D9C-4CD4-9206-3027D4ADEB70@seanharlow.info>
Message-ID: <B24A2F7EC1495447B32D350F6B4DF63802729A3BDC5E@EXVMBX017-1.exch017.msoutlookonline.net>

What was the timeframe for your issues? Just curious since we saw some strangeness last night.


Preston 



-----Original Message-----
From: Sean Harlow [mailto:sean at seanharlow.info] 
Sent: Wednesday, November 09, 2011 12:00 PM
To: Jay Nakamura
Cc: NANOG
Subject: Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

I can't say I have a specific answer to your question, but yesterday I was seeing major packet loss on outbound audio from all my VoIP customers using Qwest and going in to servers on L3.  It's entirely possible that SIP was also being lost, just the audio was the more notable and pressing issue.  It seems to be resolved at this point, but we have not yet heard from Qwest what the actual problem was.

This was with sites in Northeast Ohio and the Chicago area connecting to servers in New York and LA for what it's worth.
----------
Sean Harlow
sean at seanharlow.info

On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote:

> We ran into a strange situation yesterday that I am still trying to 
> figure out.  We have many VoIP customers but yesterday suddenly select 
> few of them couldn't reach the SIP provider's network from our 
> network.
> 
> I could traceroute to the SIP providers server from the affected 
> clients' IP just fine.  I confirmed that the SIP traffic was leaving 
> our network out the interface to the upstream provider and the SIP 
> provider says they couldn't see the SIP traffic come into their border 
> router.
> 
> SIP traffic coming from SIP provider to the affected customer came 
> through fine.  It's just Us -> SIP server was a problem.
> 
> I thought there may be some strange BGP issue going on but we had 
> other customers within the same /24 as the affected customers and they 
> were connecting fine.
> 
> The traffic at the time traversed
> 
> Our network -> Qwest/century link -> Level 3 -> SIP provider
> 
> I changed the routing around so it would go through our other 
> upstream, AT&T, and it started working.  With AT&T, the route was
> 
> Our network -> AT&T -> Level 3 -> SIP provider
> 
> So my questions is, is it possible there is some kind of filter at 
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select 
> few IPs?  That's the only explanation I can come up with other than 
> the whole Juniper BGP issue 2 days ago left something in between in a 
> strange state?  I read the post about XO doing filtering on transit 
> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
> 




From nathan at atlasnetworks.us  Wed Nov  9 13:04:52 2011
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Wed, 9 Nov 2011 19:04:52 +0000
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBACD73.60609@foobar.org>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B5E3E52@ex-mb-1.corp.atlasnetworks.us>

> I meant config sync, not state sync.
 
I have multiple deployments of the config synchronization working just fine.  :)


From jlarsen at richweb.com  Wed Nov  9 13:07:10 2011
From: jlarsen at richweb.com (C. Jon Larsen)
Date: Wed, 9 Nov 2011 14:07:10 -0500 (EST)
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBACD73.60609@foobar.org>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org>
Message-ID: <alpine.DEB.2.02.1111091405410.4911@sisler>


On Wed, 9 Nov 2011, Nick Hilliard wrote:

> On 09/11/2011 15:18, Jonathan Lassoff wrote:
>> I've found that this works decently well, via pfsync.
>
> I meant config sync, not state sync.

put the main portion of the conf in subversion as an include file and 
factor out local differences in the configs with macros that are defined 
in pf.conf

Easy.


From zeusdadog at gmail.com  Wed Nov  9 13:08:00 2011
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Wed, 9 Nov 2011 14:08:00 -0500
Subject: Anyone seen this kind of problem? SIP traffic not getting to
 destination but traceroute does
In-Reply-To: <B24A2F7EC1495447B32D350F6B4DF63802729A3BDC5E@EXVMBX017-1.exch017.msoutlookonline.net>
References: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
 <1A009F7C-6D9C-4CD4-9206-3027D4ADEB70@seanharlow.info>
 <B24A2F7EC1495447B32D350F6B4DF63802729A3BDC5E@EXVMBX017-1.exch017.msoutlookonline.net>
Message-ID: <CADs2+OGMi9P77e5-EqpJSOv1uNWGrqs=hqMdOpCd-0mq-dMNbQ@mail.gmail.com>

It started sometime Tuesday morning.  I have yet to set the route back
to Qwest.  I am going to do that tonight and test it.

On Wed, Nov 9, 2011 at 2:04 PM, Preston Parcell
<preston.parcell at viawest.com> wrote:
> What was the timeframe for your issues? Just curious since we saw some strangeness last night.
>
>
> Preston
>
>
>
> -----Original Message-----
> From: Sean Harlow [mailto:sean at seanharlow.info]
> Sent: Wednesday, November 09, 2011 12:00 PM
> To: Jay Nakamura
> Cc: NANOG
> Subject: Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does
>
> I can't say I have a specific answer to your question, but yesterday I was seeing major packet loss on outbound audio from all my VoIP customers using Qwest and going in to servers on L3. ?It's entirely possible that SIP was also being lost, just the audio was the more notable and pressing issue. ?It seems to be resolved at this point, but we have not yet heard from Qwest what the actual problem was.
>
> This was with sites in Northeast Ohio and the Chicago area connecting to servers in New York and LA for what it's worth.
> ----------
> Sean Harlow
> sean at seanharlow.info
>
> On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote:
>
>> We ran into a strange situation yesterday that I am still trying to
>> figure out. ?We have many VoIP customers but yesterday suddenly select
>> few of them couldn't reach the SIP provider's network from our
>> network.
>>
>> I could traceroute to the SIP providers server from the affected
>> clients' IP just fine. ?I confirmed that the SIP traffic was leaving
>> our network out the interface to the upstream provider and the SIP
>> provider says they couldn't see the SIP traffic come into their border
>> router.
>>
>> SIP traffic coming from SIP provider to the affected customer came
>> through fine. ?It's just Us -> SIP server was a problem.
>>
>> I thought there may be some strange BGP issue going on but we had
>> other customers within the same /24 as the affected customers and they
>> were connecting fine.
>>
>> The traffic at the time traversed
>>
>> Our network -> Qwest/century link -> Level 3 -> SIP provider
>>
>> I changed the routing around so it would go through our other
>> upstream, AT&T, and it started working. ?With AT&T, the route was
>>
>> Our network -> AT&T -> Level 3 -> SIP provider
>>
>> So my questions is, is it possible there is some kind of filter at
>> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
>> few IPs? ?That's the only explanation I can come up with other than
>> the whole Juniper BGP issue 2 days ago left something in between in a
>> strange state? ?I read the post about XO doing filtering on transit
>> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
>>
>
>
>


From leo.vegoda at icann.org  Wed Nov  9 13:08:44 2011
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Wed, 9 Nov 2011 11:08:44 -0800
Subject: Performance Issues - PTR Records
In-Reply-To: <20111108122731.DF12116E2475@drugs.dv.isc.org>
References: <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no>
 <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl>
 <20111108110512.72E8116E19F7@drugs.dv.isc.org> <4EB90EF2.3030100@unfix.org>
 <20111108122731.DF12116E2475@drugs.dv.isc.org>
Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D4BE8@EXVPMBX100-1.exc.icann.org>

Mark Andrew wrote:

[...]

> > That said though the PTR->forward->PTR check is a proper check and a
> > really great way to figure out if the source SMTP host was actually set
> > up with at least some admin doing it the right way. If they can't be
> > bothered to set that up, why should you bother to accept that mail, or a
> > better choice, just score it a bit negatively at least.
> 
> Which only works as a filter because ISP's decided to prevent home
> users from putting valid PTR records in the DNS for their own
> machines.  It has nothing to do with clue or knowlege.  

Some do but some don't. I seem to remember a very nice little web interface for setting reverse DNS when I used xs4all's service in the Netherlands. 

Regards,

Leo


From sean at seanharlow.info  Wed Nov  9 13:13:49 2011
From: sean at seanharlow.info (Sean Harlow)
Date: Wed, 9 Nov 2011 14:13:49 -0500
Subject: Anyone seen this kind of problem? SIP traffic not getting to
 destination but traceroute does
In-Reply-To: <B24A2F7EC1495447B32D350F6B4DF63802729A3BDC5E@EXVMBX017-1.exch017.msoutlookonline.net>
References: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
 <1A009F7C-6D9C-4CD4-9206-3027D4ADEB70@seanharlow.info>
 <B24A2F7EC1495447B32D350F6B4DF63802729A3BDC5E@EXVMBX017-1.exch017.msoutlookonline.net>
Message-ID: <AE201A8B-A4F8-4704-9796-D03026F8138A@seanharlow.info>

I saw the problems starting around 09:30 Eastern and continuing past 17:00.  Looking through ticket notes I had missed when writing my previous reply it seems that a fix was confirmed around 22:30 which involved a faulty piece of equipment being replaced.  I do not have specifics on what went wrong and when it was actually fixed though.
----------
Sean Harlow
sean at seanharlow.info

On Nov 9, 2011, at 2:04 PM, Preston Parcell wrote:

> What was the timeframe for your issues? Just curious since we saw some strangeness last night.
> 
> 
> Preston 
> 
> 
> 
> -----Original Message-----
> From: Sean Harlow [mailto:sean at seanharlow.info] 
> Sent: Wednesday, November 09, 2011 12:00 PM
> To: Jay Nakamura
> Cc: NANOG
> Subject: Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does
> 
> I can't say I have a specific answer to your question, but yesterday I was seeing major packet loss on outbound audio from all my VoIP customers using Qwest and going in to servers on L3.  It's entirely possible that SIP was also being lost, just the audio was the more notable and pressing issue.  It seems to be resolved at this point, but we have not yet heard from Qwest what the actual problem was.
> 
> This was with sites in Northeast Ohio and the Chicago area connecting to servers in New York and LA for what it's worth.
> ----------
> Sean Harlow
> sean at seanharlow.info
> 
> On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote:
> 
>> We ran into a strange situation yesterday that I am still trying to 
>> figure out.  We have many VoIP customers but yesterday suddenly select 
>> few of them couldn't reach the SIP provider's network from our 
>> network.
>> 
>> I could traceroute to the SIP providers server from the affected 
>> clients' IP just fine.  I confirmed that the SIP traffic was leaving 
>> our network out the interface to the upstream provider and the SIP 
>> provider says they couldn't see the SIP traffic come into their border 
>> router.
>> 
>> SIP traffic coming from SIP provider to the affected customer came 
>> through fine.  It's just Us -> SIP server was a problem.
>> 
>> I thought there may be some strange BGP issue going on but we had 
>> other customers within the same /24 as the affected customers and they 
>> were connecting fine.
>> 
>> The traffic at the time traversed
>> 
>> Our network -> Qwest/century link -> Level 3 -> SIP provider
>> 
>> I changed the routing around so it would go through our other 
>> upstream, AT&T, and it started working.  With AT&T, the route was
>> 
>> Our network -> AT&T -> Level 3 -> SIP provider
>> 
>> So my questions is, is it possible there is some kind of filter at 
>> Qwest or Level 3 that is dropping traffic only for udp 5060 for select 
>> few IPs?  That's the only explanation I can come up with other than 
>> the whole Juniper BGP issue 2 days ago left something in between in a 
>> strange state?  I read the post about XO doing filtering on transit 
>> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
>> 
> 
> 



From listas at esds.com.br  Wed Nov  9 13:18:12 2011
From: listas at esds.com.br (Eduardo Schoedler)
Date: Wed, 9 Nov 2011 17:18:12 -0200
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50BA68A49@ltiserver.lti.local>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <4EB9BC04.5010103@gmail.com>
 <13175F96BDC3B34AB1425BAE905B3CE50BA68A49@ltiserver.lti.local>
Message-ID: <8C123BAE-CAE5-457B-8838-4828AA1D7AF6@esds.com.br>

How about Endian Firewalls ?

--
Eduardo Schoedler
Sent via iPhone


Em 09/11/2011, ?s 16:16, "Dennis Burgess" <dmburgess at linktechs.net> escreveu:

> Another alternative is RouterOS/MikroTik.  Plenty of high end solutions
> and low end.   
> 
> -----------------------------------------------------------
> Dennis Burgess, Mikrotik Certified Trainer 
> Link Technologies, Inc -- Mikrotik & WISP Support Services
> Office: 314-735-0270 Website: http://www.linktechs.net
> LIVE On-Line Mikrotik Training - Author of "Learn RouterOS"
> 
>> -----Original Message-----
>> From: -Hammer- [mailto:bhmccie at gmail.com]
>> Sent: Tuesday, November 08, 2011 5:32 PM
>> To: nanog at nanog.org
>> Subject: Re: Firewalls - Ease of Use and Maintenance?
>> 
>> You've worked with all the big dogs. What are you looking for?
>> Alternative options?
>> 
>> -Hammer-
>> 
>> "I was a normal American nerd"
>> -Jack Herer
>> 
>> 
>> 
>> On 11/08/2011 05:06 PM, Jones, Barry wrote:
>>> Hello all.
>>> I am potentially looking at firewall products and wanted suggestions
> as to
>> the easiest firewalls to install, configure and maintain? I have a few
> small
>> networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at
> another.
>> I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia),
> and
>> each have strong and not as strong features for ease of use. Like
> everyone,
>> I'm resource challenged and need an easy solution to stand up and
> operate.
>>> 
>>> Feel free to ping me offline - and thank you for the assistance.
>>> 
>>> ----------------------------------------
>>> Barry Jones - CISSP GSNA
>>> Project Manager II
>>> Sempra Energy Utilities
>>> (760) 271-6822
>>> 
>>> P please don't print this e-mail unless you really need to.
>>> ----------------------------------------
>>> 
>>> 
> 


From owen at impulse.net  Wed Nov  9 13:21:09 2011
From: owen at impulse.net (Owen Roth)
Date: Wed, 9 Nov 2011 11:21:09 -0800 (PST)
Subject: Anyone seen this kind of problem? SIP traffic not getting to
 destination but traceroute does
In-Reply-To: <B24A2F7EC1495447B32D350F6B4DF63802729A3BDC5E@EXVMBX017-1.exch017.msoutlookonline.net>
Message-ID: <1043806173.408651.1320866469574.JavaMail.root@lavender.impulse.net>

Yes!

Yesterday, from 9AM-10AM PST, I had a Qwest client transiting Level3 where traceroutes were working, but sip registrations were not. They were leaving fine, but not being received on the destination side. 

Then at 10AM-2PM PST, same client, registrations and invites were now working, but "180 RINGING" was being eaten. Things worked fully at 2PM. We only contacted Level3, and they didn't see any issues at around 1:45PM PST.

Regards,
Owen

----- Original Message -----
From: "Preston Parcell" <preston.parcell at viawest.com>
To: "Sean Harlow" <sean at seanharlow.info>, "Jay Nakamura" <zeusdadog at gmail.com>
Cc: "NANOG" <nanog at nanog.org>
Sent: Wednesday, November 9, 2011 11:04:01 AM
Subject: RE: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

What was the timeframe for your issues? Just curious since we saw some strangeness last night.


Preston 



-----Original Message-----
From: Sean Harlow [mailto:sean at seanharlow.info] 
Sent: Wednesday, November 09, 2011 12:00 PM
To: Jay Nakamura
Cc: NANOG
Subject: Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

I can't say I have a specific answer to your question, but yesterday I was seeing major packet loss on outbound audio from all my VoIP customers using Qwest and going in to servers on L3.  It's entirely possible that SIP was also being lost, just the audio was the more notable and pressing issue.  It seems to be resolved at this point, but we have not yet heard from Qwest what the actual problem was.

This was with sites in Northeast Ohio and the Chicago area connecting to servers in New York and LA for what it's worth.
----------
Sean Harlow
sean at seanharlow.info

On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote:

> We ran into a strange situation yesterday that I am still trying to 
> figure out.  We have many VoIP customers but yesterday suddenly select 
> few of them couldn't reach the SIP provider's network from our 
> network.
> 
> I could traceroute to the SIP providers server from the affected 
> clients' IP just fine.  I confirmed that the SIP traffic was leaving 
> our network out the interface to the upstream provider and the SIP 
> provider says they couldn't see the SIP traffic come into their border 
> router.
> 
> SIP traffic coming from SIP provider to the affected customer came 
> through fine.  It's just Us -> SIP server was a problem.
> 
> I thought there may be some strange BGP issue going on but we had 
> other customers within the same /24 as the affected customers and they 
> were connecting fine.
> 
> The traffic at the time traversed
> 
> Our network -> Qwest/century link -> Level 3 -> SIP provider
> 
> I changed the routing around so it would go through our other 
> upstream, AT&T, and it started working.  With AT&T, the route was
> 
> Our network -> AT&T -> Level 3 -> SIP provider
> 
> So my questions is, is it possible there is some kind of filter at 
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select 
> few IPs?  That's the only explanation I can come up with other than 
> the whole Juniper BGP issue 2 days ago left something in between in a 
> strange state?  I read the post about XO doing filtering on transit 
> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
> 





From jgreco at ns.sol.net  Wed Nov  9 13:36:02 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Wed, 9 Nov 2011 13:36:02 -0600 (CST)
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <9283.1320863383@turing-police.cc.vt.edu>
Message-ID: <201111091936.pA9Ja2Di085657@aurora.sol.net>

> On Wed, 09 Nov 2011 08:00:01 CST, Joe Greco said:
> > > On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:
> > > > An important feature lacking for now as far as I know is content/web
> > > > filtering especially for corporates wishing to block
> > > > inappropriate/time wasting content like facebook. 
> 
> > > 1. That's not a firewall function.  That's a censorship function.
> 
> > Is it "censorship" not to want unwanted connection attempts to our
> > gear, and block unsolicited TCP connections inbound?
> 
> > Is it "censorship" not to want unwanted exploit attempts to our
> > gear, and run everything through ClamAV, and use blocklists to
> > prevent users inadvertently pulling content from known malware sites?
> 
> I do believe that Alex was saying "blocking outbound access to time wasters
> like Facebook" is a censorship function, not a firewall function.

Of course he was.

My point is that that's irrelevant. 

There are plenty of good policy reasons for wanting to block application 
layer stuff.  The statement Alex made appeared to characterize blocking 
facebook as a "bad policy".  As a result, one might infer that Alex's 
conclusion is that "firewalls shouldn't do this type of blocking."

The merits of policies such as "blocking facebook" are largely beyond
the scope of NANOG; I don't propose to debate that point.  There are
other forums to debate such censorship.

However, the point I made should be easily understood:  a firewall that
offers tools to prevent users from visiting a certain website (via URL,
let's say) is really not any different than a firewall that offers tools
to prevent users from visiting a certain website (via packet firewall
rules, let's say).  Do you really want your users connecting to websites
known to be operated by RBN, or virus infected stuff, or spyware?  The
difference between "we want to protect our gear against known harmful
sites" and "we want to block our employees from visiting dating sites"
is probably indistinguishable at a technical implementation level.

So, in clearer response to Alex: who cares?  That's not a NANOG issue.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From jsw at inconcepts.biz  Wed Nov  9 13:45:49 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Wed, 9 Nov 2011 14:45:49 -0500
Subject: Anyone seen this kind of problem? SIP traffic not getting to
 destination but traceroute does
In-Reply-To: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
References: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
Message-ID: <CAPWAtbJGmc2oKUbHxJF-EHNZ0Y+xa_scp_1BGrZdykHVG8vdhA@mail.gmail.com>

On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura <zeusdadog at gmail.com> wrote:
> So my questions is, is it possible there is some kind of filter at
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
> few IPs? ?That's the only explanation I can come up with other than

I ran into exactly this problem last week with Rogers.  All traffic
from the client except udp/5060 could be received by us, and udp/5060
was blocked.  We tested other IP addresses on our (provider) side and
did not find any blocking there, so we assigned a new IP to the SIP
gateway.  I hardly think this can be an ordinary malfunction, but good
luck getting a phone company to troubleshoot a problem with their
subscribers using mobile data to connect to a third-party voice
gateway...

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From nick at foobar.org  Wed Nov  9 14:44:30 2011
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 09 Nov 2011 20:44:30 +0000
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <alpine.DEB.2.02.1111091405410.4911@sisler>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org> <alpine.DEB.2.02.1111091405410.4911@sisler>
Message-ID: <4EBAE62E.5090706@foobar.org>

On 09/11/2011 19:07, C. Jon Larsen wrote:
> put the main portion of the conf in subversion as an include file and
> factor out local differences in the configs with macros that are defined in
> pf.conf
>
> Easy.

As I said, it's not a pf problem.  Commercial firewalls will do all this 
sort of thing off the shelf.  It's a pain to have to write scripts to do 
this manually.

Nick


From jra at baylink.com  Wed Nov  9 14:45:48 2011
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 9 Nov 2011 15:45:48 -0500 (EST)
Subject: Anyone seen this kind of problem? SIP traffic not getting to
 destination but traceroute does
In-Reply-To: <CAPWAtbJGmc2oKUbHxJF-EHNZ0Y+xa_scp_1BGrZdykHVG8vdhA@mail.gmail.com>
Message-ID: <7566167.2223.1320871548262.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jeff Wheeler" <jsw at inconcepts.biz>

> On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura <zeusdadog at gmail.com>
> wrote:
> > So my questions is, is it possible there is some kind of filter at
> > Qwest or Level 3 that is dropping traffic only for udp 5060 for select
> > few IPs? That's the only explanation I can come up with other than
> 
> I ran into exactly this problem last week with Rogers. All traffic
> from the client except udp/5060 could be received by us, and udp/5060
> was blocked. We tested other IP addresses on our (provider) side and
> did not find any blocking there, so we assigned a new IP to the SIP
> gateway. I hardly think this can be an ordinary malfunction, but good
> luck getting a phone company to troubleshoot a problem with their
> subscribers using mobile data to connect to a third-party voice
> gateway...

Well, just a couple of days ago, we discussed that XO does this kind of 
rifle-bullet filtering in certain circumstances; is any party getting their
connectivity from them?

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From jared at puck.nether.net  Wed Nov  9 15:39:08 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 9 Nov 2011 16:39:08 -0500
Subject: Anyone seen this kind of problem? SIP traffic not getting to
 destination but traceroute does
In-Reply-To: <CAPWAtbJGmc2oKUbHxJF-EHNZ0Y+xa_scp_1BGrZdykHVG8vdhA@mail.gmail.com>
References: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
 <CAPWAtbJGmc2oKUbHxJF-EHNZ0Y+xa_scp_1BGrZdykHVG8vdhA@mail.gmail.com>
Message-ID: <12F5AF54-DD9E-414F-8142-A055C4E405CF@puck.nether.net>


On Nov 9, 2011, at 2:45 PM, Jeff Wheeler wrote:

> On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura <zeusdadog at gmail.com> wrote:
>> So my questions is, is it possible there is some kind of filter at
>> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
>> few IPs?  That's the only explanation I can come up with other than
> 
> I ran into exactly this problem last week with Rogers.  All traffic
> from the client except udp/5060 could be received by us, and udp/5060
> was blocked.  We tested other IP addresses on our (provider) side and
> did not find any blocking there, so we assigned a new IP to the SIP
> gateway.  I hardly think this can be an ordinary malfunction, but good
> luck getting a phone company to troubleshoot a problem with their
> subscribers using mobile data to connect to a third-party voice
> gateway?

I've seen UDP/5060 be intercepted or blocked by various providers.  This
is common in international markets.  If you are doing VoIP over the public
internet, it may be worthwhile to invest in software or hardware that
can VPN either 'back' or 'out' to the internet.  I have a PPTP VPN
solution I use to escape various hotel networks.  You can even do an
install on a Linux box with the poptop/pptpd solution.  (Having a
ssh server on tcp/80 and tcp/443 also can help, and is part of 'being
prepared').

- Jared

From owen at delong.com  Wed Nov  9 15:59:33 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 9 Nov 2011 13:59:33 -0800
Subject: Comcast IPv6 Update
In-Reply-To: <CAE0193F.1ABFE6%john_brzozowski@cable.comcast.com>
References: <CAE0193F.1ABFE6%john_brzozowski@cable.comcast.com>
Message-ID: <46051B98-2CD0-4DAD-9CD3-ABD6D6C97079@delong.com>

This is excellent news, John and I encourage you and the folks at Comcast
to keep up the good work.

I wait with baited breath for the day I can move my business class connection
to IPv6.

Owen

On Nov 9, 2011, at 8:54 AM, Brzozowski, John wrote:

> This is not all we are pursuing, it is part of our incremental enablement
> and deployment.  We have a non-trivial population of users that are
> directly connected versus using a home router.  If you notice we also
> mention that we will soon be sharing information about customer home
> gateway plans.
> 
> Stay tuned.
> 
> John
> =========================================
> John Jason Brzozowski
> Comcast Cable
> e) mailto:john_brzozowski at cable.comcast.com
> o) 609-377-6594
> m) 484-962-0060
> w) http://www.comcast6.net
> =========================================
> 
> 
> 
> 
> On 11/9/11 11:47 AM, "Steve Clark" <sclark at netwolves.com> wrote:
> 
>> 
>> 
>> 
>>   On 11/09/2011 11:40 AM, Jeroen Massar wrote:
>> 
>>     On 2011-11-09 17:32 , Brzozowski, John wrote:
>> 
>> 
>>       Update from http://www.comcast6.net
>> IPv6 Pilot Market Deployment Begins
>> Wednesday, November 9, 2011
>> 
>> Comcast has started our first pilot market deployment of IPv6...
>> 
>> 
>> 
>>     Congrats! One step closer to full deployment!
>> 
>> Greets,
>> Jeroen
>> 
>> 
>> 
>> 
>>   Sort of interesting that you are only
>>     handing out a single address and not a prefix  - which seems
>>     contradictory
>>     to all recommended practices.
>> 
>>     Will this be a continued effort for ISP's to charge for extra
>>     routable addresses?
>> 
>>     My $.02
>> 
>> 
>> 
>> 
>>   -- 
>>     Stephen Clark
>>     NetWolves
>>     Sr. Software Engineer III
>>     Phone: 813-579-3200
>>     Fax: 813-882-0209
>>     Email: steve.clark at netwolves.com
>>     http://www.netwolves.com
>> 
>> 
>> 
> 



From marka at isc.org  Wed Nov  9 16:07:10 2011
From: marka at isc.org (Mark Andrews)
Date: Thu, 10 Nov 2011 09:07:10 +1100
Subject: Performance Issues - PTR Records
In-Reply-To: Your message of "Wed, 09 Nov 2011 11:08:44 -0800."
 <41F6C547EA49EC46B4EE1EB2BC2F341849F82D4BE8@EXVPMBX100-1.exc.icann.org>
References: <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>
 <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no>
 <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl>
 <20111108110512.72E8116E19F7@drugs.dv.isc.org> <4EB90EF2.3030100@unfix.org>
 <20111108122731.DF12116E2475@drugs.dv.isc.org>
 <41F6C547EA49EC46B4EE1EB2BC2F341849F82D4BE8@EXVPMBX100-1.exc.icann.org>
Message-ID: <20111109220710.79A4E16F9754@drugs.dv.isc.org>


In message <41F6C547EA49EC46B4EE1EB2BC2F341849F82D4BE8 at EXVPMBX100-1.exc.icann.o
rg>, Leo Vegoda writes:
> Mark Andrew wrote:
> 
> [...]
> 
> > > That said though the PTR->forward->PTR check is a proper check and a
> > > really great way to figure out if the source SMTP host was actually set
> > > up with at least some admin doing it the right way. If they can't be
> > > bothered to set that up, why should you bother to accept that mail, or =
> a
> > > better choice, just score it a bit negatively at least.
> >=20
> > Which only works as a filter because ISP's decided to prevent home
> > users from putting valid PTR records in the DNS for their own
> > machines.  It has nothing to do with clue or knowlege. =20
> 
> Some do but some don't. I seem to remember a very nice little web interface=
> for setting reverse DNS when I used xs4all's service in the Netherlands.=20
> 
> Regards,
> 
> Leo

But many do.  As I said the ability to set up PTR records has
*nothing* to do with the clue level of the administrator.  It has
everything to do with what the ISP will let you do.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From jared at puck.nether.net  Wed Nov  9 16:24:00 2011
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 9 Nov 2011 17:24:00 -0500
Subject: Comcast IPv6 Update
In-Reply-To: <CAE01AF8.41C4C%jason_livingood@cable.comcast.com>
References: <CAE01AF8.41C4C%jason_livingood@cable.comcast.com>
Message-ID: <000E444E-DD72-4DB8-AB1E-2EB8AF14B8A0@puck.nether.net>


On Nov 9, 2011, at 11:58 AM, Livingood, Jason wrote:

> On 11/9/11 11:54 AM, "Blake T. Pfankuch" <blake at pfankuch.me> wrote:
> 
> 
>> This appears directed at the Home market.  Any word on the Business Class
>> market even as a /128?
> 
> Business Class is coming later. It won't hurt to contact the Business
> Class sales number and ask about IPv6 (and tell them to escalate it) - it
> all helps get us internal support and buy in. It is definitely on our
> radar though. 


Thanks!

I have been telling everyone to ask each time they phone in.  I suspect
there's a non-trivial number of people in this community alone that could
call in for IPv6 on the business service, even if it is just a /64 for
starters :)

(That is all I would want myself).

I'm grateful you are communicating with the community on your efforts.

- Jared


From blake at ispn.net  Wed Nov  9 16:32:39 2011
From: blake at ispn.net (Blake Hudson)
Date: Wed, 09 Nov 2011 16:32:39 -0600
Subject: Performance Issues - PTR Records
In-Reply-To: <4EB2D3B4.7060700@merit.edu>
References: <CAKP=495duD9tyeiTwDh0XHEmAeUSgtheGF3CMhyOK7xvfD6UZA@mail.gmail.com>
 <4EB2D3B4.7060700@merit.edu>
Message-ID: <4EBAFF87.8080409@ispn.net>



Larry Blunk wrote the following on 11/3/2011 12:47 PM:
> On 11/02/2011 05:57 PM, Matt Chung wrote:
>> I work for a regional ISP and very recently there has been an influx of
>> calls reporting "slowness" when accessing certain websites (i.e
>> google.com/voice/b) via HTTP.  After performing a tcpdump and 
>> analyzing the
>> session, I have been able to pinpoint the latency at the application
>> layer.  After the tcp session has been established, it takes up to 15-20
>> seconds before the application begins sending data.   The root of the
>> problem was that the PTR record for our customer(s) address does not
>> exist.  As soon as the record is created, latency from the 
>> application is
>> eliminated.  This is analogous to latency when accessing a server 
>> over SSH
>> when no PTR is available.
>>
>> A seperate packet capture from another customer exhibiting similar
>> performance behavior showed many TCP retransmissions.  At first 
>> glance, I
>> assumed this was network related however this correlates with the
>> application not responding and inducing retransmissions at the TCP layer
>> (different symptoms, same problem).
>>
>> Historically, there was no compelling reason to create PTR records 
>> for our
>> CPE however more and more applications seem to be dependent on it.
>> Although we will be assigning a record for each address, my question 
>> is why
>> is the application (specifically HTTP) dependent on a reverse record ?
>> What is the purpose?
>>
>> Hope this is helpful as well
>>
>
>   We recently encountered a similar issue with a customer.
> The sites that had slowness issues were configured to
> use the traditional Google Analytics javascript instead
> of the newer asynchronous code.
>   The problem was not the lack of a PTR record, but rather
> the in-addr delegation was pointing to lame servers that were
> no longer responding (hence the long timeouts as the
> Google servers attempted to perform reverse lookups
> on the client IP's).  As others have pointed out, as long
> as there's a valid nameserver responding, a lack of PTR
> record would not cause issues as an NXDOMAIN record would
> be sent back immediately and the Google Analytics server
> will move on.
>
>
>  -Larry Blunk
>   Merit

Larry, you're absolutely correct. One has to wonder what the continued 
debate is about. The Op likely had a DNS loop, misconfiguration, or lame 
servers. Correcting that issue should resolve any "slowness". The issue 
then is whether the application requires a valid PTR (or subsequent 
matching forward record) such as SMTP.

BTW, ARIN requires valid IN-ADDR.ARPA domain records. The specific 
record may be NXDOMAIN (non-existant), but the server cannot be lame - 
https://www.arin.net/policy/nrpm.html#seven1
I believe just about all of us on this list have agreed to this policy. 
However, my experience tells me that many people choose to ignore it. 
This thread is evidence of such.

--Blake


From blake at ispn.net  Wed Nov  9 16:45:15 2011
From: blake at ispn.net (Blake Hudson)
Date: Wed, 09 Nov 2011 16:45:15 -0600
Subject: Anyone seen this kind of problem? SIP traffic not getting to
 destination but traceroute does
In-Reply-To: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
References: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
Message-ID: <4EBB027B.8010306@ispn.net>


Jay Nakamura wrote the following on 11/9/2011 12:47 PM:
> We ran into a strange situation yesterday that I am still trying to
> figure out.  We have many VoIP customers but yesterday suddenly select
> few of them couldn't reach the SIP provider's network from our
> network.
>
> I could traceroute to the SIP providers server from the affected
> clients' IP just fine.  I confirmed that the SIP traffic was leaving
> our network out the interface to the upstream provider and the SIP
> provider says they couldn't see the SIP traffic come into their border
> router.
>
> ...
> So my questions is, is it possible there is some kind of filter at
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
> few IPs?  That's the only explanation I can come up with other than
> the whole Juniper BGP issue 2 days ago left something in between in a
> strange state?  I read the post about XO doing filtering on transit
> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
>

I've found tools like tcptraceroute (the name is deceiving, UDP is the 
default) and hping to be invaluable in tracking down issues like these 
that are obviously above the routing and into the transport layer.

I'm not sure how an IP transit provider (who should be providing 
routing/switching) screws up transport layer connections - looks like 
they are arbitrarily "managing" client data. Just my $0.02.

--Blake


From paul at paulgraydon.co.uk  Wed Nov  9 16:59:19 2011
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Wed, 09 Nov 2011 12:59:19 -1000
Subject: Comcast IPv6 Update
In-Reply-To: <CAE01557.1ABFB9%john_brzozowski@cable.comcast.com>
References: <CAE01557.1ABFB9%john_brzozowski@cable.comcast.com>
Message-ID: <4EBB05C7.2050201@paulgraydon.co.uk>

On 11/09/2011 06:32 AM, Brzozowski, John wrote:
> Update from http://www.comcast6.net
> IPv6 Pilot Market Deployment Begins
> Wednesday, November 9, 2011
>
> Comcast has started our first pilot market deployment of IPv6 in limited areas of California and Colorado. This first phase supports directly connected CPE, where a single computer is directly connected to a cable device. A subsequent phase will support home gateway devices. To learn more, check out FAQs on the pilot market deployment<http://www.comcast6.net/pilotfaq.php>  and the announcement<http://blog.comcast.com/2011/11/ipv6-deployment.html>  and technical details<http://blog.comcast.com/2011/11/ipv6-deployment-technology.html>  on our blog.
>
> John
>
Good to hear, thanks John.  Hopefully Comcast's marketing/sales team can 
run productively with this.  It might start to encourage some of the 
other major and minor ISPs to jump on board.

Paul


From mulitskiy at acedsl.com  Wed Nov  9 17:20:29 2011
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Wed, 9 Nov 2011 18:20:29 -0500
Subject: Anyone seen this kind of problem? SIP traffic not getting to
 destination but traceroute does
In-Reply-To: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
References: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
Message-ID: <201111091820.29199.mulitskiy@acedsl.com>

It may also be related to QoS policy inside the carriers.
Some time ago I've seen exactly the same symptoms with Verizon when sip signaling
was sent marked as EF. Remarking it down to CS1 or CS3 (don't remember exactly) solved the problem.

Michael

On Wednesday 09 November 2011 13:47:37 Jay Nakamura wrote:
> We ran into a strange situation yesterday that I am still trying to
> figure out.  We have many VoIP customers but yesterday suddenly select
> few of them couldn't reach the SIP provider's network from our
> network.
> 
> I could traceroute to the SIP providers server from the affected
> clients' IP just fine.  I confirmed that the SIP traffic was leaving
> our network out the interface to the upstream provider and the SIP
> provider says they couldn't see the SIP traffic come into their border
> router.
> 
> SIP traffic coming from SIP provider to the affected customer came
> through fine.  It's just Us -> SIP server was a problem.
> 
> I thought there may be some strange BGP issue going on but we had
> other customers within the same /24 as the affected customers and they
> were connecting fine.
> 
> The traffic at the time traversed
> 
> Our network -> Qwest/century link -> Level 3 -> SIP provider
> 
> I changed the routing around so it would go through our other
> upstream, AT&T, and it started working.  With AT&T, the route was
> 
> Our network -> AT&T -> Level 3 -> SIP provider
> 
> So my questions is, is it possible there is some kind of filter at
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
> few IPs?  That's the only explanation I can come up with other than
> the whole Juniper BGP issue 2 days ago left something in between in a
> strange state?  I read the post about XO doing filtering on transit
> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
> 
> 


From jimb at jsbc.cc  Wed Nov  9 18:25:12 2011
From: jimb at jsbc.cc (Jim Burwell)
Date: Wed, 09 Nov 2011 16:25:12 -0800
Subject: Comcast IPv6 Update
In-Reply-To: <CAE01AF8.41C4C%jason_livingood@cable.comcast.com>
References: <CAE01AF8.41C4C%jason_livingood@cable.comcast.com>
Message-ID: <4EBB19E8.6080307@jsbc.cc>

On 11/9/2011 08:58, Livingood, Jason wrote:
> On 11/9/11 11:54 AM, "Blake T. Pfankuch"<blake at pfankuch.me>  wrote:
>
>
>> This appears directed at the Home market.  Any word on the Business Class
>> market even as a /128?
> Business Class is coming later. It won't hurt to contact the Business
> Class sales number and ask about IPv6 (and tell them to escalate it) - it
> all helps get us internal support and buy in. It is definitely on our
> radar though.
>
> - Jason
>
>
Yeh.  I've been waiting since before the trial started for biz class 
IPv6.  I even read some article on one of the Comcast sites (IIRC) that 
one of their business class customers was doing NDS.  I guess it was a 
one-off.  :)




From zeusdadog at gmail.com  Wed Nov  9 21:33:44 2011
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Wed, 9 Nov 2011 22:33:44 -0500
Subject: Anyone seen this kind of problem? SIP traffic not getting to
 destination but traceroute does
In-Reply-To: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
References: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
Message-ID: <CADs2+OG_De6KxKEPUefiXj0Hs3sL4Yv-DkwYQb3oLpaJOD8AwA@mail.gmail.com>

I just removed the route to our other provider and traffic is going
out Qwest again. The problem seems to be gone now.  As others had
similar problems during the same period using Qwest, it must have been
some strange issue with Qwest.

On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura <zeusdadog at gmail.com> wrote:
> We ran into a strange situation yesterday that I am still trying to
> figure out. ?We have many VoIP customers but yesterday suddenly select
> few of them couldn't reach the SIP provider's network from our
> network.
>
> I could traceroute to the SIP providers server from the affected
> clients' IP just fine. ?I confirmed that the SIP traffic was leaving
> our network out the interface to the upstream provider and the SIP
> provider says they couldn't see the SIP traffic come into their border
> router.
>
> SIP traffic coming from SIP provider to the affected customer came
> through fine. ?It's just Us -> SIP server was a problem.
>
> I thought there may be some strange BGP issue going on but we had
> other customers within the same /24 as the affected customers and they
> were connecting fine.
>
> The traffic at the time traversed
>
> Our network -> Qwest/century link -> Level 3 -> SIP provider
>
> I changed the routing around so it would go through our other
> upstream, AT&T, and it started working. ?With AT&T, the route was
>
> Our network -> AT&T -> Level 3 -> SIP provider
>
> So my questions is, is it possible there is some kind of filter at
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
> few IPs? ?That's the only explanation I can come up with other than
> the whole Juniper BGP issue 2 days ago left something in between in a
> strange state? ?I read the post about XO doing filtering on transit
> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
>


From jbates at brightok.net  Wed Nov  9 23:41:39 2011
From: jbates at brightok.net (Jack Bates)
Date: Wed, 09 Nov 2011 23:41:39 -0600
Subject: Anyone seen this kind of problem? SIP traffic not getting to
 destination but traceroute does
In-Reply-To: <4EBB027B.8010306@ispn.net>
References: <CADs2+OE2VDVE_RaGE5R+=obYguHj0s8v4LokOhv7Bu0ayEbwXg@mail.gmail.com>
 <4EBB027B.8010306@ispn.net>
Message-ID: <4EBB6413.9060509@brightok.net>

On 11/9/2011 4:45 PM, Blake Hudson wrote:
> I'm not sure how an IP transit provider (who should be providing 
> routing/switching) screws up transport layer connections - looks like 
> they are arbitrarily "managing" client data. Just my $0.02. 

With today's routers, all sorts of weird things can go wrong, especially 
if it's a hardware failure.

I had an IO/FE go out on a 7200 (which is as software as you get) which 
attributed to a lot of weirdness. It started when the IGP updated state 
information on the IO card's FE, which shut down mpls switching on the 
router, but the LSP itself was still considered up. It then showed by 
freaking out the neighbor 7206 when we reboot the failing one (could no 
longer ping the loopback of the neighbor router with and without using 
the LSP, but all IGP was up and you could ping/telnet/ssh to any other 
IP ). Finally the  reboot itself showed the true issue (required 
multiple power cycles and a reset of the ata card to even load IOS in an 
unstable state).

I don't even want to think what happens when a high end router's 
linecard starts to fail.


Jack


From randy at psg.com  Thu Nov 10 00:01:07 2011
From: randy at psg.com (Randy Bush)
Date: Thu, 10 Nov 2011 07:01:07 +0100
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <20111109155633.GA21891@ussenterprise.ufp.org>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org>
Message-ID: <m2sjlwqzx8.wl%randy@psg.com>

> 1) The concept of Inter-RIR transfers is a bad idea.  Insuring
>    "compatible" rules between RIR's will always be difficult at
>    best.

no need to coordinate rules/policies at all.  what we suggested in a/p
three years back was simple.  seller must abide by seller's local
selling policy and buyer must abide by buyer's local receiving policy.

randy


From lasse at sdu.dk  Thu Nov 10 02:56:51 2011
From: lasse at sdu.dk (Lasse Birnbaum Jensen)
Date: Thu, 10 Nov 2011 09:56:51 +0100
Subject: Encrypted RPC and firewalling
Message-ID: <2E350517-A6A8-4097-AE60-BAF2FA090877@sdu.dk>

hi all

I would like to know how you guys handle encypted rpc across firewalls. 

We utilize an ASA platform and the DCERPC inspection cant handle encrypted RPC (which is standard in most windows 2008 and default in all communication in exchange 2010). Ciscos says: disable encryption or create "allow any" rules.

Do you limit the RPC port range on the windows systems and make "holes" in the firewall for these or do you disable RPC encryption ? 

Please share your knowledge in this area.

Best regards 

Lasse Birnbaum Jensen
Network administrator, IT-Service
University of Southern Denmark

Email: lasse at sdu.dk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1927 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111110/16a9ab22/attachment.bin>

From bill at herrin.us  Thu Nov 10 06:39:15 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 10 Nov 2011 07:39:15 -0500
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <m2sjlwqzx8.wl%randy@psg.com>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
Message-ID: <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>

On Thu, Nov 10, 2011 at 1:01 AM, Randy Bush <randy at psg.com> wrote:
>> 1) The concept of Inter-RIR transfers is a bad idea. ?Insuring
>> ? ?"compatible" rules between RIR's will always be difficult at
>> ? ?best.
>
> no need to coordinate rules/policies at all. ?what we suggested in a/p
> three years back was simple. ?seller must abide by seller's local
> selling policy and buyer must abide by buyer's local receiving policy.

Randy,

Such a process creates a back-door requirement that participating
registries race to the bottom eliminating eligibility requirements for
address recipients. Failure to do so leaves their own registrants at
an unfair disadvantage when trying to get addresses. The approach is,
unfortunately, more simpleminded than it is simple.

But really this discussion belongs on the ARIN PPML where your input
would be most welcome.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From Valdis.Kletnieks at vt.edu  Thu Nov 10 06:50:39 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 10 Nov 2011 07:50:39 -0500
Subject: Encrypted RPC and firewalling
In-Reply-To: Your message of "Thu, 10 Nov 2011 09:56:51 +0100."
 <2E350517-A6A8-4097-AE60-BAF2FA090877@sdu.dk>
References: <2E350517-A6A8-4097-AE60-BAF2FA090877@sdu.dk>
Message-ID: <42850.1320929439@turing-police.cc.vt.edu>

On Thu, 10 Nov 2011 09:56:51 +0100, Lasse Birnbaum Jensen said:
> I would like to know how you guys handle encypted rpc across firewalls.

You can always just set the firewall to ban RPC in general, whether or not it's
encrypted (while you're there, close off ports 137-139 and other chucklehead
stuff like that), and just make the user who's outside the firewall VPN in.  That's
a nice, simple, well-understood configuration that almost all software and even
most users can handle.

(We don't actually do a big monolithic firewall box - but pretty much
everything has an iptables ruleset loaded that says "if your source IP isn't
inside our 2 /16s, your packets go bye bye".  And there's a nice PPTP-based VPN
solution in place that even a humanities professor emeritus can use ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111110/6ff4d403/attachment.bin>

From Valdis.Kletnieks at vt.edu  Thu Nov 10 06:50:39 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 10 Nov 2011 07:50:39 -0500
Subject: Encrypted RPC and firewalling
In-Reply-To: Your message of "Thu, 10 Nov 2011 09:56:51 +0100."
 <2E350517-A6A8-4097-AE60-BAF2FA090877@sdu.dk>
References: <2E350517-A6A8-4097-AE60-BAF2FA090877@sdu.dk>
Message-ID: <42850.1320929439@turing-police.cc.vt.edu>

On Thu, 10 Nov 2011 09:56:51 +0100, Lasse Birnbaum Jensen said:
> I would like to know how you guys handle encypted rpc across firewalls.

You can always just set the firewall to ban RPC in general, whether or not it's
encrypted (while you're there, close off ports 137-139 and other chucklehead
stuff like that), and just make the user who's outside the firewall VPN in.  That's
a nice, simple, well-understood configuration that almost all software and even
most users can handle.

(We don't actually do a big monolithic firewall box - but pretty much
everything has an iptables ruleset loaded that says "if your source IP isn't
inside our 2 /16s, your packets go bye bye".  And there's a nice PPTP-based VPN
solution in place that even a humanities professor emeritus can use ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111110/6ff4d403/attachment-0003.bin>

From Valdis.Kletnieks at vt.edu  Thu Nov 10 06:51:17 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 10 Nov 2011 07:51:17 -0500
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: Your message of "Thu, 10 Nov 2011 07:39:15 EST."
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
Message-ID: <42872.1320929477@turing-police.cc.vt.edu>

On Thu, 10 Nov 2011 07:39:15 EST, William Herrin said:
> Such a process creates a back-door requirement that participating
> registries race to the bottom eliminating eligibility requirements for
> address recipients.

When was the last time this industry turned down a chance to have
a race to the bottom?

</snark>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111110/11134287/attachment.bin>

From randy at psg.com  Thu Nov 10 07:28:50 2011
From: randy at psg.com (Randy Bush)
Date: Thu, 10 Nov 2011 14:28:50 +0100
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org>
 <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
Message-ID: <m2ty6cp0ml.wl%randy@psg.com>

>> no need to coordinate rules/policies at all. ?what we suggested in a/p
>> three years back was simple. ?seller must abide by seller's local
>> selling policy and buyer must abide by buyer's local receiving policy.
> 
> Such a process creates a back-door requirement that participating
> registries race to the bottom eliminating eligibility requirements for
> address recipients. Failure to do so leaves their own registrants at
> an unfair disadvantage when trying to get addresses.

i am sure the americans who think all address space should righfully be
theirs can dream up paranoid scenarios for anything.  but dear canute,
the tide is coming, get over it or get wet.

they do not sell enough enough anti-nausea meds here for me to read the
arin ppml list.

randy


From mysidia at gmail.com  Thu Nov 10 07:36:58 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 10 Nov 2011 07:36:58 -0600
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBAE62E.5090706@foobar.org>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org>
 <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
Message-ID: <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>

On Wed, Nov 9, 2011 at 2:44 PM, Nick Hilliard <nick at foobar.org> wrote:
> On 09/11/2011 19:07, C. Jon Larsen wrote:
> As I said, it's not a pf problem. ?Commercial firewalls will do all this
> sort of thing off the shelf. ?It's a pain to have to write scripts to do  this manually.

Ah... the high cost of  'free' products,  you have to do some
scripting, or pay another organization to support it / do scripting
work for you.  The advantage is... you _can_ do a small amount of
scripting or programming to add minor additional required
functionality.   And a very large number commercial firewalls do not
have config synchronization, except,  perhaps between a failover pair,
anyways.

Anyways...   I can see synchronizing blacklists on a firewall,   or
having a firewall configured to fetch certain 'drop' rules from a
HTTPS URL.        Otherwise:  the thought of  mass synchronization of
lots of firewalls can be bad in that it creates a single point of
system compromise;  supposing  the synchronization source  machine
were compromised,  one dirty rule inserted by an intruder followed by
a kick off of the sync mechanism,  and then actions to break
it/prevent further syncing, defeats the security of the entire
deployment....

--
-JH


From cja at daydream.com  Thu Nov 10 07:38:16 2011
From: cja at daydream.com (CJ Aronson)
Date: Thu, 10 Nov 2011 06:38:16 -0700
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <m2ty6cp0ml.wl%randy@psg.com>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org>
 <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com>
Message-ID: <CAMvf=7ZKrpfHkjX6MEX7O92s3Ch+9a-hStD85va3K9p7MC7exw@mail.gmail.com>

So Randy.. Are you in favor or opposed to 2011-1?

Thanks!
----Cathy

On Thu, Nov 10, 2011 at 6:28 AM, Randy Bush <randy at psg.com> wrote:

> >> no need to coordinate rules/policies at all.  what we suggested in a/p
> >> three years back was simple.  seller must abide by seller's local
> >> selling policy and buyer must abide by buyer's local receiving policy.
> >
> > Such a process creates a back-door requirement that participating
> > registries race to the bottom eliminating eligibility requirements for
> > address recipients. Failure to do so leaves their own registrants at
> > an unfair disadvantage when trying to get addresses.
>
> i am sure the americans who think all address space should righfully be
> theirs can dream up paranoid scenarios for anything.  but dear canute,
> the tide is coming, get over it or get wet.
>
> they do not sell enough enough anti-nausea meds here for me to read the
> arin ppml list.
>
> randy
>
>

From mhuff at ox.com  Thu Nov 10 07:38:35 2011
From: mhuff at ox.com (Matthew Huff)
Date: Thu, 10 Nov 2011 08:38:35 -0500
Subject: Encrypted RPC and firewalling
In-Reply-To: <42850.1320929439@turing-police.cc.vt.edu>
References: <2E350517-A6A8-4097-AE60-BAF2FA090877@sdu.dk>
 <42850.1320929439@turing-police.cc.vt.edu>
Message-ID: <483E6B0272B0284BA86D7596C40D29F901212962120E@PUR-EXCH07.ox.com>

Also,

Most enterprises that support Exchange remote access use RPC over HTTPS which is encrypted and easy to allow on the firewall.

----
Matthew Huff?            | 1 Manhattanville Rd
Director of Operations???| Purchase, NY 10577
OTA Management LLC       | Phone: 914-460-4039
aim: matthewbhuff?       | Fax:?? 914-460-4139


> -----Original Message-----
> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> Sent: Thursday, November 10, 2011 7:51 AM
> To: Lasse Birnbaum Jensen
> Cc: nanog at nanog.org
> Subject: Re: Encrypted RPC and firewalling
> 
> On Thu, 10 Nov 2011 09:56:51 +0100, Lasse Birnbaum Jensen said:
> > I would like to know how you guys handle encypted rpc across
> firewalls.
> 
> You can always just set the firewall to ban RPC in general, whether or
> not it's encrypted (while you're there, close off ports 137-139 and
> other chucklehead stuff like that), and just make the user who's
> outside the firewall VPN in.  That's a nice, simple, well-understood
> configuration that almost all software and even most users can handle.
> 
> (We don't actually do a big monolithic firewall box - but pretty much
> everything has an iptables ruleset loaded that says "if your source IP
> isn't inside our 2 /16s, your packets go bye bye".  And there's a nice
> PPTP-based VPN solution in place that even a humanities professor
> emeritus can use ;)



From randy at psg.com  Thu Nov 10 07:44:12 2011
From: randy at psg.com (Randy Bush)
Date: Thu, 10 Nov 2011 14:44:12 +0100
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <CAMvf=7ZKrpfHkjX6MEX7O92s3Ch+9a-hStD85va3K9p7MC7exw@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org>
 <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com>
 <CAMvf=7ZKrpfHkjX6MEX7O92s3Ch+9a-hStD85va3K9p7MC7exw@mail.gmail.com>
Message-ID: <m2pqh0ozwz.wl%randy@psg.com>

> So Randy.. Are you in favor or opposed to 2011-1?

against


From bill at herrin.us  Thu Nov 10 07:48:04 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 10 Nov 2011 08:48:04 -0500
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <m2ty6cp0ml.wl%randy@psg.com>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com>
Message-ID: <CAP-guGWNzWp4WOGTquZdua5gjLi3btsY7TXLkSi9EObVef+6Bw@mail.gmail.com>

On Thu, Nov 10, 2011 at 8:28 AM, Randy Bush <randy at psg.com> wrote:
> i am sure the americans who think all address space should righfully be
> theirs can dream up paranoid scenarios for anything. ?but dear canute,
> the tide is coming, get over it or get wet.

Randy,

You're fortunate that you speak for a minority. If you didn't, we'd
tell the bunch of you to go to hell instead of valiantly seeking to
improve the situation in which APNIC finds itself.


> they do not sell enough enough anti-nausea meds here for me to read the
> arin ppml list.

It's your privilege to make uneducated snipes from afar.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From randy at psg.com  Thu Nov 10 07:51:02 2011
From: randy at psg.com (Randy Bush)
Date: Thu, 10 Nov 2011 14:51:02 +0100
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <CAP-guGWNzWp4WOGTquZdua5gjLi3btsY7TXLkSi9EObVef+6Bw@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org>
 <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com>
 <CAP-guGWNzWp4WOGTquZdua5gjLi3btsY7TXLkSi9EObVef+6Bw@mail.gmail.com>
Message-ID: <m2obwkozll.wl%randy@psg.com>

> You're fortunate that you speak for a minority.

actually, that time has passed.  you're the minority.  there are more
non-americans than american rir members, there are more legacy holders
than arin junior vigilantes, ...

observe how the american 'global' proposal flew.

randy


From bicknell at ufp.org  Thu Nov 10 07:56:18 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 10 Nov 2011 05:56:18 -0800
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <m2ty6cp0ml.wl%randy@psg.com>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com>
Message-ID: <20111110135618.GA82609@ussenterprise.ufp.org>

In a message written on Thu, Nov 10, 2011 at 02:28:50PM +0100, Randy Bush wrote:
> i am sure the americans who think all address space should righfully be
> theirs can dream up paranoid scenarios for anything.  but dear canute,
> the tide is coming, get over it or get wet.

I believe you have made an incorrect assumption as to why some folks
are against transfers.  Quite frankly, if it made you (and the rest
of the world) happier I would support a proposal to reclaim all
unused legacy space in the ARIN region and divide 100% of it among
the other RIR's.  We'd be better off without it.

The real problem is, if people spent even 10% of the time spent
arguing over how to buy/sell/trade/swap IPv4 space deploying IPv6
space we wouldn't be havng this discussion, as no one would need
any more IPv4 space at this point since we would all be removing
it from our network.

The tide is coming.  The tide is wet.  The tide is full of IPv6 water.
Get over it.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111110/d5df168b/attachment.bin>

From randy at psg.com  Thu Nov 10 08:04:50 2011
From: randy at psg.com (Randy Bush)
Date: Thu, 10 Nov 2011 15:04:50 +0100
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <20111110135618.GA82609@ussenterprise.ufp.org>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org>
 <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com>
 <20111110135618.GA82609@ussenterprise.ufp.org>
Message-ID: <m2k478oyyl.wl%randy@psg.com>

> The real problem is, if people spent even 10% of the time spent
> arguing over how to buy/sell/trade/swap IPv4 space deploying IPv6
> space we wouldn't be havng this discussion, as no one would need
> any more IPv4 space at this point since we would all be removing
> it from our network.
> 
> The tide is coming.  The tide is wet.  The tide is full of IPv6 water.
> Get over it.

i am a measurement type.  it's a stretch to call things even slightly
damp.  not that i am happy with this.  we deployed in the '90s.

randy


From bhmccie at gmail.com  Thu Nov 10 08:52:22 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Thu, 10 Nov 2011 08:52:22 -0600
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org> <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
Message-ID: <4EBBE526.5090102@gmail.com>

The other high cost of "free" that people sometimes overlook is 
liability. Many organizations want/need someone to hold the fire to in 
the event of an issue. I believe in open source and am an advocate of 
open source computing (this email is from my Debian (NOT UBUNTU) laptop 
and my BSD workstation is right beside it), but at an organizational 
level, if I had an open source FW and a vulnerability was allowed to get 
thru it and compromise customer or confidential data, my management 
would be looking to the vendor for answers. If I told them "it's open 
source, there is no "vendor"" it would not go over well. Why? Because 
the liability is now assumed by my company. So when the customer sues 
it's on me. Or (and we see these on a regular basis) when the patent 
troll contacts us about his patent that the open source product is 
violating and wants compensation the liability stops at my company. IF I 
am using a vendor supported platform, I can take that to my vendor and 
discuss options. Many (not all) large businesses have agreements with 
vendors that go well beyond NDAs. Agreements about liability. 
Healthcare/Financial/Defense all have these kinds of agreements. I'm not 
saying it's fair. It's just how the world works. For that reason there 
are some areas where open source is smart while there are other areas (a 
firewall you depend on to protect you) where open source may put you and 
your employer at risk. You have to consider that. Or... Some of us do.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/10/2011 07:36 AM, Jimmy Hess wrote:
> On Wed, Nov 9, 2011 at 2:44 PM, Nick Hilliard<nick at foobar.org>  wrote:
>    
>> On 09/11/2011 19:07, C. Jon Larsen wrote:
>> As I said, it's not a pf problem.  Commercial firewalls will do all this
>> sort of thing off the shelf.  It's a pain to have to write scripts to do  this manually.
>>      
> Ah... the high cost of  'free' products,  you have to do some
> scripting, or pay another organization to support it / do scripting
> work for you.  The advantage is... you _can_ do a small amount of
> scripting or programming to add minor additional required
> functionality.   And a very large number commercial firewalls do not
> have config synchronization, except,  perhaps between a failover pair,
> anyways.
>
> Anyways...   I can see synchronizing blacklists on a firewall,   or
> having a firewall configured to fetch certain 'drop' rules from a
> HTTPS URL.        Otherwise:  the thought of  mass synchronization of
> lots of firewalls can be bad in that it creates a single point of
> system compromise;  supposing  the synchronization source  machine
> were compromised,  one dirty rule inserted by an intruder followed by
> a kick off of the sync mechanism,  and then actions to break
> it/prevent further syncing, defeats the security of the entire
> deployment....
>
> --
> -JH
>
>    

From rsk at gsp.org  Thu Nov 10 09:14:26 2011
From: rsk at gsp.org (Richard Kulawiec)
Date: Thu, 10 Nov 2011 10:14:26 -0500
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBBE526.5090102@gmail.com>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org>
 <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
 <4EBBE526.5090102@gmail.com>
Message-ID: <20111110151426.GA22050@gsp.org>

On Thu, Nov 10, 2011 at 08:52:22AM -0600, -Hammer- wrote:
> The other high cost of "free" that people sometimes overlook is
> liability. 

Please point to an instance (case citation, please) where a commercial
firewall vendor has been successfully litigated against -- that is, held
responsible by a court of law for a failure of their product to provide
the functionality that it's claimed to provide.

---rsk



From bhmccie at gmail.com  Thu Nov 10 09:39:29 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Thu, 10 Nov 2011 09:39:29 -0600
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <20111110151426.GA22050@gsp.org>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org> <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
 <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org>
Message-ID: <4EBBF031.4060200@gmail.com>

OK. Right off the bat you know I can't and won't. But in some places it 
is common practice to make sure agreements are in place to make sure all 
parties are protected based on how a product is expected/designed to 
perform. I can't say more than that. Realize I'm speaking about things 
that are solely on the vendor. Not "Did you configure the ACL properly?"

What you can Google is the names of companies who have settled out of 
court against various trolling lawsuits vs the names of companies that 
are still in litigation. There is a mix of both manufacturer/vendor and 
end customer. It all depends on the case.

This shouldn't surprise you. If Toyota makes a defective brake and you 
slam into someone else, your insurance covers you. Eventually, if the 
issue scales out to the point that it is obvious that Toyota made a 
defective brake and it is not your fault, some insurance companies 
collectively will go to the government or directly to the manufacturer 
for compensation. This is no different. If you sell me a FW and it 
catches on fire thru no fault of my own and then the public finds out 
that FWs are catching on fire all over the place, it's a good bet that 
that FW vendor will be getting some lawsuits. If a FW vendor reports a 
product to work a certain way and instead thru a massive vulnerability 
or development oversight it does not the same applies. Software. 
Hardware. Physical (fire). Logical (vulnerability). I'm not saying that 
it happens all the time and I'm not even saying it's a general practice. 
What I'm saying is it happens. And depending on your business vertical 
it could be a very real consideration.

COMPLETELY 100% MADE UP HYPOTHETICAL SCENARIO:

I put a FW in. I put proper L3 ACLs in. I block 443 inbound. I didn't 
say I block HTTPS. I block 443. I test it by telnetting from the 
Internet to 1.1.1.1:443 and I am unable to connect. Looks good. A month 
later our CEO is surfing the Internet. Thru a development oversight in 
the product, when I NAT or PAT him to the Internet his source port is 
not pulled from the Ephemeral range but is instead sourced as port 443. 
He of course goes to sites riddled with Malware because that's what CEOs 
do. They click on links. So the Malware website initiates a new TCP 
session to destination port 443 with his NATted IP. The state table has 
an entry for that IP and 443 and even though this is a new TCP session 
the FW lets it thru. The malware site bad guys are able to retrieve 
confidential information about a merger and publish it. The other 
company that we were merging with sues us because the information is 
leaked to the public and adversely impacted their stock value. 
Everything in the above paragraph is able to be documented thru 
forensics and it is indisputable that the FW was properly configured and 
should have blocked it but didn't. The FW did NOT perform as 
advertised/designed. This is NOT the fault of me or my company. If a few 
thousand dollars is at stake nothing may come of this. If tens or 
hundreds of millions of dollars are at stake I promise you that our 
lawyers will be contacting the manufacturer whose product did not 
perform as advertised. They will compensate (in one way or another) us 
for our losses. It's a big ugly world full of lots of lawyers.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/10/2011 09:14 AM, Richard Kulawiec wrote:
> On Thu, Nov 10, 2011 at 08:52:22AM -0600, -Hammer- wrote:
>    
>> The other high cost of "free" that people sometimes overlook is
>> liability.
>>      
> Please point to an instance (case citation, please) where a commercial
> firewall vendor has been successfully litigated against -- that is, held
> responsible by a court of law for a failure of their product to provide
> the functionality that it's claimed to provide.
>
> ---rsk
>
>
>    

From bicknell at ufp.org  Thu Nov 10 09:53:17 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 10 Nov 2011 07:53:17 -0800
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <20111110151426.GA22050@gsp.org>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org> <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
 <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org>
Message-ID: <20111110155317.GA88837@ussenterprise.ufp.org>

In a message written on Thu, Nov 10, 2011 at 10:14:26AM -0500, Richard Kulawiec wrote:
> Please point to an instance (case citation, please) where a commercial
> firewall vendor has been successfully litigated against -- that is, held
> responsible by a court of law for a failure of their product to provide
> the functionality that it's claimed to provide.

Unsuccessful litigation has costs as well.  Patent trolls have sued
end-users in a number of cases for both commerical and open source
software.  In many cases they lose, but someone still has to shell
out a pile of cash for the lawyers to defend.

Just ask folks like AutoZone or DaimlerChrysler how much it cost to use
Linux when they were sued by SCO and had to defend themselves.  Sure,
they prevailed, but I bet tens of thousands of dollars were spent on
litigation.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111110/e0ec1730/attachment.bin>

From jra at baylink.com  Thu Nov 10 09:56:25 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 10 Nov 2011 10:56:25 -0500 (EST)
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <20111110155317.GA88837@ussenterprise.ufp.org>
Message-ID: <3751311.2323.1320940585880.JavaMail.root@benjamin.baylink.com>

---- Original Message -----
> From: "Leo Bicknell" <bicknell at ufp.org>

> Just ask folks like AutoZone or DaimlerChrysler how much it cost to use
> Linux when they were sued by SCO and had to defend themselves. Sure,
> they prevailed, but I bet tens of thousands of dollars were spent on
> litigation.

Sure.  But compare that to the millions they would have spent using SCO... :-)

Cheers,
-- jra
[1]Yes, I realize AutoZone may have been paying for their Linux distro...
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From alter3d at alter3d.ca  Thu Nov 10 10:04:19 2011
From: alter3d at alter3d.ca (Peter Kristolaitis)
Date: Thu, 10 Nov 2011 11:04:19 -0500
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBBF031.4060200@gmail.com>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org> <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
 <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org>
 <4EBBF031.4060200@gmail.com>
Message-ID: <4EBBF603.1000506@alter3d.ca>

Your hypothetical scenario assumes you're the only organization 
compromised by the flaw (or one of very few), and not #3972 on the list, 
in which case the company could go bankrupt before a court can hear your 
case, and the "liability protection" they offered you is worth the 
electrons it's printed on.    It's great if you're a Fortune 50 and have 
the legal, political and financial clout to be #1 on the lawsuit list, 
but nearly worthless for most organizations.

- Peter


On 11/10/2011 10:39 AM, -Hammer- wrote:
> OK. Right off the bat you know I can't and won't. But in some places 
> it is common practice to make sure agreements are in place to make 
> sure all parties are protected based on how a product is 
> expected/designed to perform. I can't say more than that. Realize I'm 
> speaking about things that are solely on the vendor. Not "Did you 
> configure the ACL properly?"
>
> What you can Google is the names of companies who have settled out of 
> court against various trolling lawsuits vs the names of companies that 
> are still in litigation. There is a mix of both manufacturer/vendor 
> and end customer. It all depends on the case.
>
> This shouldn't surprise you. If Toyota makes a defective brake and you 
> slam into someone else, your insurance covers you. Eventually, if the 
> issue scales out to the point that it is obvious that Toyota made a 
> defective brake and it is not your fault, some insurance companies 
> collectively will go to the government or directly to the manufacturer 
> for compensation. This is no different. If you sell me a FW and it 
> catches on fire thru no fault of my own and then the public finds out 
> that FWs are catching on fire all over the place, it's a good bet that 
> that FW vendor will be getting some lawsuits. If a FW vendor reports a 
> product to work a certain way and instead thru a massive vulnerability 
> or development oversight it does not the same applies. Software. 
> Hardware. Physical (fire). Logical (vulnerability). I'm not saying 
> that it happens all the time and I'm not even saying it's a general 
> practice. What I'm saying is it happens. And depending on your 
> business vertical it could be a very real consideration.
>
> COMPLETELY 100% MADE UP HYPOTHETICAL SCENARIO:
>
> I put a FW in. I put proper L3 ACLs in. I block 443 inbound. I didn't 
> say I block HTTPS. I block 443. I test it by telnetting from the 
> Internet to 1.1.1.1:443 and I am unable to connect. Looks good. A 
> month later our CEO is surfing the Internet. Thru a development 
> oversight in the product, when I NAT or PAT him to the Internet his 
> source port is not pulled from the Ephemeral range but is instead 
> sourced as port 443. He of course goes to sites riddled with Malware 
> because that's what CEOs do. They click on links. So the Malware 
> website initiates a new TCP session to destination port 443 with his 
> NATted IP. The state table has an entry for that IP and 443 and even 
> though this is a new TCP session the FW lets it thru. The malware site 
> bad guys are able to retrieve confidential information about a merger 
> and publish it. The other company that we were merging with sues us 
> because the information is leaked to the public and adversely impacted 
> their stock value. Everything in the above paragraph is able to be 
> documented thru forensics and it is indisputable that the FW was 
> properly configured and should have blocked it but didn't. The FW did 
> NOT perform as advertised/designed. This is NOT the fault of me or my 
> company. If a few thousand dollars is at stake nothing may come of 
> this. If tens or hundreds of millions of dollars are at stake I 
> promise you that our lawyers will be contacting the manufacturer whose 
> product did not perform as advertised. They will compensate (in one 
> way or another) us for our losses. It's a big ugly world full of lots 
> of lawyers.
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 11/10/2011 09:14 AM, Richard Kulawiec wrote:
>> On Thu, Nov 10, 2011 at 08:52:22AM -0600, -Hammer- wrote:
>>> The other high cost of "free" that people sometimes overlook is
>>> liability.
>> Please point to an instance (case citation, please) where a commercial
>> firewall vendor has been successfully litigated against -- that is, held
>> responsible by a court of law for a failure of their product to provide
>> the functionality that it's claimed to provide.
>>
>> ---rsk
>>
>>



From bhmccie at gmail.com  Thu Nov 10 10:06:32 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Thu, 10 Nov 2011 10:06:32 -0600
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBBF603.1000506@alter3d.ca>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org> <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
 <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org>
 <4EBBF031.4060200@gmail.com> <4EBBF603.1000506@alter3d.ca>
Message-ID: <4EBBF688.4060300@gmail.com>

Look the thread was about considerations for various firewalls. 
Eventually it spun off to be considerations and issues with Open Source 
options. I was merely pointing out a consideration that some folks have 
to take into account. You don't have to like it, agree with it, or even 
believe it. But it does happen and it is out there. I was just pointing 
it out. Take it for what you want but arguing it is pointless. It's out 
there for some of us.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/10/2011 10:04 AM, Peter Kristolaitis wrote:
> Your hypothetical scenario assumes you're the only organization 
> compromised by the flaw (or one of very few), and not #3972 on the 
> list, in which case the company could go bankrupt before a court can 
> hear your case, and the "liability protection" they offered you is 
> worth the electrons it's printed on.    It's great if you're a Fortune 
> 50 and have the legal, political and financial clout to be #1 on the 
> lawsuit list, but nearly worthless for most organizations.
>
> - Peter
>
>
> On 11/10/2011 10:39 AM, -Hammer- wrote:
>> OK. Right off the bat you know I can't and won't. But in some places 
>> it is common practice to make sure agreements are in place to make 
>> sure all parties are protected based on how a product is 
>> expected/designed to perform. I can't say more than that. Realize I'm 
>> speaking about things that are solely on the vendor. Not "Did you 
>> configure the ACL properly?"
>>
>> What you can Google is the names of companies who have settled out of 
>> court against various trolling lawsuits vs the names of companies 
>> that are still in litigation. There is a mix of both 
>> manufacturer/vendor and end customer. It all depends on the case.
>>
>> This shouldn't surprise you. If Toyota makes a defective brake and 
>> you slam into someone else, your insurance covers you. Eventually, if 
>> the issue scales out to the point that it is obvious that Toyota made 
>> a defective brake and it is not your fault, some insurance companies 
>> collectively will go to the government or directly to the 
>> manufacturer for compensation. This is no different. If you sell me a 
>> FW and it catches on fire thru no fault of my own and then the public 
>> finds out that FWs are catching on fire all over the place, it's a 
>> good bet that that FW vendor will be getting some lawsuits. If a FW 
>> vendor reports a product to work a certain way and instead thru a 
>> massive vulnerability or development oversight it does not the same 
>> applies. Software. Hardware. Physical (fire). Logical 
>> (vulnerability). I'm not saying that it happens all the time and I'm 
>> not even saying it's a general practice. What I'm saying is it 
>> happens. And depending on your business vertical it could be a very 
>> real consideration.
>>
>> COMPLETELY 100% MADE UP HYPOTHETICAL SCENARIO:
>>
>> I put a FW in. I put proper L3 ACLs in. I block 443 inbound. I didn't 
>> say I block HTTPS. I block 443. I test it by telnetting from the 
>> Internet to 1.1.1.1:443 and I am unable to connect. Looks good. A 
>> month later our CEO is surfing the Internet. Thru a development 
>> oversight in the product, when I NAT or PAT him to the Internet his 
>> source port is not pulled from the Ephemeral range but is instead 
>> sourced as port 443. He of course goes to sites riddled with Malware 
>> because that's what CEOs do. They click on links. So the Malware 
>> website initiates a new TCP session to destination port 443 with his 
>> NATted IP. The state table has an entry for that IP and 443 and even 
>> though this is a new TCP session the FW lets it thru. The malware 
>> site bad guys are able to retrieve confidential information about a 
>> merger and publish it. The other company that we were merging with 
>> sues us because the information is leaked to the public and adversely 
>> impacted their stock value. Everything in the above paragraph is able 
>> to be documented thru forensics and it is indisputable that the FW 
>> was properly configured and should have blocked it but didn't. The FW 
>> did NOT perform as advertised/designed. This is NOT the fault of me 
>> or my company. If a few thousand dollars is at stake nothing may come 
>> of this. If tens or hundreds of millions of dollars are at stake I 
>> promise you that our lawyers will be contacting the manufacturer 
>> whose product did not perform as advertised. They will compensate (in 
>> one way or another) us for our losses. It's a big ugly world full of 
>> lots of lawyers.
>>
>> -Hammer-
>>
>> "I was a normal American nerd"
>> -Jack Herer
>>
>>
>>
>> On 11/10/2011 09:14 AM, Richard Kulawiec wrote:
>>> On Thu, Nov 10, 2011 at 08:52:22AM -0600, -Hammer- wrote:
>>>> The other high cost of "free" that people sometimes overlook is
>>>> liability.
>>> Please point to an instance (case citation, please) where a commercial
>>> firewall vendor has been successfully litigated against -- that is, 
>>> held
>>> responsible by a court of law for a failure of their product to provide
>>> the functionality that it's claimed to provide.
>>>
>>> ---rsk
>>>
>>>
>
>

From egermann at limanews.com  Thu Nov 10 10:20:22 2011
From: egermann at limanews.com (Eric Germann)
Date: Thu, 10 Nov 2011 08:20:22 -0800
Subject: TwTelecom engineer offlist
Message-ID: <730AF3879A3A3844B3FB5A881A3DFBC8D60719AF08@VA3DIAXVS091.RED001.local>

Anyone with twtelecom who can contact me off list about a possible congestion issue at one of your handoffs?

Thanks

EKG


From jof at thejof.com  Thu Nov 10 10:30:46 2011
From: jof at thejof.com (Jonathan Lassoff)
Date: Thu, 10 Nov 2011 08:30:46 -0800
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBAE62E.5090706@foobar.org>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org>
 <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
Message-ID: <CAHsqw9v60yOiZfadCOpgXgz9NmYZB4HCtyNHRbNGDBPsbMWpWw@mail.gmail.com>

On Wed, Nov 9, 2011 at 12:44 PM, Nick Hilliard <nick at foobar.org> wrote:
> On 09/11/2011 19:07, C. Jon Larsen wrote:
>>
>> put the main portion of the conf in subversion as an include file and
>> factor out local differences in the configs with macros that are defined
>> in
>> pf.conf
>>
>> Easy.
>
> As I said, it's not a pf problem. ?Commercial firewalls will do all this
> sort of thing off the shelf. ?It's a pain to have to write scripts to do
> this manually.

Agreed. This is rather a pain to have to do manually each time (either
scp'ing or scripting). It's unfortunate that there's not a
conventional script or mechanism for doing this.

I have plenty of scripts from past commercial work that do this, but
they're sadly tied up license-wise.

I've had good luck, pf-wise, with creating a ruleset that is just
identical between hosts. By keeping the interface naming/numbering
scheme consistent across two hosts, the same configuration can just
"work" on both.

Cheers,
jof


From drc at virtualized.org  Thu Nov 10 10:59:35 2011
From: drc at virtualized.org (David Conrad)
Date: Thu, 10 Nov 2011 08:59:35 -0800
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <CAP-guGWNzWp4WOGTquZdua5gjLi3btsY7TXLkSi9EObVef+6Bw@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com>
 <CAP-guGWNzWp4WOGTquZdua5gjLi3btsY7TXLkSi9EObVef+6Bw@mail.gmail.com>
Message-ID: <FF2591A7-2541-49F3-8C8D-13C105259DCE@virtualized.org>

Bill,

On Nov 10, 2011, at 5:48 AM, William Herrin wrote:
> On Thu, Nov 10, 2011 at 8:28 AM, Randy Bush <randy at psg.com> wrote:
>> i am sure the americans who think all address space should righfully be
>> theirs can dream up paranoid scenarios for anything.  but dear canute,
>> the tide is coming, get over it or get wet.
> You're fortunate that you speak for a minority.

I don't think Randy speaks for anyone but himself. Some may, however, agree with him.

> If you didn't, we'd
> tell the bunch of you to go to hell instead of valiantly seeking to
> improve the situation in which APNIC finds itself.

Seriously?

It is this sort of attitude that resulted in me giving up in disgust with the whole RIR circus.  Well that and a curious note from ARIN counsel (at the direction of ARIN's board) to my then corporate counsel purportedly "expressing concern" about statements I made in a personal capacity on NANOG. Quite amusing, actually, but still disgusting.

A tiny dose of reality: 
- The Internet (and world population as a whole) is growing most rapidly in the Asia/Pacific region. 
- There are companies who demand IPv4 addresses for which the combined yearly budgets of all the RIRs amounts to little more than a small fraction of what those companies spend on their lawyers alone.
- APNIC no longer has IPv4 addresses to meet that demand.
- There now at least 4 different organizations offering IPv4 addresses for sale (addrex.net, kalorama.com, tradeipv4.com, ipv4marketgroup.com) who are now participating in an estimated at $6 - $8 Billion market (and that's just legacy space).

And you believe the couple of hundred folks who participate in ARIN are going to stand in the way of those business interests?  I might gently suggest it would probably be more useful to figure out how the new market players and the "legacy" RIRs can coexist in a way that doesn't do severe damage to the Internet than it is to discuss how to rearrange the deck chairs in ever more intricate designs in order to try to maintain unjustifiable monopolies.

I might suggest that but as I said, I gave up in disgust.  Tell King Canute's advisors I said "hi".

Regards,
-drc



From nick at foobar.org  Thu Nov 10 11:29:40 2011
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 10 Nov 2011 17:29:40 +0000
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in
 one week)
In-Reply-To: <FF2591A7-2541-49F3-8C8D-13C105259DCE@virtualized.org>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com>
 <CAP-guGWNzWp4WOGTquZdua5gjLi3btsY7TXLkSi9EObVef+6Bw@mail.gmail.com>
 <FF2591A7-2541-49F3-8C8D-13C105259DCE@virtualized.org>
Message-ID: <4EBC0A04.2010507@foobar.org>

On 10/11/2011 16:59, David Conrad wrote:
> Tell King Canute's advisors I said "hi".

My OCD is screaming at me to point out that King Knut was attempting to 
show his advisers that even he couldn't control the tides.

Nick


From rsk at gsp.org  Thu Nov 10 11:50:59 2011
From: rsk at gsp.org (Richard Kulawiec)
Date: Thu, 10 Nov 2011 12:50:59 -0500
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <CAHsqw9v60yOiZfadCOpgXgz9NmYZB4HCtyNHRbNGDBPsbMWpWw@mail.gmail.com>
References: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C40@MS-EX7MB-P03.corp.se.sempra.com>
 <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org>
 <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAHsqw9v60yOiZfadCOpgXgz9NmYZB4HCtyNHRbNGDBPsbMWpWw@mail.gmail.com>
Message-ID: <20111110175059.GA14575@gsp.org>

On Thu, Nov 10, 2011 at 08:30:46AM -0800, Jonathan Lassoff wrote:
> > As I said, it's not a pf problem. ?Commercial firewalls will do all this
> > sort of thing off the shelf. ?It's a pain to have to write scripts to do
> > this manually.
> 
> Agreed. This is rather a pain to have to do manually each time (either
> scp'ing or scripting). It's unfortunate that there's not a
> conventional script or mechanism for doing this.

I don't see why this is a problem.   I've been using tools like make, RCS
(or CVS or subversion), perl, and rsync to maintain all kinds of unified
and diverse configurations on small and large numbers of systems for many
years.  It's simple, it's scalable, it's easy to write, it's portable,
it's robust (provided you pay attention to command exit codes), and it
allows easy integration between disparate configuration files.  (As an
example of that last: I can cause changes in pf.conf to be synchronized
with appropriately-matching changes in sendmail.cf or named.conf.  Use of
"make"  ensures that they're kept in a consistent state.  Of course, if I
make a mistake, they're consistently wrong: but that's highly desirable.)

Yes, you have to understand the interrelationships between all these
moving parts to write the scripts/makefiles; but that's a good thing.
And the payoff is that you get FAR more flexibility than any commercial
product.  And it's free (modulo your time investment...and you'd be
investing time anyway, trying to make some vendor's setup do what you want).

---rsk


From rsk at gsp.org  Thu Nov 10 12:12:19 2011
From: rsk at gsp.org (Richard Kulawiec)
Date: Thu, 10 Nov 2011 13:12:19 -0500
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBBF031.4060200@gmail.com>
References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org>
 <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
 <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org>
 <4EBBF031.4060200@gmail.com>
Message-ID: <20111110181219.GA26841@gsp.org>

On Thu, Nov 10, 2011 at 09:39:29AM -0600, -Hammer- wrote:
> OK. Right off the bat you know I can't and won't. 

Right.  I know you can't and won't.   I can't either.  So we can
summarily dismiss all the concerns about liability because they
have no relationship to reality.  You will not be suing BigFirewallCo,
no matter how horribly their product fails, no matter how bad the damage is,
no matter how obvious to all of us the failure is, no matter how culpable
we might all agree they are, because (a) your pockets aren't as deep
as BigFirewallCo's, and (b) you'd probably lose anyway (c) after 11 years
and a lot of billable hours for everyone's attorneys.  (s/you/I/ and
everyone else, unless we happen to work for a Fortune 50 company...and
probably not even then.)

When it comes to security, I think it's better to rely on software
engineering than litigation.

---rsk


From bhmccie at gmail.com  Thu Nov 10 12:12:21 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Thu, 10 Nov 2011 12:12:21 -0600
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <20111110181219.GA26841@gsp.org>
References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org> <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
 <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org>
 <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org>
Message-ID: <4EBC1405.5010007@gmail.com>

WOW. You really are naive....

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/10/2011 12:12 PM, Richard Kulawiec wrote:
> On Thu, Nov 10, 2011 at 09:39:29AM -0600, -Hammer- wrote:
>    
>> OK. Right off the bat you know I can't and won't.
>>      
> Right.  I know you can't and won't.   I can't either.  So we can
> summarily dismiss all the concerns about liability because they
> have no relationship to reality.  You will not be suing BigFirewallCo,
> no matter how horribly their product fails, no matter how bad the damage is,
> no matter how obvious to all of us the failure is, no matter how culpable
> we might all agree they are, because (a) your pockets aren't as deep
> as BigFirewallCo's, and (b) you'd probably lose anyway (c) after 11 years
> and a lot of billable hours for everyone's attorneys.  (s/you/I/ and
> everyone else, unless we happen to work for a Fortune 50 company...and
> probably not even then.)
>
> When it comes to security, I think it's better to rely on software
> engineering than litigation.
>
> ---rsk
>
>    

From jra at baylink.com  Thu Nov 10 12:19:49 2011
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 10 Nov 2011 13:19:49 -0500 (EST)
Subject: Firewalls - Ease of Litigation and Subrogation
In-Reply-To: <20111110181219.GA26841@gsp.org>
Message-ID: <24317277.2351.1320949189583.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Richard Kulawiec" <rsk at gsp.org>

> Right. I know you can't and won't. I can't either. So we can
> summarily dismiss all the concerns about liability because they
> have no relationship to reality. You will not be suing BigFirewallCo,
> no matter how horribly their product fails, no matter how bad the damage is,
> no matter how obvious to all of us the failure is, no matter how culpable
> we might all agree they are, because (a) your pockets aren't as deep
> as BigFirewallCo's, and (b) you'd probably lose anyway (c) after 11 years
> and a lot of billable hours for everyone's attorneys. (s/you/I/ and
> everyone else, unless we happen to work for a Fortune 50 company...and
> probably not even then.)

Yeah, Rich, but come on: you and I -- and even his managers -- know that while
that is true (that no one's actually going to sue anyone, and likely legally
cannot anyway), that *still* won't keep Pointy Haired Bosses from making that
*capability* a firm requirement.

That's why their hair is pointy.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From bhmccie at gmail.com  Thu Nov 10 12:19:20 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Thu, 10 Nov 2011 12:19:20 -0600
Subject: Firewalls - Ease of Litigation and Subrogation
In-Reply-To: <24317277.2351.1320949189583.JavaMail.root@benjamin.baylink.com>
References: <24317277.2351.1320949189583.JavaMail.root@benjamin.baylink.com>
Message-ID: <4EBC15A8.8010909@gmail.com>

You guys are hilarious. OK. I give up. It never happens. I'll leave this 
thread alone.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/10/2011 12:19 PM, Jay Ashworth wrote:
> ----- Original Message -----
>    
>> From: "Richard Kulawiec"<rsk at gsp.org>
>>      
>    
>> Right. I know you can't and won't. I can't either. So we can
>> summarily dismiss all the concerns about liability because they
>> have no relationship to reality. You will not be suing BigFirewallCo,
>> no matter how horribly their product fails, no matter how bad the damage is,
>> no matter how obvious to all of us the failure is, no matter how culpable
>> we might all agree they are, because (a) your pockets aren't as deep
>> as BigFirewallCo's, and (b) you'd probably lose anyway (c) after 11 years
>> and a lot of billable hours for everyone's attorneys. (s/you/I/ and
>> everyone else, unless we happen to work for a Fortune 50 company...and
>> probably not even then.)
>>      
> Yeah, Rich, but come on: you and I -- and even his managers -- know that while
> that is true (that no one's actually going to sue anyone, and likely legally
> cannot anyway), that *still* won't keep Pointy Haired Bosses from making that
> *capability* a firm requirement.
>
> That's why their hair is pointy.
>
> Cheers,
> -- jra
>    

From Valdis.Kletnieks at vt.edu  Thu Nov 10 12:24:29 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 10 Nov 2011 13:24:29 -0500
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: Your message of "Thu, 10 Nov 2011 12:12:21 CST."
 <4EBC1405.5010007@gmail.com>
References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org> <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
 <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org>
 <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org>
 <4EBC1405.5010007@gmail.com>
Message-ID: <8252.1320949469@turing-police.cc.vt.edu>

On Thu, 10 Nov 2011 12:12:21 CST, -Hammer- said:
> WOW. You really are naive....

I think Rich has been around long enough that he gets called a *lot* of things
(many of them non-complimentary), but this is the first time this century
anybody's called him *naive*... ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111110/70a18931/attachment-0001.bin>

From bhmccie at gmail.com  Thu Nov 10 12:28:52 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Thu, 10 Nov 2011 12:28:52 -0600
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <8252.1320949469@turing-police.cc.vt.edu>
References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org> <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
 <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org>
 <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org>
 <4EBC1405.5010007@gmail.com> <8252.1320949469@turing-police.cc.vt.edu>
Message-ID: <4EBC17E4.5060807@gmail.com>

OK. Maybe I jumped to hard. But to tell me that what I'm referring to 
has never happened (even though I've participated) just because he 
hasn't heard of it is not the best way to approach an argument. When 
these things happen, there are agreements in place so it's not 
discussed. Especially when it's settled out of court. If you want some 
fun reading on the subject google Walker Digital or Leon Stambler.

Again, I never said it happens to everyone. But it does happen and some 
of us have to consider it. I didn't realize it would come under such 
scrutiny just because it isn't widely published.

Again, I'll try and leave this thread alone.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/10/2011 12:24 PM, Valdis.Kletnieks at vt.edu wrote:
> On Thu, 10 Nov 2011 12:12:21 CST, -Hammer- said:
>    
>> WOW. You really are naive....
>>      
> I think Rich has been around long enough that he gets called a *lot* of things
> (many of them non-complimentary), but this is the first time this century
> anybody's called him *naive*... ;)
>
>    

From js.lists at gmail.com  Thu Nov 10 12:51:14 2011
From: js.lists at gmail.com (Joe)
Date: Thu, 10 Nov 2011 10:51:14 -0800
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBC17E4.5060807@gmail.com>
References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org> <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
 <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org>
 <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org>
 <4EBC1405.5010007@gmail.com> <8252.1320949469@turing-police.cc.vt.edu>
 <4EBC17E4.5060807@gmail.com>
Message-ID: <3F46E049-1568-4402-A3A0-54A8D83F36E6@gmail.com>

Litigation? Wow. 

To answer the OP:

Any of the Cisco, Juniper, Sonic, Fortinet, etc can be easy to use to maintain. But I'd make sure you have a good understanding of what you intend to do, and what products will satisfy your needs. Demo's are a good idea. One person's definition of easy may not match someone else's.

If you know what you're doing and want to roll your own, then go with what you're most comfortable with (linux, bad, etc). Your subject indicates you aren't comfortable with rolling your own, so there is no point to the side debate going on in this thread.

Side point: For what it's worth, I use PF on OpenBSD because I like the clean and easy to read syntax. To me, that is *easier* to use, than trying to figure out some point-click GUI. The take away from this is, "what does ease of use mean to you"?

Hope that helps.

From bhmccie at gmail.com  Thu Nov 10 12:54:48 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Thu, 10 Nov 2011 12:54:48 -0600
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <8252.1320949469@turing-police.cc.vt.edu>
References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org> <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
 <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org>
 <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org>
 <4EBC1405.5010007@gmail.com> <8252.1320949469@turing-police.cc.vt.edu>
Message-ID: <4EBC1DF8.5070205@gmail.com>

I changed my mind. I want to clear this up. Here is an example of where 
a patent troll skipped over the manufacturer and went straight for the 
end customer. There are dozens of these attacking all verticals and 
manufacturers alike for various reasons.

http://dockets.justia.com/docket/texas/txedce/2:2008cv00471/113504/

So a customer buys a product that contains a technology. Then the 
customer is sued for possessing said technology. You don't think the 
customer (Merrill Lynch / BofA / Citigroup / etc) isn't gonna take that 
lawsuit and call the manufacturer up and tell them they are gonna eat 
it? You don't think a financial institution or a healthcare organization 
would attempt to recuperate the costs? You don't think that after the 
fact agreements are put in place so that frivolous lawsuits like this 
are appropriately handled between the manufacturer and the customer in 
the future? When millions of dollars are at stake? You don't have to 
like it. But you should be a little more objective.

I am not speaking of specific cases I'm involved in. I just googled a 
few things and found some results....

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/10/2011 12:24 PM, Valdis.Kletnieks at vt.edu wrote:
> On Thu, 10 Nov 2011 12:12:21 CST, -Hammer- said:
>    
>> WOW. You really are naive....
>>      
> I think Rich has been around long enough that he gets called a *lot* of things
> (many of them non-complimentary), but this is the first time this century
> anybody's called him *naive*... ;)
>
>    

From nathan at atlasnetworks.us  Thu Nov 10 16:07:20 2011
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Thu, 10 Nov 2011 22:07:20 +0000
Subject: Security Contact from k12.fl.us
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B5E66A6@ex-mb-1.corp.atlasnetworks.us>

Please contact me off-list.

From nathan at atlasnetworks.us  Thu Nov 10 16:14:43 2011
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Thu, 10 Nov 2011 22:14:43 +0000
Subject: Security Contact from broward.k12.fl.us (was: Security Contact
 from k12.fl.us)
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B5E66A6@ex-mb-1.corp.atlasnetworks.us>
References: <8C26A4FDAE599041A13EB499117D3C286B5E66A6@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B5E66F2@ex-mb-1.corp.atlasnetworks.us>

It was pointed out to me that 'k12.fl.us' is not an organization, but rather a container.  Clarification - I'm looking for a security contact from broward.k12.fl.us

Nathan Eisenberg

> -----Original Message-----
> From: Nathan Eisenberg
> Sent: Thursday, November 10, 2011 2:07 PM
> To: NANOG list
> Subject: Security Contact from k12.fl.us
> 
> Please contact me off-list.



From jbates at brightok.net  Thu Nov 10 20:05:33 2011
From: jbates at brightok.net (Jack Bates)
Date: Thu, 10 Nov 2011 20:05:33 -0600
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <8252.1320949469@turing-police.cc.vt.edu>
References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org> <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
 <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org>
 <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org>
 <4EBC1405.5010007@gmail.com> <8252.1320949469@turing-police.cc.vt.edu>
Message-ID: <4EBC82ED.6060603@brightok.net>

On 11/10/2011 12:24 PM, Valdis.Kletnieks at vt.edu wrote:
> I think Rich has been around long enough that he gets called a*lot*  of things
> (many of them non-complimentary), but this is the first time this century
> anybody's called him*naive*...;)

Given that all of humankind is naive, it would be redundant. The other 
things are much more entertaining.


Jack

From randy at psg.com  Thu Nov 10 22:50:28 2011
From: randy at psg.com (Randy Bush)
Date: Fri, 11 Nov 2011 13:50:28 +0900
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <FF2591A7-2541-49F3-8C8D-13C105259DCE@virtualized.org>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org>
 <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com>
 <CAP-guGWNzWp4WOGTquZdua5gjLi3btsY7TXLkSi9EObVef+6Bw@mail.gmail.com>
 <FF2591A7-2541-49F3-8C8D-13C105259DCE@virtualized.org>
Message-ID: <m2zkg3dzzf.wl%randy@psg.com>

> And you believe the couple of hundred folks who participate in ARIN
> are going to stand in the way of those business interests?  I might
> gently suggest it would probably be more useful to figure out how the
> new market players and the "legacy" RIRs can coexist in a way that
> doesn't do severe damage to the Internet than it is to discuss how to
> rearrange the deck chairs in ever more intricate designs in order to
> try to maintain unjustifiable monopolies.

arin control-freak vigilante insanity overwhelmed what's good for the
internet long ago.

randy


From brett at the-watsons.org  Fri Nov 11 01:15:46 2011
From: brett at the-watsons.org (Brett Watson)
Date: Fri, 11 Nov 2011 00:15:46 -0700
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <20111110135618.GA82609@ussenterprise.ufp.org>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com> <20111110135618.GA82609@ussenterprise.ufp.org>
Message-ID: <F86D9C6F-9C85-46F9-8916-DCC44567BEE5@the-watsons.org>

On Nov 10, 2011, at 6:56 AM, Leo Bicknell wrote:

> The tide is coming.  The tide is wet.  The tide is full of IPv6 water.
> Get over it.

Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6 issues? (I'll just leave it at those three).

-b

From harris.hui at gmail.com  Fri Nov 11 02:19:10 2011
From: harris.hui at gmail.com (Harris Hui)
Date: Fri, 11 Nov 2011 16:19:10 +0800
Subject: Location of Akamai Edge servers in Hong Kong
Message-ID: <CAPqnQsHppOkJtSLw+B4MvqAy5qrxHiGrVBCEC4myUw6ZOPSiww@mail.gmail.com>

Hi,

Does anybody know where is the Akamai Edge servers located in Hong Kong?
Which ISPs they are using? Are they peering with HKIX?

Please advise.

Thanks
Harris

From chcheng at ieee.org  Fri Nov 11 03:17:32 2011
From: chcheng at ieee.org (Che-Hoo CHENG)
Date: Fri, 11 Nov 2011 17:17:32 +0800
Subject: Location of Akamai Edge servers in Hong Kong
In-Reply-To: <CAPqnQsHppOkJtSLw+B4MvqAy5qrxHiGrVBCEC4myUw6ZOPSiww@mail.gmail.com>
References: <CAPqnQsHppOkJtSLw+B4MvqAy5qrxHiGrVBCEC4myUw6ZOPSiww@mail.gmail.com>
Message-ID: <FB6E111E-5A98-43FF-BFFB-A9689E65F116@ieee.org>

Yes, AS20940 is on HKIX.  You can check HKIX's Looking Glass (of MLPA Route Servers) at http://www.hkix.net/hkix/hkixlg.htm or http://www.hkix.net/hkix/connected.htm .  I'm sure they do BLPA over HKIX too.

Regards,

Che-Hoo


On 11 Nov, 2011, at 4:19 PM, Harris Hui wrote:

> Hi,
> 
> Does anybody know where is the Akamai Edge servers located in Hong Kong?
> Which ISPs they are using? Are they peering with HKIX?
> 
> Please advise.
> 
> Thanks
> Harris



From cdel at firsthand.net  Fri Nov 11 03:34:27 2011
From: cdel at firsthand.net (Christian de Larrinaga)
Date: Fri, 11 Nov 2011 09:34:27 +0000
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <F86D9C6F-9C85-46F9-8916-DCC44567BEE5@the-watsons.org>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com> <20111110135618.GA82609@ussenterprise.ufp.org>
 <F86D9C6F-9C85-46F9-8916-DCC44567BEE5@the-watsons.org>
Message-ID: <4D6F26F1-005B-4095-B65F-DEAF79006396@firsthand.net>


Lucky rich you to have such capacious v4 connectivity to be worrying about such downstream stuff. The rest of the world is starring at abyss of zero connectivity unless it deploys v6. 

Solve that one. 


Christian

On 11 Nov 2011, at 07:15, Brett Watson wrote:

> On Nov 10, 2011, at 6:56 AM, Leo Bicknell wrote:
> 
>> The tide is coming.  The tide is wet.  The tide is full of IPv6 water.
>> Get over it.
> 
> Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6 issues? (I'll just leave it at those three).
> 
> -b



From jcurran at arin.net  Fri Nov 11 04:47:50 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 11 Nov 2011 10:47:50 +0000
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in
 one week)
In-Reply-To: <FF2591A7-2541-49F3-8C8D-13C105259DCE@virtualized.org>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com>
 <CAP-guGWNzWp4WOGTquZdua5gjLi3btsY7TXLkSi9EObVef+6Bw@mail.gmail.com>
 <FF2591A7-2541-49F3-8C8D-13C105259DCE@virtualized.org>
Message-ID: <9B8525E7-022F-478E-AA38-A92475C55F2D@arin.net>

On Nov 10, 2011, at 11:59 AM, David Conrad wrote:

> A tiny dose of reality: 
> - The Internet (and world population as a whole) is growing most rapidly in the Asia/Pacific region. 
> - There are companies who demand IPv4 addresses for which the combined yearly budgets of all the RIRs amounts to little more than a small fraction of what those companies spend on their lawyers alone.
> - APNIC no longer has IPv4 addresses to meet that demand.
> - There now at least 4 different organizations offering IPv4 addresses for sale (addrex.net, kalorama.com, tradeipv4.com, ipv4marketgroup.com) who are now participating in an estimated at $6 - $8 Billion market (and that's just legacy space).
> 
> And you believe the couple of hundred folks who participate in ARIN are going to stand in the way of those business interests?  I might gently suggest it would probably be more useful to figure out how the new market players and the "legacy" RIRs can coexist in a way that doesn't do severe damage to the Internet than it is to discuss how to rearrange the deck chairs in ever more intricate designs in order to try to maintain unjustifiable monopolies.

David - 

  We've got co-existence today for transfers within the ARIN region;
  it is now not uncommon to see ("Sale may be subject to compliance 
  with policies of the American Registry of Internet Numbers") on 
  various solicitations involving resources registered in the region.
 
  At present, there is no way to transfer resources in or out of the
  region, and whether that is desirable and under what constraints is 
  precisely the question at hand with draft policy ARIN-2011-1. To the 
  extent that folks have a view on this matter either in support or 
  against, I suggest that you make that view known on the ARIN Public
  Policy Mailing List (ppml).   As this policy will have some effect
  on many in the Internet community, it would be best for folks to 
  take a moment to provide this important feedback.

Thanks!
/John

John Curran
President and CEO
ARIN



From bmanning at vacation.karoshi.com  Fri Nov 11 04:51:38 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 11 Nov 2011 10:51:38 +0000
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <4D6F26F1-005B-4095-B65F-DEAF79006396@firsthand.net>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com> <20111110135618.GA82609@ussenterprise.ufp.org>
 <F86D9C6F-9C85-46F9-8916-DCC44567BEE5@the-watsons.org>
 <4D6F26F1-005B-4095-B65F-DEAF79006396@firsthand.net>
Message-ID: <20111111105138.GA4384@vacation.karoshi.com.>


actually - Paul Francis has done the community a massive favor by making the argument
for NAT as a viable tool strong enough that NAT and NAT-like technologies are pervasive.

NAT is even used to "glue" v4 and v6 enclaves together.

So it is too early to tell if IPv6-only will be the inevitable end game (in our lifetimes),
or if NAT-enabled infrastructures will continue to be pervasive, leaving v4 enclaves running
for longer than our childrens live.

This policy proposal is one means to track rights to use a given resource, and it is not 
clear to me that it has to fit in the sole provence of a single address family (although it
is clearly targeted for one of them as currently written)

I guess that puts me in the camp of favoring this work.

For the rest of the zelots (in either camp) - put down the retoric and quit trying to teach
the pigs to sing.  Its a waste of your time and it annoys the pigs.

/bill


On Fri, Nov 11, 2011 at 09:34:27AM +0000, Christian de Larrinaga wrote:
> 
> Lucky rich you to have such capacious v4 connectivity to be worrying about such downstream stuff. The rest of the world is starring at abyss of zero connectivity unless it deploys v6. 
> 
> Solve that one. 
> 
> 
> Christian
> 
> On 11 Nov 2011, at 07:15, Brett Watson wrote:
> 
> > On Nov 10, 2011, at 6:56 AM, Leo Bicknell wrote:
> > 
> >> The tide is coming.  The tide is wet.  The tide is full of IPv6 water.
> >> Get over it.
> > 
> > Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6 issues? (I'll just leave it at those three).
> > 
> > -b
> 
> 


From bicknell at ufp.org  Fri Nov 11 08:55:03 2011
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 11 Nov 2011 06:55:03 -0800
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <F86D9C6F-9C85-46F9-8916-DCC44567BEE5@the-watsons.org>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com> <20111110135618.GA82609@ussenterprise.ufp.org>
 <F86D9C6F-9C85-46F9-8916-DCC44567BEE5@the-watsons.org>
Message-ID: <20111111145503.GA48535@ussenterprise.ufp.org>

In a message written on Fri, Nov 11, 2011 at 12:15:46AM -0700, Brett Watson wrote:
> > The tide is coming.  The tide is wet.  The tide is full of IPv6 water.
> > Get over it.
> 
> Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6 issues? (I'll just leave it at those three).

Multi-homing in IPv6 works just like it does in IPv4.  Folks may
be working on better ways, but that's the reality of the moment,
and it's a deployable reality.

RA/DHCPv6 is being worked on, and progress is being made...although
slower than I would like.

But remember, IPv4 isn't done 30+ years on.  The IETF has entertained
proposals to improve/extend IPv4 every year.  NAT wasn't in the original
spec.  MPLS was added much later, etc.  If you expect IPv6 to have 100%
feature parity day one and then never change, you have unrealistic
expectations.

It's deployable today.  Heck Comcast is deploying to end-users as we
speak.  Maybe in a few scenarios it still has significant issues that
there are deployment problems, but you find those by doing, not by
waiting.

The networks I run have been dual stacked for 5+ years.  It works.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111111/3a2ec9dd/attachment.bin>

From lorell at hathcock.org  Fri Nov 11 09:09:46 2011
From: lorell at hathcock.org (Lorell Hathcock)
Date: Fri, 11 Nov 2011 09:09:46 -0600
Subject: Savvis broken link / underperforming between DC and Atlanta?
Message-ID: <004c01cca083$f36da1b0$da48e510$@hathcock.org>

Any one else seeing this?

 

This was done yesterday from Hawaii.

 

tracert speedtest.saas.infor.com

  3     5 ms     5 ms     4 ms  ip64-75-240-210.aloha.net [64.75.240.210]

  4     5 ms     5 ms     5 ms  hnl-edge-02.inet.qwest.net [67.129.94.69]

  5     *        *        *     Request timed out.

  6    56 ms    56 ms    56 ms  63-235-40-18.dia.static.qwest.net
[63.235.40.18]

  7    58 ms    58 ms    59 ms  cr1-tenge-0-3-5-0.sanfrancisco.savvis.net
[204.70.200.198]

  8   138 ms   138 ms   138 ms  cr1-bundle-pos2.Washington.savvis.net
[204.70.200.90]

  9   135 ms   136 ms   136 ms  hr1-tengig-2-0-0.sterling2dc2.savvis.net
[204.70.197.74]

10   139 ms   136 ms   137 ms  165.193.78.106

11     *        *        *     Request timed out.

12     *        *        *     Request timed out.

13     *        *        *     Request timed out.

 

But from Houston it was fine yesterday.   It took a different route.

 

Today I have the same problem from Houston.

 

tracert speedtest.saas.infor.com

  4     2 ms     2 ms     2 ms  te4-1.3509.ccr01.iah02.atlas.cogentco.com
[66.28.6.21]

  5     3 ms     2 ms     2 ms  te0-2-0-4.ccr21.iah01.atlas.cogentco.com
[154.54.3.149]

  6     9 ms    10 ms     8 ms  te0-1-0-5.ccr21.dfw01.atlas.cogentco.com
[154.54.2.225]

  7     8 ms     8 ms     8 ms  te7-3.mpd01.dfw03.atlas.cogentco.com
[154.54.6.66]

  8    15 ms     8 ms    12 ms  aer1-ge-4-2.dallasequinix.savvis.net
[208.175.175.5]

  9    17 ms     8 ms    15 ms  204.70.207.182

10    10 ms     9 ms    10 ms  cr1-tengig0-7-5-0.Dallas.savvis.net
[204.70.200.170]

11    37 ms    37 ms    37 ms  cr1-tengig-0-7-0-0.Washington.savvis.net
[204.70.196.105]

12    36 ms    36 ms    36 ms  hr1-tengig-2-0-0.sterling2dc2.savvis.net
[204.70.197.74]

13    37 ms    36 ms    37 ms  165.193.78.106

14     *        *        *     Request timed out.

15     *        *        *     Request timed out.

16     *        *        *     Request timed out.

 

This the end IP address is in Rackspace in Atlanta I am told.  Known issues
out there?  Any de-peering going on?  Or is this just a firewall or private
IP space that is not responding to traceroute information requests?

 

Thanks for any help,

 

Lorell Hathcock


From BEJones at semprautilities.com  Fri Nov 11 09:22:53 2011
From: BEJones at semprautilities.com (Jones, Barry)
Date: Fri, 11 Nov 2011 07:22:53 -0800
Subject: Firewalls - Ease of Use and Maintenance?
In-Reply-To: <4EBC82ED.6060603@brightok.net>
References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org>
 <CAHsqw9u4sZfsHarWh9VK-o1YSh=-BL7RjurXoR+2XVXaz6pufQ@mail.gmail.com>
 <4EBACD73.60609@foobar.org> <alpine.DEB.2.02.1111091405410.4911@sisler>
 <4EBAE62E.5090706@foobar.org>
 <CAAAwwbV77_OVrnd4ti+q7cnkinp5EbC+yxwQ7fkbETvdrx-9AQ@mail.gmail.com>
 <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org>
 <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org>
 <4EBC1405.5010007@gmail.com> <8252.1320949469@turing-police.cc.vt.edu>
 <4EBC82ED.6060603@brightok.net>
Message-ID: <E36EB8E60B5EB244AAFCFEF0AF0A116D0301794C7C@MS-EX7MB-P03.corp.se.sempra.com>

Hey all.
I wanted to say thanks for all the advice.

Barry

-----Original Message-----
From: Jack Bates [mailto:jbates at brightok.net] 
Sent: Thursday, November 10, 2011 6:06 PM
To: Valdis.Kletnieks at vt.edu
Cc: nanog at nanog.org
Subject: Re: Firewalls - Ease of Use and Maintenance?

On 11/10/2011 12:24 PM, Valdis.Kletnieks at vt.edu wrote:
> I think Rich has been around long enough that he gets called a*lot*  
> of things (many of them non-complimentary), but this is the first time 
> this century anybody's called him*naive*...;)

Given that all of humankind is naive, it would be redundant. The other things are much more entertaining.


Jack


From Valdis.Kletnieks at vt.edu  Fri Nov 11 09:56:18 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 11 Nov 2011 10:56:18 -0500
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: Your message of "Fri, 11 Nov 2011 00:15:46 MST."
 <F86D9C6F-9C85-46F9-8916-DCC44567BEE5@the-watsons.org>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com> <20111110135618.GA82609@ussenterprise.ufp.org>
 <F86D9C6F-9C85-46F9-8916-DCC44567BEE5@the-watsons.org>
Message-ID: <4387.1321026978@turing-police.cc.vt.edu>

On Fri, 11 Nov 2011 00:15:46 MST, Brett Watson said:

> Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6
> issues? (I'll just leave it at those three).

What multi-homing issues?  We've been multihomed on the IPv6 side for... ages.

And yes, there's some RA/DHCP issues - but the *practical* upshot is that it's
hard to DHCP a v6-only host and get stuff like DNS and NTP servers to them.  So
since our users are all dual-stack, we just DCHPv4 the DNS and such to them,
and it's not a major issue.  If they're on our wireless, they get a globally
routable IPv6 address and a NAT-ed IPv4, and DNS and such are available over
the IPv4, and mostly everything Just Works (modulo the NAT dain bramage, of
course). When we get a good DHCPv6, we'll roll it out.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111111/7227a4b5/attachment.bin>

From nick at foobar.org  Fri Nov 11 10:04:31 2011
From: nick at foobar.org (Nick Hilliard)
Date: Fri, 11 Nov 2011 16:04:31 +0000
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in
 one week)
In-Reply-To: <4387.1321026978@turing-police.cc.vt.edu>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com> <20111110135618.GA82609@ussenterprise.ufp.org>
 <F86D9C6F-9C85-46F9-8916-DCC44567BEE5@the-watsons.org>
 <4387.1321026978@turing-police.cc.vt.edu>
Message-ID: <4EBD478F.4040703@foobar.org>

On 11/11/2011 15:56, Valdis.Kletnieks at vt.edu wrote:
> And yes, there's some RA/DHCP issues - but the *practical* upshot is that it's
> hard to DHCP a v6-only host and get stuff like DNS and NTP servers to them.

another practical upshot is that switch manufacturers now need to support 
both RA Guard and DHCPv6 snooping instead of just a single protocol like we 
have in ipv4.  That is, unless you're ok with the idea of arbitrary 
priority RA packets floating around your network.

e.g. pages 9-16 of:

http://ripe63.ripe.net/presentations/220-ripe63_techteam.pdf

Nick


From bmanning at vacation.karoshi.com  Fri Nov 11 10:02:33 2011
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 11 Nov 2011 16:02:33 +0000
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <20111111145503.GA48535@ussenterprise.ufp.org>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com> <20111110135618.GA82609@ussenterprise.ufp.org>
 <F86D9C6F-9C85-46F9-8916-DCC44567BEE5@the-watsons.org>
 <20111111145503.GA48535@ussenterprise.ufp.org>
Message-ID: <20111111160233.GA5760@vacation.karoshi.com.>

On Fri, Nov 11, 2011 at 06:55:03AM -0800, Leo Bicknell wrote:
> 
> The networks I run have been dual stacked for 5+ years.  It works.
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/

	and I've been running single-stack IPv6 networks for 4+ years.
	IVI is a wonderful thing.   Dual stack kind of implies you still 
	need IPv4 for -EVERY- node. :)  whoops!  Guess there is a need for
	NAT after all, eh?   (now promises to stop meing snarky and STFU)


/bill



From owen at delong.com  Fri Nov 11 12:44:36 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 11 Nov 2011 10:44:36 -0800
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: <20111111160233.GA5760@vacation.karoshi.com.>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com> <20111110135618.GA82609@ussenterprise.ufp.org>
 <F86D9C6F-9C85-46F9-8916-DCC44567BEE5@the-watsons.org>
 <20111111145503.GA48535@ussenterprise.ufp.org>
 <20111111160233.GA5760@vacation.karoshi.com.>
Message-ID: <EC1A8AE9-D05C-4224-B6D8-27F39A8B0780@delong.com>


On Nov 11, 2011, at 8:02 AM, bmanning at vacation.karoshi.com wrote:

> On Fri, Nov 11, 2011 at 06:55:03AM -0800, Leo Bicknell wrote:
>> 
>> The networks I run have been dual stacked for 5+ years.  It works.
>> 
>> -- 
>>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>>        PGP keys at http://www.ufp.org/~bicknell/
> 
> 	and I've been running single-stack IPv6 networks for 4+ years.
> 	IVI is a wonderful thing.   Dual stack kind of implies you still 
> 	need IPv4 for -EVERY- node. :)  whoops!  Guess there is a need for
> 	NAT after all, eh?   (now promises to stop meing snarky and STFU)
> 

Dual stack implies that you have IPv4 for some subset of the nodes.
It says nothing about need. It says nothing about percentage of the
nodes that are dual stacked.

Owen



From Valdis.Kletnieks at vt.edu  Fri Nov 11 13:11:20 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 11 Nov 2011 14:11:20 -0500
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one
 week)
In-Reply-To: Your message of "Fri, 11 Nov 2011 16:04:31 GMT."
 <4EBD478F.4040703@foobar.org>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com> <20111110135618.GA82609@ussenterprise.ufp.org>
 <F86D9C6F-9C85-46F9-8916-DCC44567BEE5@the-watsons.org>
 <4387.1321026978@turing-police.cc.vt.edu>
 <4EBD478F.4040703@foobar.org>
Message-ID: <4923.1321038680@turing-police.cc.vt.edu>

On Fri, 11 Nov 2011 16:04:31 GMT, Nick Hilliard said:
> another practical upshot is that switch manufacturers now need to support 
> both RA Guard and DHCPv6 snooping instead of just a single protocol like we 
> have in ipv4.  That is, unless you're ok with the idea of arbitrary 
> priority RA packets floating around your network.

When did I ever say I was "OK with the idea"?

Our single biggest network security issue is the fact that every day, one or
two dozen of our users manage to get phished or hit by a drive-by, have their
credentials stolen, and then often get used to send through enough spam to land
us on various block lists, at which point the NANOG lurker in the next cubicle
has a Bad Day because he's part our e-mail team.  Most of the time we catch it,
and the user has a Bad Day because they have to deal with the fallout of
getting compromised.  But this stuff would happen if it was IPv4, IPv6,
IPv5.437 or tin-can-and-string.

RA Guard is so far down the list of *actual* day to day net operations issues
it's not funny.  I think the the last time we had to put the smackdown on
somebody advertising 2002: was like a year ago.  Yes, RA Guard is a
consideration.  But the subnets we *really* care about are more-or-less
physically secure, and the hosts are secure, so we don't see many RA games on
critical subnets unless we've *already* got a critical security event in
progress.  Dorms and the like are easier to RA-spoof - but our switches are all
managed, the symptoms of an RA issue are known to our NOC, and when we have an
issue, the offending port suddenly loses link. ;)

Would it be *nice* to have RA Guard and DHCP6 snooping in place? Yes.  Is it
totally impossible to deploy IPv6 until they're fully baked? Not at all - just
need to be aware of the issues and be prepared to mitigate.  Sure it raises the
risk level slightly - but we judge the risks of not being well-positioned for
IPv6 to be *much* higher.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111111/3aab9e4b/attachment.bin>

From cscora at apnic.net  Fri Nov 11 13:18:23 2011
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 12 Nov 2011 05:18:23 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201111111918.pABJINS6030367@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 12 Nov, 2011

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              381658
    Prefixes after maximum aggregation:                          166539
    Deaggregation factor:                                          2.29
    Unique aggregates announced to Internet:                     187635
Total ASes present in the Internet Routing Table:                 39286
    Prefixes per ASN:                                              9.71
Origin-only ASes present in the Internet Routing Table:           32382
Origin ASes announcing only one prefix:                           15485
Transit ASes present in the Internet Routing Table:                5290
Transit-only ASes present in the Internet Routing Table:            133
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      33
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:              1677
    Unregistered ASNs in the Routing Table:                         881
Number of 32-bit ASNs allocated by the RIRs:                       1940
Number of 32-bit ASNs visible in the Routing Table:                1614
Prefixes from 32-bit ASNs in the Routing Table:                    3721
Special use prefixes present in the Routing Table:                    3
Prefixes being announced from unallocated address space:             87
Number of addresses announced to Internet:                   2490142976
    Equivalent to 148 /8s, 108 /16s and 145 /24s
    Percentage of available address space announced:               67.2
    Percentage of allocated address space announced:               67.2
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               91.6
Total number of prefixes smaller than registry allocations:      161365

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    95008
    Total APNIC prefixes after maximum aggregation:               31143
    APNIC Deaggregation factor:                                    3.05
Prefixes being announced from the APNIC address blocks:           91456
    Unique aggregates announced from the APNIC address blocks:    38380
APNIC Region origin ASes present in the Internet Routing Table:    4602
    APNIC Prefixes per ASN:                                       19.87
APNIC Region origin ASes announcing only one prefix:               1269
APNIC Region transit ASes present in the Internet Routing Table:    720
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         21
Number of APNIC region 32-bit ASNs visible in the Routing Table:    107
Number of APNIC addresses announced to Internet:              629934432
    Equivalent to 37 /8s, 140 /16s and 9 /24s
    Percentage of available APNIC address space announced:         79.9

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
                       182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
                       219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    146101
    Total ARIN prefixes after maximum aggregation:                74287
    ARIN Deaggregation factor:                                     1.97
Prefixes being announced from the ARIN address blocks:           118152
    Unique aggregates announced from the ARIN address blocks:     48520
ARIN Region origin ASes present in the Internet Routing Table:    14740
    ARIN Prefixes per ASN:                                         8.02
ARIN Region origin ASes announcing only one prefix:                5637
ARIN Region transit ASes present in the Internet Routing Table:    1565
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          25
Number of ARIN region 32-bit ASNs visible in the Routing Table:      12
Number of ARIN addresses announced to Internet:               804207808
    Equivalent to 47 /8s, 239 /16s and 60 /24s
    Percentage of available ARIN address space announced:          63.9

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 173/8,
                       174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8,
                       208/8, 209/8, 214/8, 215/8, 216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                     92019
    Total RIPE prefixes after maximum aggregation:                51066
    RIPE Deaggregation factor:                                     1.80
Prefixes being announced from the RIPE address blocks:            84487
    Unique aggregates announced from the RIPE address blocks:     54587
RIPE Region origin ASes present in the Internet Routing Table:    16107
    RIPE Prefixes per ASN:                                         5.25
RIPE Region origin ASes announcing only one prefix:                7977
RIPE Region transit ASes present in the Internet Routing Table:    2539
Average RIPE Region AS path length visible:                         4.7
    Max RIPE Region AS path length visible:                          33
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1119
Number of RIPE addresses announced to Internet:               491921856
    Equivalent to 29 /8s, 82 /16s and 33 /24s
    Percentage of available RIPE address space announced:          79.2

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   36135
    Total LACNIC prefixes after maximum aggregation:               7921
    LACNIC Deaggregation factor:                                   4.56
Prefixes being announced from the LACNIC address blocks:          35567
    Unique aggregates announced from the LACNIC address blocks:   18567
LACNIC Region origin ASes present in the Internet Routing Table:   1549
    LACNIC Prefixes per ASN:                                      22.96
LACNIC Region origin ASes announcing only one prefix:               446
LACNIC Region transit ASes present in the Internet Routing Table:   286
Average LACNIC Region AS path length visible:                       4.5
    Max LACNIC Region AS path length visible:                        18
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   372
Number of LACNIC addresses announced to Internet:              92919936
    Equivalent to 5 /8s, 137 /16s and 216 /24s
    Percentage of available LACNIC address space announced:        61.5

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   8487
    Total AfriNIC prefixes after maximum aggregation:              2043
    AfriNIC Deaggregation factor:                                  4.15
Prefixes being announced from the AfriNIC address blocks:          6576
    Unique aggregates announced from the AfriNIC address blocks:   2022
AfriNIC Region origin ASes present in the Internet Routing Table:   496
    AfriNIC Prefixes per ASN:                                     13.26
AfriNIC Region origin ASes announcing only one prefix:              156
AfriNIC Region transit ASes present in the Internet Routing Table:  106
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    4
Number of AfriNIC addresses announced to Internet:             27687168
    Equivalent to 1 /8s, 166 /16s and 121 /24s
    Percentage of available AfriNIC address space announced:       41.3

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2510      11108         968   Korea Telecom (KIX)
17974     1649        511          36   PT TELEKOMUNIKASI INDONESIA
 7545     1625        303          88   TPG Internet Pty Ltd
 4755     1544        377         172   TATA Communications formerly 
 7552     1394       1064           7   Vietel Corporation
 9829     1166        989          28   BSNL National Internet Backbo
 9583     1116         83         512   Sify Limited
 4808     1093       2095         313   CNCGROUP IP network: China169
24560      964        343         218   Bharti Airtel Ltd., Telemedia
18101      953        119         149   Reliance Infocom Ltd Internet

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3544       3814         219   bellsouth.net, inc. 
 7029     2918       1016         199   Windstream Communications Inc
18566     2093        383         177   Covad Communications 
 1785     1847        680         122   PaeTec Communications, Inc.
 4323     1622       1077         387   Time Warner Telecom
20115     1595       1545         624   Charter Communications 
22773     1495       2909         102   Cox Communications, Inc.
30036     1415        255         671   Mediacom Communications Corp 
19262     1395       4728         400   Verizon Global Networks 
 7018     1314       7029         862   AT&T WorldNet Services

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1519        416          14   Corbina telecom
 6830      646       1927         411   UPC Distribution Services
34984      596        110         184   BILISIM TELEKOM
20940      551        182         433   Akamai Technologies European 
 3320      503       8168         388   Deutsche Telekom AG
 3292      479       2074         407   TDC Tele Danmark
12479      479        596           9   Uni2 Autonomous System
 8866      463        133          26   Bulgarian Telecommunication C
31148      408         22         114   FreeNet ISP
 8551      402        354          43   Bezeq International

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1706        316         157   TVCABLE BOGOTA 
28573     1490       1043          79   NET Servicos de Comunicao S.A
 8151     1446       2937         346   UniNet S.A. de C.V. 
 7303     1238        751         173   Telecom Argentina Stet-France
27947      591         72          84   Telconet S.A
22047      580        322          17   VTR PUNTO NET S.A. 
 6503      566        434          68   AVANTEL, S.A. 
 7738      553       1050          31   Telecomunicacoes da Bahia S.A
 3816      539        234          96   Empresa Nacional de Telecomun
11172      525         85          95   Servicios Alestra S.A de C.V 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
24863      716        146          36   LINKdotNET AS number
 8452      665        446          12   TEDATA
15475      444         74           8   Nile Online
36992      285        415          20   Etisalat MISR
 3741      281        939         230   The Internet Solution 
15706      240         32           6   Sudatel Internet Exchange Aut
33776      239         13           8   Starcomms Nigeria Limited
 6713      235        519          14   Itissalat Al-MAGHRIB
29571      218         17          13   Ci Telecom Autonomous system 
12258      196         28          57   Vodacom Internet Company 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3544       3814         219   bellsouth.net, inc. 
 7029     2918       1016         199   Windstream Communications Inc
 4766     2510      11108         968   Korea Telecom (KIX)
18566     2093        383         177   Covad Communications 
 1785     1847        680         122   PaeTec Communications, Inc.
10620     1706        316         157   TVCABLE BOGOTA 
17974     1649        511          36   PT TELEKOMUNIKASI INDONESIA
 7545     1625        303          88   TPG Internet Pty Ltd
 4323     1622       1077         387   Time Warner Telecom
20115     1595       1545         624   Charter Communications 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 7029      2918        2719      Windstream Communications Inc
18566      2093        1916      Covad Communications 
 1785      1847        1725      PaeTec Communications, Inc.
17974      1649        1613      PT TELEKOMUNIKASI INDONESIA
10620      1706        1549      TVCABLE BOGOTA 
 4766      2510        1542      Korea Telecom (KIX)
 7545      1625        1537      TPG Internet Pty Ltd
 8402      1519        1505      Corbina telecom
28573      1490        1411      NET Servicos de Comunicao S.A
22773      1495        1393      Cox Communications, Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23       10912       InterNAP Network Ser

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.0.0/16         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
24.225.128.0/18      36377     Comcast Telecommunications, I
24.225.192.0/23      36377     Comcast Telecommunications, I
24.225.192.0/18      36377     Comcast Telecommunications, I
24.225.224.0/21      36377     Comcast Telecommunications, I
24.225.237.0/24      36377     Comcast Telecommunications, I
24.225.248.0/21      36377     Comcast Telecommunications, I
41.222.79.0/24       37345     MEDALLION Communications
41.223.92.0/22       36936     >>UNKNOWN<<
62.61.220.0/24       24974     Tachyon Europe BV - Wireless 
62.61.221.0/24       24974     Tachyon Europe BV - Wireless 

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:19       /9:12      /10:27      /11:81      /12:236     
/13:465     /14:808     /15:1422    /16:12006   /17:6064    /18:10089   
/19:19963   /20:27615   /21:27723   /22:37556   /23:35208   /24:198912  
/25:1154    /26:1364    /27:759     /28:166     /29:4       /30:0       
/31:0       /32:5       

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 7029     2548          2918      Windstream Communications Inc
 6389     2185          3544      bellsouth.net, inc. 
18566     2042          2093      Covad Communications 
10620     1601          1706      TVCABLE BOGOTA 
 8402     1495          1519      Corbina telecom
30036     1375          1415      Mediacom Communications Corp 
11492     1117          1154      Cable One 
 1785     1057          1847      PaeTec Communications, Inc.
 7011     1051          1168      Citizens Utilities 
22773      958          1495      Cox Communications, Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:408       2:484       4:15        5:1         6:3         8:356    
  12:1966     13:1        14:547      15:11       16:3        17:7      
  20:9        23:63       24:1683     27:1031     31:675      32:65     
  33:2        34:2        36:4        38:756      39:1        40:110    
  41:2681     42:59       43:1        44:3        46:1050     47:3      
  49:298      50:449      52:13       55:8        56:2        57:47     
  58:920      59:496      60:362      61:1131     62:1094     63:1970   
  64:4065     65:2302     66:4319     67:2019     68:1174     69:3142   
  70:905      71:387      72:1820     74:2633     75:430      76:319    
  77:881      78:887      79:479      80:1133     81:836      82:516    
  83:518      84:621      85:1154     86:400      87:931      88:356    
  89:1591     90:235      91:4257     92:536      93:1553     94:1303   
  95:1089     96:427      97:286      98:943      99:37      101:233    
 103:459     106:7       107:91      108:76      109:1184    110:671    
 111:807     112:362     113:480     114:623     115:715     116:881    
 117:722     118:889     119:1266    120:345     121:681     122:1574   
 123:1019    124:1353    125:1355    128:246     129:184     130:164    
 131:616     132:151     133:21      134:221     135:54      136:213    
 137:142     138:287     139:121     140:494     141:253     142:389    
 143:401     144:495     145:64      146:470     147:219     148:638    
 149:270     150:164     151:194     152:449     153:172     154:7      
 155:387     156:208     157:361     158:155     159:489     160:331    
 161:214     162:374     163:173     164:506     165:368     166:544    
 167:443     168:820     169:145     170:881     171:87      172:4      
 173:1742    174:702     175:432     176:297     177:367     178:1100   
 180:1145    181:38      182:652     183:236     184:393     185:1      
 186:1401    187:774     188:963     189:1157    190:5188    192:5923   
 193:5050    194:3554    195:3109    196:1268    197:170     198:3617   
 199:4206    200:5475    201:1704    202:8553    203:8538    204:4311   
 205:2370    206:2668    207:2816    208:4025    209:3584    210:2711   
 211:1463    212:2074    213:1804    214:777     215:96      216:4930   
 217:1601    218:560     219:343     220:1257    221:515     222:324    
 223:272    

End of report


From jbates at brightok.net  Fri Nov 11 14:10:32 2011
From: jbates at brightok.net (Jack Bates)
Date: Fri, 11 Nov 2011 14:10:32 -0600
Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in
 one week)
In-Reply-To: <4923.1321038680@turing-police.cc.vt.edu>
References: <4E9F20FF.1070203@arin.net>
 <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net>
 <20111109155633.GA21891@ussenterprise.ufp.org> <m2sjlwqzx8.wl%randy@psg.com>
 <CAP-guGWddV1LVEbfu7MJzOq+h98pUoiDBZtAeLC6NiTWbVPBUw@mail.gmail.com>
 <m2ty6cp0ml.wl%randy@psg.com> <20111110135618.GA82609@ussenterprise.ufp.org>
 <F86D9C6F-9C85-46F9-8916-DCC44567BEE5@the-watsons.org>
 <4387.1321026978@turing-police.cc.vt.edu> <4EBD478F.4040703@foobar.org>
 <4923.1321038680@turing-police.cc.vt.edu>
Message-ID: <4EBD8138.70408@brightok.net>



On 11/11/2011 1:11 PM, Valdis.Kletnieks at vt.edu wrote:
> Would it be*nice*  to have RA Guard and DHCP6 snooping in place? Yes.  Is it
> totally impossible to deploy IPv6 until they're fully baked? Not at all - just
> need to be aware of the issues and be prepared to mitigate.  Sure it raises the
> risk level slightly - but we judge the risks of not being well-positioned for
> IPv6 to be*much*  higher.

 From a DSLAM perspective, the security stuff was annoying and often 
just broke IPv6 all together. I am still a fan of 1 vlan per user and 
q-in-q. It does have issues in dorm type scenarios where you might not 
want to bring local traffic all the way back to l3 termination, though.


Jack


From cidr-report at potaroo.net  Fri Nov 11 16:00:01 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 11 Nov 2011 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201111112200.pABM01Lo023491@wattle.apnic.net>

BGP Update Report
Interval: 03-Nov-11 -to- 09-Nov-11 (6 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9829            50212  2.8%      50.7 -- BSNL-NIB National Internet Backbone
 2 - AS8402            26154  1.5%      22.0 -- CORBINA-AS OJSC "Vimpelcom"
 3 - AS6316            25706  1.5%     659.1 -- AS-PAETEC-NET - PaeTec Communications, Inc.
 4 - AS32528           24976  1.4%   12488.0 -- ABBOTT Abbot Labs
 5 - AS27738           24092  1.4%      70.9 -- Ecuadortelecom S.A.
 6 - AS20632           19812  1.1%    1981.2 -- PETERSTAR-AS PeterStar
 7 - AS24722           17705  1.0%     260.4 -- BABILON-AS Babilon-T
 8 - AS9498            17067  1.0%      28.5 -- BBIL-AP BHARTI Airtel Ltd.
 9 - AS7552            16942  1.0%      12.2 -- VIETEL-AS-AP Vietel Corporation
10 - AS4274            15310  0.9%     189.0 -- ERX-AU-NET Assumption University
11 - AS45595           13295  0.8%      49.6 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited
12 - AS16916           12798  0.7%     752.8 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC
13 - AS5800            12743  0.7%      49.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
14 - AS8866            10934  0.6%     218.7 -- BTC-AS Bulgarian Telecommunication Company Plc.
15 - AS47331           10442  0.6%       4.6 -- TTNET TTNet A.S.
16 - AS4766            10388  0.6%       4.4 -- KIXS-AS-KR Korea Telecom
17 - AS28573            9590  0.5%      12.8 -- NET Servicos de Comunicao S.A.
18 - AS24560            9494  0.5%      12.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
19 - AS7029             8930  0.5%       3.6 -- WINDSTREAM - Windstream Communications Inc
20 - AS9649             8751  0.5%     182.3 -- MOPH-TH-AP Information Technology Office


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS32528           24976  1.4%   12488.0 -- ABBOTT Abbot Labs
 2 - AS17408            3281  0.2%    3281.0 -- ABOVE-AS-AP AboveNet Communications Taiwan
 3 - AS20632           19812  1.1%    1981.2 -- PETERSTAR-AS PeterStar
 4 - AS8499             1192  0.1%    1192.0 -- Space Hellas S.A.
 5 - AS9562             8166  0.5%    1166.6 -- MSU-TH-AP Mahasarakham University
 6 - AS44075            1046  0.1%    1046.0 -- GCCNGN GCCNGN AS
 7 - AS17425            4074  0.2%    1018.5 -- EPA-AS-TH Provincial Electricity Authority of Thailand.
 8 - AS16916           12798  0.7%     752.8 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC
 9 - AS10099             742  0.0%     742.0 -- HKUNICOM1-AP China Unicom (Hong Kong) Operations Limited
10 - AS6316            25706  1.5%     659.1 -- AS-PAETEC-NET - PaeTec Communications, Inc.
11 - AS47859             635  0.0%     635.0 -- CLEORON Cleoron Alliance LTD.
12 - AS46983             527  0.0%     527.0 -- SAML-ASN - Southpaw Asset Management LP
13 - AS50977            3656  0.2%     522.3 -- ESYCOR-AS ESYCOR S.A.
14 - AS18409            2598  0.1%     519.6 -- BOT-TH-AS Bank of Thailand, Bangkok, Thailand
15 - AS55696            1004  0.1%     502.0 -- SCOM-AS-ID Starcom Solusindo PT.
16 - AS16898             488  0.0%     488.0 -- LOG-NET - Global Technology Services, Ltd.
17 - AS48068             486  0.0%     486.0 -- VISONIC Visonic Ltd
18 - AS10445            1894  0.1%     473.5 -- HTG - Huntleigh Telcom
19 - AS16391             473  0.0%     473.0 -- CELITO-1 - Celito Communications Inc.
20 - AS3738             1379  0.1%     459.7 -- SSB-ASN - State Street Bank and Trust Company


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 84.204.132.0/24   19734  1.1%   AS20632 -- PETERSTAR-AS PeterStar
 2 - 206.80.93.0/24    12756  0.7%   AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC
 3 - 202.92.235.0/24   12739  0.7%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 4 - 130.36.34.0/24    12488  0.7%   AS32528 -- ABBOTT Abbot Labs
 5 - 130.36.35.0/24    12488  0.7%   AS32528 -- ABBOTT Abbot Labs
 6 - 213.16.48.0/24    10728  0.6%   AS8866  -- BTC-AS Bulgarian Telecommunication Company Plc.
 7 - 66.248.104.0/21    8529  0.5%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 8 - 66.248.120.0/21    8523  0.5%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
 9 - 66.248.96.0/21     8517  0.5%   AS6316  -- AS-PAETEC-NET - PaeTec Communications, Inc.
10 - 221.183.16.0/23    4245  0.2%   AS65500 -- -Private Use AS-
                                     AS9808  -- CMNET-GD Guangdong Mobile Communication Co.Ltd.
11 - 202.153.174.0/24   3281  0.2%   AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan
12 - 217.52.130.0/24    2525  0.1%   AS15475 -- NOL
                                     AS36992 -- ETISALAT-MISR
13 - 110.164.24.0/24    2040  0.1%   AS9562  -- MSU-TH-AP Mahasarakham University
14 - 110.164.25.0/24    2040  0.1%   AS9562  -- MSU-TH-AP Mahasarakham University
15 - 110.164.27.0/24    2040  0.1%   AS9562  -- MSU-TH-AP Mahasarakham University
16 - 110.164.26.0/24    2040  0.1%   AS9562  -- MSU-TH-AP Mahasarakham University
17 - 202.151.6.0/24     2036  0.1%   AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand.
18 - 202.151.7.0/24     2036  0.1%   AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand.
19 - 59.99.0.0/20       1780  0.1%   AS9829  -- BSNL-NIB National Internet Backbone
20 - 117.228.0.0/20     1779  0.1%   AS9829  -- BSNL-NIB National Internet Backbone

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Nov 11 16:00:00 2011
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 11 Nov 2011 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201111112200.pABM00uW023486@wattle.apnic.net>

This report has been generated at Fri Nov 11 21:12:18 2011 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        04-11-11    382870      224714
        05-11-11    383079      224693
        06-11-11    382973      224818
        07-11-11    383132      224645
        08-11-11    383213      224878
        09-11-11    383651      224771
        10-11-11    383571      224523
        11-11-11    383517      224623


AS Summary
         39387  Number of ASes in routing system
         16620  Number of ASes announcing only one prefix
          3544  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      108825600  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 11Nov11 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     383910   224980   158930    41.4%   All ASes

AS6389      3544      222     3322    93.7%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS18566     2093      406     1687    80.6%   COVAD - Covad Communications
                                               Co.
AS4766      2514      993     1521    60.5%   KIXS-AS-KR Korea Telecom
AS7029      2959     1541     1418    47.9%   WINDSTREAM - Windstream
                                               Communications Inc
AS22773     1495      112     1383    92.5%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4755      1539      230     1309    85.1%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS4323      1623      389     1234    76.0%   TWTC - tw telecom holdings,
                                               inc.
AS1785      1850      782     1068    57.7%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS28573     1485      425     1060    71.4%   NET Servicos de Comunicao S.A.
AS19262     1395      400      995    71.3%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS7552      1394      423      971    69.7%   VIETEL-AS-AP Vietel
                                               Corporation
AS10620     1706      757      949    55.6%   Telmex Colombia S.A.
AS7303      1238      333      905    73.1%   Telecom Argentina S.A.
AS18101      954      150      804    84.3%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS8151      1447      667      780    53.9%   Uninet S.A. de C.V.
AS4808      1093      344      749    68.5%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS30036     1415      676      739    52.2%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS7545      1625      947      678    41.7%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS3356      1107      457      650    58.7%   LEVEL3 Level 3 Communications
AS17974     1648     1014      634    38.5%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS24560      964      347      617    64.0%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS8402      1428      818      610    42.7%   CORBINA-AS OJSC "Vimpelcom"
AS20115     1595      996      599    37.6%   CHARTER-NET-HKY-NC - Charter
                                               Communications
AS4804       691       93      598    86.5%   MPX-AS Microplex PTY LTD
AS17676      664       70      594    89.5%   GIGAINFRA Softbank BB Corp.
AS3549      1027      454      573    55.8%   GBLX Global Crossing Ltd.
AS22561      933      373      560    60.0%   DIGITAL-TELEPORT - Digital
                                               Teleport Inc.
AS22047      580       33      547    94.3%   VTR BANDA ANCHA S.A.
AS17488      946      401      545    57.6%   HATHWAY-NET-AP Hathway IP Over
                                               Cable Internet
AS7011      1168      646      522    44.7%   FRONTIER-AND-CITIZENS -
                                               Frontier Communications of
                                               America, Inc.

Total      44120    15499    28621    64.9%   Top 30 total


Possible Bogus Routes

        5.0.0.0/16           AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        5.1.0.0/21           AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        5.1.24.0/24          AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        41.222.79.0/24       AS37345 MEDALLION
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.171.32.0/20       AS705   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.206.47.0/24       AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        69.6.80.0/24         AS13442 
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        80.88.10.0/24        AS33774 DJAWEB
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.45.1.0/24        AS29571 CITelecom-AS
        172.45.2.0/24        AS29571 CITelecom-AS
        172.45.3.0/24        AS29571 CITelecom-AS
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        185.0.0.0/16         AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        185.1.0.0/21         AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        185.24.0.0/24        AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS26061 Equant Colombia
        200.24.78.0/26       AS3549  GBLX Global Crossing Ltd.
        200.24.78.64/26      AS3549  GBLX Global Crossing Ltd.
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.131.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        202.179.144.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        203.175.107.0/24     AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A.
        205.207.148.0/23     AS812   ROGERS-CABLE - Rogers Cable Communications Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - Knology Holdings
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc.
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc.
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc.
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        208.64.240.0/21      AS13871 TELEBYTE-NW - Telebyte NW
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From owen at impulse.net  Fri Nov 11 16:01:47 2011
From: owen at impulse.net (Owen Roth)
Date: Fri, 11 Nov 2011 14:01:47 -0800 (PST)
Subject: Edgecast network issues seen in combination with lowered MTU
In-Reply-To: <41596952.419621.1321046344544.JavaMail.root@lavender.impulse.net>
Message-ID: <1398278335.419780.1321048907409.JavaMail.root@lavender.impulse.net>

Hello,

I had an issue with lowered MTU through a portion of my network, and besides the expected impact, some clients were unable to access resources either directly hosted or indirectly served content by EdgeCast Networks (had to look at traceroutes and view source to determine). I also found nodes that weren't pingable, and didn't appear to have ICMP unreachables available but no directly impacted end-to-end lowered MTU was visible.

It seems to be a PathMTU issue or a weird unidirectional MTU issue (?). I have fixed the lowered MTU, and so restored connectivity to affected users -- this is not a current problem but still an incipient one. I consulted with EdgeCast NOC in this matter, but it is hard to demonstrate a <1% problem when it isn't apparent from every other network. Or they may have contracted clue-immunity, it's hard to tell.

I've used MTUroute/TCProute and "ping a.b.c.d df-bit size 1500". That did NOT show an issue, 1500 bytes were pingable from the customer end and edge router. Given that I know it was an MTU issue, as that's how I patched and then fixed it, is there another tool that would detect whatever this is?

Has anyone else seen this compound problem with EdgeCast Networks?

Is "ICMP unreachables" ON to NOT break PMTUD per RFC, still best practice or has that drifted?

Regards,
Owen





From jlewis at packetnexus.com  Sun Nov 13 09:36:43 2011
From: jlewis at packetnexus.com (Jason Lewis)
Date: Sun, 13 Nov 2011 10:36:43 -0500
Subject: Arguing against using public IP space
Message-ID: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>

I don't want to start a flame war, but this article seems flawed to
me.  It seems an IP is an IP.

http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html

I think I could announce private IP space, so doesn't that make this
argument invalid?  I've always looked at private IP space as more of a
resource and management choice and not a security feature.


From bonomi at mail.r-bonomi.com  Sun Nov 13 10:38:50 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sun, 13 Nov 2011 10:38:50 -0600 (CST)
Subject: Arguing against using public IP space
In-Reply-To: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
Message-ID: <201111131638.pADGcoiu007448@mail.r-bonomi.com>


On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis <jlewis at packetnexus.com> wrote;
>
> I don't want to start a flame war, but this article seems flawed to
> me. 

Any article that claims a /12 is a 'class B', and a /16 is a 'Class C', is
DEFINITELY 'flawed'.

>       It seems an IP is an IP.

True.  *BUT*, "some IP's are more equal than others", as Orwell would say.
>
> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>
> I think I could announce private IP space, so doesn't that make this
> argument invalid? 

You likely would have a 'rude surprise' if you actually tried it.

It is an express violation of RFCs to announce routing for RFC-1918 space
-outside- of your own network.

In addition, virtually _every_ ASN operator has ingress filters on their 
border routers to block almost all traffic to RFC-1918 destinations.

"Good net neighbor" operators also run egress filters that block almost all
outbound traffic with RFC-1918 _source_ addresses -- things like icmp 'un-
reachables' are an exception.

>                    I've always looked at private IP space as more of a
> resource and management choice and not a security feature.
>


From rdobbins at arbor.net  Sun Nov 13 10:42:16 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sun, 13 Nov 2011 16:42:16 +0000
Subject: Arguing against using public IP space
In-Reply-To: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
Message-ID: <B9AEE1BF-E963-4B79-A705-D12301E7A823@arbor.net>


On Nov 13, 2011, at 10:36 PM, Jason Lewis wrote:

> I don't want to start a flame war, but this article seems flawed to me. 

The real issue is interconnecting SCADA systems to publicly-routed networks, not the choice of potentially routable space vs. RFC1918 space for SCADA networks, per se.  If I've an RFC1918-addressed SCADA network which is interconnected to a publicly-routed- and -accessible network, then an attacker can work to compromise a host on the publicly-accessible network and then jump from there to the RFC1918 SCADA network. 

> I think I could announce private IP space, so doesn't that make this argument invalid? 

Most networks, except those which haven't implemented the most basic BCPs, wouldn't accept your announcements of RFC1918 or otherwise-reserved space.  It's likely that your peers/upstreams wouldn't accept them in the first place, much less propagate them.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From davidianwalker at gmail.com  Sun Nov 13 11:21:38 2011
From: davidianwalker at gmail.com (David Walker)
Date: Mon, 14 Nov 2011 03:51:38 +1030
Subject: Arguing against using public IP space
In-Reply-To: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
Message-ID: <CABE=bRNUs8S6Xvje5sjnYhbSuaRisocBwnww96U9iXyfgK-CSw@mail.gmail.com>

On 14/11/2011, Jason Lewis <jlewis at packetnexus.com> wrote:
> I don't want to start a flame war,

If you didn't write it I wouldn't stress about that.

> but this article seems flawed to
> me.

Me too.

>  It seems an IP is an IP.

Yes but in IPv4 land there is a difference although probably not in
the way the author "suggests".
The non-routability of the private address space is dependent on the
good sense of router manufacturers and although these days that's
probably guaranteed the impression I get is some dumb SCADA network
guy is expected to go "oh, private address, intrinsically secure" or
"oh, public address, intrinsically insecure, hmm, all my edge devices
are owned and beyond help".
Hehe.

> I think I could announce private IP space,

Exactly but it would never get legs.

> so doesn't that make this
> argument invalid?

I think there are much better reasons why the article is invalid and
ultimately irrelevant and weird.

I know this is contentious so I'll clarify it  ...
NAT is not a security feature.
Any perceived benefit is from the state table ... which any packet
filter can duplicate.
NATting is not the issue but the allow/deny situation based on the state table.
More importantly though, other than DOS (presuming less bandwidth
inside than out) or attacks on a host's TCP/IP stack (maybe SCADA
suffers here), what's important is services hanging on ports and any
vulnerabilities they have - which, by design are passed whether you
NAT or not (we want people to talk to our web server).
Has any one ever been cracked on their web browser or email client or
whatever by something that was preventable at the lower layers with a
default deny all in rule ...
Never.
The only issue for clients in that respect is spoofing and so on ...
which NAT passes as well as (or more openly than) any packet filter
...
Any good packet filter can help there but that's strictly a packet
filtering feature and nothing to do with NAT.
By definition alone, NAT is useless here.
Some of the finer points argue against NAT entirely.
http://www.ietf.org/rfc/rfc4966.txt (security considerations)

Extending that, there could be some filtering somewhere.
On the host, on the edge.
A packet filter (ipso facto more relevant than a network address
translator) is the tool of choice.
Regardless, all that matters is vulnerability in services.
I could never imagine writing an article about NAT (or translation) in
a security context other than to say "focus on the real issues".

It's all kind of backward too.
IPv6 anyone?
Surely SCADA is the prima facie example of "everyone's light bulb
connected to the internet".
Where's Vint Cerf when you need him ...

Besides ...
... who uses Classes any more?

:]

>  I've always looked at private IP space as more of a
> resource and management choice and not a security feature.
>
>

Right on ...

... and those SCADA guys have got important issues to worry about.

Best wishes.


From mysidia at gmail.com  Sun Nov 13 11:48:06 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 13 Nov 2011 11:48:06 -0600
Subject: Arguing against using public IP space
In-Reply-To: <201111131638.pADGcoiu007448@mail.r-bonomi.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
Message-ID: <CAAAwwbXtyaALM=vi2iUM1rS-QfvPRB9DhyKW2K-BK_-sQyP2vw@mail.gmail.com>

On Sun, Nov 13, 2011 at 10:38 AM, Robert Bonomi
<bonomi at mail.r-bonomi.com> wrote:
> On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis <jlewis at packetnexus.com> wrote;
> In addition, virtually _every_ ASN operator has ingress filters on their
> border routers to block almost all traffic to RFC-1918 destinations.

Well, when we are talking about selection of IP addresses as a
supposed security feature...
the view that "your ASN operator probably has ingress filters"  is an
optimistic one.
The relevant question if you expect "private IP" to be a security
feature is:  "Can you legitimately rely on your ASN operator having
ingress filters on border routers to block your RFC1918 destinations
from remote access" ?

And the proper answer is NO,  you cannot rely on that;  if your
network design relies on this assumption, then it is not secure.  If
your router is compromised,  an intruder can announce your private
RFC1918 IP address space through a tunnel.

If an intruder is a conspirator with one of your peer networks,  they
can conspire with your peer to allow an RFC1918 announcement from your
network.

Or create a static route for a RFC1918 subnet on your network.

In other words, your use of RFC1918 address space alone does not
create security.   Your RFC1918 network actually _does_  need
isolation  separate and apart from the address space,  for you to have
reliable security,  you still need a firewall,  proxy, or NAT device
of some form,  with the private network isolated from the public one,
even when using private IPs.

--
-JH


From leigh.porter at ukbroadband.com  Sun Nov 13 12:50:55 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Sun, 13 Nov 2011 18:50:55 +0000
Subject: Arguing against using public IP space
In-Reply-To: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
Message-ID: <7814062A-B014-48D7-9D1A-37E7DD5C09EF@ukbroadband.com>

I was involved in a security review of a SCADA system a couple of years ago. Their guy was very impressed with himself and his "Internet air-gap" but managed to leave all their ops consoles on both the SCADA network and their internal corp LAN.

Their corp LAN was a mess with holes through their NAT gateway all over the place to let external support people rdesktop to the SCADA network machines.

Of course it was all on private address space internally. 

So you see, when you put idiots in charge, your screwed whatever you do and private address space and NAT and whatever else will be no more then security by nice stickers and marketing.

-- 
Leigh


On 13 Nov 2011, at 15:38, "Jason Lewis" <jlewis at packetnexus.com> wrote:

> I don't want to start a flame war, but this article seems flawed to
> me.  It seems an IP is an IP.
> 
> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
> 
> I think I could announce private IP space, so doesn't that make this
> argument invalid?  I've always looked at private IP space as more of a
> resource and management choice and not a security feature.
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From bill at herrin.us  Sun Nov 13 14:13:37 2011
From: bill at herrin.us (William Herrin)
Date: Sun, 13 Nov 2011 15:13:37 -0500
Subject: Arguing against using public IP space
In-Reply-To: <201111131638.pADGcoiu007448@mail.r-bonomi.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
Message-ID: <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>

On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi
<bonomi at mail.r-bonomi.com> wrote:
> On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis <jlewis at packetnexus.com> wrote;
>> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>
> Any article that claims a /12 is a 'class B', and a /16 is a 'Class C', is
> DEFINITELY 'flawed'.

Hi Robert,

Give the chart a second look. 192.168.0.0/16 (one of the three RFC1918
spaces) is, in fact, a /16 of IPv4 address space and it is, in fact,
found in the old "class C" range. Ditto 172.16.0.0/12. If there's a
nitpick, the author should have labeled the column something like
"classful area" instead of "classful description."


On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis <jlewis at packetnexus.com> wrote:
> I've always looked at private IP space as more of a
> resource and management choice and not a security feature.

Hi Jason,

If your machine is addressed with a globally routable IP, a trivial
failure of your security apparatus leaves your machine addressable
from any other host in the entire world which wishes to send it
packets. In the parlance, it tends to "fail open." Machines using
RFC1918 or RFC4193 space often have the opposite property: a failure
of the security apparatus is prone to leave them unable to interact
with the rest of the world at all. They tend to "fail closed."

Think of this way: Your firewall is a deadbolt and RFC1918 is the lock
on the doorknob. The knob lock doesn't stop anyone from entering an
unlatched window, opening the door from the inside and walking out
with all your stuff. Yet when you forget to throw the deadbolt, it
does stop an intruder from simply turning the knob and wandering in.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From davidianwalker at gmail.com  Sun Nov 13 15:03:02 2011
From: davidianwalker at gmail.com (David Walker)
Date: Mon, 14 Nov 2011 07:33:02 +1030
Subject: Arguing against using public IP space
In-Reply-To: <CAAAwwbXtyaALM=vi2iUM1rS-QfvPRB9DhyKW2K-BK_-sQyP2vw@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAAAwwbXtyaALM=vi2iUM1rS-QfvPRB9DhyKW2K-BK_-sQyP2vw@mail.gmail.com>
Message-ID: <CABE=bROZe-ZXkO=hrkRvi8PibzbYuHW6nBJ6tu_TJd_MF_inuQ@mail.gmail.com>

Hey.

On 14/11/2011, Jimmy Hess <mysidia at gmail.com> wrote:
> In other words, your use of RFC1918 address space alone does not
> create security.

I had this crazy idea that somewhere in the rfcs was a "should" that
manufacturers block private address space (i.e. hard coded) but it's
not (in fact the opposite).
Obviously there's shoulds for nocs and isps.
Regardless, you're exactly correct.

>   Your RFC1918 network actually _does_  need
> isolation  separate and apart from the address space,  for you to have
> reliable security,  you still need a firewall,  proxy, or NAT device
> of some form,

Pardon me but that's not axiomatic.
This is where the flames come right?

Between me and you there's X machines that route packets (and have
layer four services - yes I'm a TCP/IP model guy).
There's no separate firewall machines, no security postured proxies, no NATting.
These routers pass packets happily and don't influence my security or
the security of the other routers at all.
Obviously there are plenty of other critical machines that don't have
proxies or NATting (DNS).

Pertinently, they are publicly addressable yet don't have security
issues resulting from not having intermediate firewalls or proxies or
NAT.
The only issues they do have are what all endpoint machines face -
poor application (protocol) design (lack of encryption and so on),
poor administration, bugs.

Of those three, the methodology most readily associated to security is
firewalling (packet filtering).

A packet addressed to an endpoint that doesn't serve anything or have
a client listening will be ignered (whatever) as a matter of course.
Firewall or no firewall.
If I have a client application open on a port and get incoming from an
unsolicited IP then again it will be ignored as a matter of course.
Incoming to bogus ports are of course dropped (whatever). Firewall or
no firewall.
If I do have a port mapped to a service (serving not clienting) then
I'm open for business.

That's fundamental to TCP/IP and secure.
All other security considerations are appropriately handled at layer four.
The only reason we firewall (packet filter) is to provide access
control (for whatever reason).
Access control is a good enough reason to have something called a
firewall but everything else is a failure in design.
Again though, access control is a failure at protocol design (hence
DNS and BGP issues). Firewalling here is a kludge.

The only issue that depends on firewalling is ... DoS to preserve
bandwidth and that's not an end in and of itself.
I posit to you that in the current state of affairs, firewalling a
host or network is incredibly useful but entirely superfluous to
defending a machine.

I think you'd be hard pressed to find any convincing reason to suggest
that proxies  are any more useful (given good layer four design) from
a security perspective.

NAT?
No.
Fundamentally, it's not required or every machine that was publicly
addressable would have a NAT machine shoved in front of it and another
one shoved in front of that ...
Prima facie examples are every publicly addressable machine on the internet.
If there was a reason other than address space management then our
critical infrastructure would be NATted. The history of NAT tells me
I'm right.

> ... you still need ...
> ... the private network isolated from the public one ...

No.

I apologize in advance if this is too pedestrian (you might know this
but not agree with it) but I want to make a point:
http://en.wikipedia.org/wiki/End-to-end_connectivity
I've got homework to do (read some of that stuff and re-evaluate my
position) but NAT has caused nothing but trouble for security
practioners and allowed developers to get away with whatever they can
...
NAT saved us ... or at least all the moms and dads who don't have good
product or good administration.

> ... you still need ...
> ... the private network isolated from the public one ...

If this were true then IPv6 was fail.
Apart from any push to bring NAT along for the ride, we have a newer
IP with the deliberate choice made to make every machine publicly
addressable ... and to turn every NAT box into a router only ... and
let them route packets (like every other intermediate router) freeing
up hosts ... to do host security.
To me that was a breath of very fresh air.

The only reason to be concerned about this is vendors who make bad
choices and for that there's always other vendors. :]

> --
> -JH
>
>

Best wishes.


From regnauld at nsrc.org  Sun Nov 13 15:27:56 2011
From: regnauld at nsrc.org (Phil Regnauld)
Date: Sun, 13 Nov 2011 22:27:56 +0100
Subject: Arguing against using public IP space
In-Reply-To: <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
Message-ID: <20111113212756.GD73635@macbook.bluepipe.net>

William Herrin (bill) writes:
> If your machine is addressed with a globally routable IP, a trivial
> failure of your security apparatus leaves your machine addressable
> from any other host in the entire world which wishes to send it
> packets. In the parlance, it tends to "fail open." Machines using
> RFC1918 or RFC4193 space often have the opposite property: a failure
> of the security apparatus is prone to leave them unable to interact
> with the rest of the world at all. They tend to "fail closed."
> 
> Think of this way: Your firewall is a deadbolt and RFC1918 is the lock
> on the doorknob. The knob lock doesn't stop anyone from entering an
> unlatched window, opening the door from the inside and walking out
> with all your stuff. Yet when you forget to throw the deadbolt, it
> does stop an intruder from simply turning the knob and wandering in.
>

	That's not exactly correct. NAT doesn't imply firewalling/filtering.
	To illustrate this to customers, I've mounted attacks/scans on
	hosts behind NAT devices, from the interconnect network immediately
	outside: if you can point a route with the ext ip of the NAT device
	as the next hop, it usually just forwards the packets...

	Phil


From dougb at dougbarton.us  Sun Nov 13 15:48:32 2011
From: dougb at dougbarton.us (Doug Barton)
Date: Sun, 13 Nov 2011 13:48:32 -0800
Subject: Arguing against using public IP space
In-Reply-To: <20111113212756.GD73635@macbook.bluepipe.net>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
Message-ID: <4EC03B30.2090007@dougbarton.us>

On 11/13/2011 13:27, Phil Regnauld wrote:
> 	That's not exactly correct. NAT doesn't imply firewalling/filtering.
> 	To illustrate this to customers, I've mounted attacks/scans on
> 	hosts behind NAT devices, from the interconnect network immediately
> 	outside: if you can point a route with the ext ip of the NAT device
> 	as the next hop, it usually just forwards the packets...

Have you written this up anywhere? It would be absolutely awesome to be
able to point the "NAT IS A SECURITY FEATURE!!!" crowd to an actual
demonstration of why it isn't.


Doug

-- 

		"We could put the whole Internet into a book."
		"Too practical."

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/



From cb.list6 at gmail.com  Sun Nov 13 15:57:51 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Sun, 13 Nov 2011 13:57:51 -0800
Subject: Arguing against using public IP space
In-Reply-To: <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
Message-ID: <CAD6AjGSDxgYjHmzSXw01Lag1d9YC=x-yLAXQL7hidLP9LzeRgw@mail.gmail.com>

On Sun, Nov 13, 2011 at 12:13 PM, William Herrin <bill at herrin.us> wrote:
> On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi
> <bonomi at mail.r-bonomi.com> wrote:
>> On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis <jlewis at packetnexus.com> wrote;
>>> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>>
>> Any article that claims a /12 is a 'class B', and a /16 is a 'Class C', is
>> DEFINITELY 'flawed'.
>
> Hi Robert,
>
> Give the chart a second look. 192.168.0.0/16 (one of the three RFC1918
> spaces) is, in fact, a /16 of IPv4 address space and it is, in fact,
> found in the old "class C" range. Ditto 172.16.0.0/12. If there's a
> nitpick, the author should have labeled the column something like
> "classful area" instead of "classful description."
>
>
> On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis <jlewis at packetnexus.com> wrote:
>> I've always looked at private IP space as more of a
>> resource and management choice and not a security feature.
>
> Hi Jason,
>
> If your machine is addressed with a globally routable IP, a trivial
> failure of your security apparatus leaves your machine addressable
> from any other host in the entire world which wishes to send it
> packets. In the parlance, it tends to "fail open." Machines using
> RFC1918 or RFC4193 space often have the opposite property: a failure
> of the security apparatus is prone to leave them unable to interact
> with the rest of the world at all. They tend to "fail closed."
>

This "fail open" vs "fail closed" is a very good characterization of
the situation.  While many IPv4 situations requires RFC1918 addresses
due to scarcity, so it is a moot point, this fail open vs closed
argument applies very well to why one should consider IPv6 ULA
addresses in certain specific scenarios.  If the system does not need
to speak to the outside world, a ULA is frequently the right choice to
leverage this "fail closed" benefits, which IMHO outstrip any
advantages due to "not having to renumber when requirements change" or
whatever else the religiously anti-ULA folks have to say.

CB

> Think of this way: Your firewall is a deadbolt and RFC1918 is the lock
> on the doorknob. The knob lock doesn't stop anyone from entering an
> unlatched window, opening the door from the inside and walking out
> with all your stuff. Yet when you forget to throw the deadbolt, it
> does stop an intruder from simply turning the knob and wandering in.
>
> Regards,
> Bill Herrin
>
>
> --
> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
>
>


From chuckchurch at gmail.com  Sun Nov 13 16:43:46 2011
From: chuckchurch at gmail.com (Chuck Church)
Date: Sun, 13 Nov 2011 17:43:46 -0500
Subject: Arguing against using public IP space
In-Reply-To: <4EC03B30.2090007@dougbarton.us>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us>
Message-ID: <001001cca255$b4a45450$1decfcf0$@com>

When you all say NAT, are you implying PAT as well?  1 to 1 NAT really
provides no security.  But with PAT, different story.  Are there poor
implementations of PAT that don't enforce an exact port/address match for
the translation table?  If the translation table isn't at fault, are the
'helpers' that allow ftp to work passively to blame? 

Chuck

-----Original Message-----
From: Doug Barton [mailto:dougb at dougbarton.us] 
Sent: Sunday, November 13, 2011 4:49 PM
To: Phil Regnauld
Cc: nanog at nanog.org
Subject: Re: Arguing against using public IP space

On 11/13/2011 13:27, Phil Regnauld wrote:
> 	That's not exactly correct. NAT doesn't imply firewalling/filtering.
> 	To illustrate this to customers, I've mounted attacks/scans on
> 	hosts behind NAT devices, from the interconnect network immediately
> 	outside: if you can point a route with the ext ip of the NAT device
> 	as the next hop, it usually just forwards the packets...

Have you written this up anywhere? It would be absolutely awesome to be able
to point the "NAT IS A SECURITY FEATURE!!!" crowd to an actual demonstration
of why it isn't.


Doug

-- 

		"We could put the whole Internet into a book."
		"Too practical."

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/




From regnauld at nsrc.org  Sun Nov 13 16:46:31 2011
From: regnauld at nsrc.org (Phil Regnauld)
Date: Sun, 13 Nov 2011 23:46:31 +0100
Subject: Arguing against using public IP space
In-Reply-To: <4EC03B30.2090007@dougbarton.us>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us>
Message-ID: <20111113224631.GE73635@macbook.bluepipe.net>

Doug Barton (dougb) writes:
> On 11/13/2011 13:27, Phil Regnauld wrote:
> > 	That's not exactly correct. NAT doesn't imply firewalling/filtering.
> > 	To illustrate this to customers, I've mounted attacks/scans on
> > 	hosts behind NAT devices, from the interconnect network immediately
> > 	outside: if you can point a route with the ext ip of the NAT device
> > 	as the next hop, it usually just forwards the packets...
> 
> Have you written this up anywhere? It would be absolutely awesome to be
> able to point the "NAT IS A SECURITY FEATURE!!!" crowd to an actual
> demonstration of why it isn't.

	Nope, but I could do a quick tut on how to do this against a natd/pf/
	iptables or IOS with IP overload.

	Arguably in *most* cases your CPE or whatever is NATing is behind
	some upstream device doing ingress filtering, so you still need to
	be compromising a device fairly close to the target network.

	P.



From regnauld at nsrc.org  Sun Nov 13 16:59:24 2011
From: regnauld at nsrc.org (Phil Regnauld)
Date: Sun, 13 Nov 2011 23:59:24 +0100
Subject: Arguing against using public IP space
In-Reply-To: <001001cca255$b4a45450$1decfcf0$@com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us>
 <001001cca255$b4a45450$1decfcf0$@com>
Message-ID: <20111113225924.GF73635@macbook.bluepipe.net>

Chuck Church (chuckchurch) writes:
> When you all say NAT, are you implying PAT as well?  1 to 1 NAT really
> provides no security.  But with PAT, different story.  Are there poor
> implementations of PAT that don't enforce an exact port/address match for
> the translation table?  If the translation table isn't at fault, are the
> 'helpers' that allow ftp to work passively to blame? 

    PAT (overload) will have ports open listening for return traffic,
    on the external IP that's being "overloaded".

    What happens if you initiate traffic directed at the RFC1918
    network itself, and send that to the MAC address of the NAT device ?

    In many cases, it just works. That's how IP forwarding works, after
    all :)

    inside net ----------[NAT]-----------{ext net}----[attacker]
    192.168.0.0/24    .254    1.2.3.4                  1.2.3.5

    S:1.2.3.5   D:192.168.0.1   next hop: 1.2.3.4

    Now, on the way back *out* from the inside net, traffic from
    192.168.0.1 back to 1.2.3.4 might get translated - it depends if
    what the NAT is programmed to do if it sees, say, a S/A packet
    with no corresponding SYN, on its way out. It might just get
    dropped.  UDP would in some cases get natted, but since you
    know your destination port on 1.2.3.5, you know what to expect,
    and you can build an asymmetric connection since you control the
    attacking host.

	Either way, you've still injected traffic into the inside net.

    Etc...



From Gabriel.McCall at thyssenkrupp.com  Sun Nov 13 17:12:19 2011
From: Gabriel.McCall at thyssenkrupp.com (McCall, Gabriel)
Date: Sun, 13 Nov 2011 18:12:19 -0500
Subject: Arguing against using public IP space
In-Reply-To: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
Message-ID: <b80f7673-b6fb-4529-809b-b57ba2a14043@blur>

Google for "NAT is not a security feature" and review all the discussions and unnecessary panic over a lack of NAT support in IPv6. If your SCADA network can reach the public internet then your security is only as good as your firewall, whether you NAT or not. If your SCADA network is completely isolated then it doesn't make a bit of difference what addresses you use.

-----Original message-----
From: Jason Lewis <jlewis at packetnexus.com>
To: "nanog at nanog.org" <nanog at nanog.org>
Sent: Sun, Nov 13, 2011 15:36:43 GMT+00:00
Subject: Arguing against using public IP space

I don't want to start a flame war, but this article seems flawed to
me. It seems an IP is an IP.

http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html

I think I could announce private IP space, so doesn't that make this
argument invalid? I've always looked at private IP space as more of a
resource and management choice and not a security feature.



From jra at baylink.com  Sun Nov 13 17:29:39 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 13 Nov 2011 18:29:39 -0500 (EST)
Subject: Arguing against using public IP space
In-Reply-To: <B9AEE1BF-E963-4B79-A705-D12301E7A823@arbor.net>
Message-ID: <30721173.2585.1321226978998.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Roland Dobbins" <rdobbins at arbor.net>

> The real issue is interconnecting SCADA systems to publicly-routed
> networks, not the choice of potentially routable space vs. RFC1918
> space for SCADA networks, per se. If I've an RFC1918-addressed SCADA
> network which is interconnected to a publicly-routed- and -accessible
> network, then an attacker can work to compromise a host on the
> publicly-accessible network and then jump from there to the RFC1918
> SCADA network.

SCADA networks should be hard air-gapped from any other network.

In case you're in charge of one, and you didn't hear that, let me say it again:

*SCADA networks should he hard air-gapped from any other network.*

If you're in administrative control of one, and it's attacked because you
didn't follow this rule, and someone dies because of it, I heartily, and
perfectly seriously, encourage that you be charged with homicide.

We do it with Professional Engineers; I see no reason we shouldn't expect
the same level of responsibility from other types.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From jra at baylink.com  Sun Nov 13 17:36:31 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 13 Nov 2011 18:36:31 -0500 (EST)
Subject: Arguing against using public IP space
In-Reply-To: <4EC03B30.2090007@dougbarton.us>
Message-ID: <8319275.2593.1321227391110.JavaMail.root@benjamin.baylink.com>

---- Original Message -----
> From: "Doug Barton" <dougb at dougbarton.us>

> On 11/13/2011 13:27, Phil Regnauld wrote:
> > 	That's not exactly correct. NAT doesn't imply
> > 	firewalling/filtering.
> > 	To illustrate this to customers, I've mounted attacks/scans on
> > 	hosts behind NAT devices, from the interconnect network immediately
> > 	outside: if you can point a route with the ext ip of the NAT device
> > 	as the next hop, it usually just forwards the packets...
> 
> Have you written this up anywhere? It would be absolutely awesome to
> be able to point the "NAT IS A SECURITY FEATURE!!!" crowd to an actual
> demonstration of why it isn't.

Accepting strict source routing from a public interface is certainly in the
top 10 Worst Common Practices, is it not?  (IE: I would be surprised if *any*
current router actually let you do that.)

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From jay at west.net  Sun Nov 13 17:51:13 2011
From: jay at west.net (Jay Hennigan)
Date: Sun, 13 Nov 2011 15:51:13 -0800
Subject: Arguing against using public IP space
In-Reply-To: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
Message-ID: <4EC057F1.6030105@west.net>

On 11/13/11 7:36 AM, Jason Lewis wrote:
> I don't want to start a flame war, but this article seems flawed to
> me.  It seems an IP is an IP.
>
> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>
> I think I could announce private IP space, so doesn't that make this
> argument invalid?

You could announce it.  I wouldn't expect anyone else to listen to those 
announcements other than for the purpose of ridiculing you.

> I've always looked at private IP space as more of a
> resource and management choice and not a security feature.

It depends.

Case 1:  If the SCADA vendors are configuring units with non-RFC1918 IP 
space in live customer installations, and these installations aren't 
ever in any way connected to the public Internet, then there isn't any 
real operational problem.  It smacks of carelessness/cluelessness on the 
part of both the vendor and the IT staff of the customer who accepted 
the configuration, but nothing is operationally broken.

Case 2:  Same as above, but the SCADA network is connected to the 
Internet behind a NAT at the customer location.  Again careless and 
clueless.  And should anything on that network need to access resources 
on the Internet within the space configured on the SCADA system it won't 
work.  The vendor/customer have broken reachability to some part of the 
public Internet for that system.  Whether there is a security risk 
depends on the configuration of the NAT firewall and whether and how how 
the SCADA system opens connections outbound and what vulnerabilities 
exist in its systems if it does.  No more security risk than the same 
situation using RFC1918 space.

Case 3:  Same as case 2 but without the NAT.  Pretty much the same 
result.  The SCADA system won't be reachable from the outside because 
the customer's provider won't route those addresses to the customer. 
Packets sourced to the Internet from the SCADA aren't likely to get very 
far.  Even more broken/stupid than the other scenarios but not likely to 
be much of a security risk in terms of exposure to the Internet.

Case 4:  SCADA vendor asks customer for a subnet of public IP space 
allocated to the customer and installs the SCADA system directly on the 
Internet.  From an RFC standpoint, nothing is broken.  From a security 
standpoint, without appropriate firewalls, a very bad idea.

So, yes, it's a dumb idea.  The degree of dumbness depends.

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV


From chuckchurch at gmail.com  Sun Nov 13 17:53:19 2011
From: chuckchurch at gmail.com (Chuck Church)
Date: Sun, 13 Nov 2011 18:53:19 -0500
Subject: Arguing against using public IP space
In-Reply-To: <20111113225924.GF73635@macbook.bluepipe.net>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
Message-ID: <002201cca25f$6c5340d0$44f9c270$@com>

-----Original Message-----
From: Phil Regnauld [mailto:regnauld at nsrc.org] 


>    PAT (overload) will have ports open listening for return traffic,
>    on the external IP that's being "overloaded".

>    What happens if you initiate traffic directed at the RFC1918
>    network itself, and send that to the MAC address of the NAT device ?

>    In many cases, it just works. That's how IP forwarding works, after
>    all :)
>
>    inside net ----------[NAT]-----------{ext net}----[attacker]
>    192.168.0.0/24    .254    1.2.3.4                  1.2.3.5

>   S:1.2.3.5   D:192.168.0.1   next hop: 1.2.3.4
>
>    Now, on the way back *out* from the inside net, traffic from
>    192.168.0.1 back to 1.2.3.4 might get translated - it depends if
>    what the NAT is programmed to do if it sees, say, a S/A packet
>    with no corresponding SYN, on its way out. It might just get
>    dropped.  UDP would in some cases get natted, but since you
>   know your destination port on 1.2.3.5, you know what to expect,
>   and you can build an asymmetric connection since you control the
>   attacking host.
>
>	Either way, you've still injected traffic into the inside net.
>

That makes sense, but I'm wondering if that should be considered correct
behavior.  Obviously a non-consumer grade router can have rules defining
what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
everything coming from the outside in to either a) match up with something
in the translation table, b) be a service the router itself is hosting
(http, etc), or c) be a port it explicitly forwards to the same inside host.
Anything not matching one of those 3 categories you'd think could be
dropped.  Routing without translating ports and addresses seems like the
root of the issue.

Chuck



From jlewis at packetnexus.com  Sun Nov 13 17:58:36 2011
From: jlewis at packetnexus.com (Jason Lewis)
Date: Sun, 13 Nov 2011 18:58:36 -0500
Subject: Arguing against using public IP space
In-Reply-To: <4EC057F1.6030105@west.net>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <4EC057F1.6030105@west.net>
Message-ID: <CA+buB7dD3hw8paa3UYtCsNvY3XDJHxjWj2u6J7PNi9kJ0=MffA@mail.gmail.com>

>> I think I could announce private IP space, so doesn't that make this
>> argument invalid?
>
> You could announce it. ?I wouldn't expect anyone else to listen to those
> announcements other than for the purpose of ridiculing you.
>

People keep pointing to this as unlikely.  I argue that spammers are
currently doing this all over the world, maybe not as widespread wiith
1918 space.  If I can announce 1918 space to an ISP where my target
is...it doesn't matter if everyone else ignores or drops it.  The ISP
allowed it, so all their customers will route the traffic.   I still
think it's a valid attack vector, discounting it because people would
laugh at me, seems like a poor security posture.

jas


From bonomi at mail.r-bonomi.com  Sun Nov 13 18:16:46 2011
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sun, 13 Nov 2011 18:16:46 -0600 (CST)
Subject: Arguing against using public IP space
In-Reply-To: <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
Message-ID: <201111140016.pAE0GkZP009815@mail.r-bonomi.com>

> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Sun Nov 13 14:15:38 2011
> From: William Herrin <bill at herrin.us>
> Date: Sun, 13 Nov 2011 15:13:37 -0500
> Subject: Re: Arguing against using public IP space
> To: nanog at nanog.org
>
> On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi
> <bonomi at mail.r-bonomi.com> wrote:
> > On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis <jlewis at packetnexus.com> wrote;
> >> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
> >
> > Any article that claims a /12 is a 'class B', and a /16 is a 'Class C', is
> > DEFINITELY 'flawed'.
>
> Hi Robert,
>
> Give the chart a second look. 192.168.0.0/16 (one of the three RFC1918
> spaces) is, in fact, a /16 of IPv4 address space and it is, in fact,
> found in the old "class C" range. Ditto 172.16.0.0/12. If there's a
> nitpick, the author should have labeled the column something like
> "classful area" instead of "classful description."

In the 'classful' world, neither the /12 or the /16 spaces were referencble
as a single object.  Correct 'classful descriptions' would have been:
        "16 contiguous Class 'B's"
       "256 contiguous Class 'C's"


From jra at baylink.com  Sun Nov 13 18:21:36 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 13 Nov 2011 19:21:36 -0500 (EST)
Subject: Arguing against using public IP space
In-Reply-To: <201111140016.pAE0GkZP009815@mail.r-bonomi.com>
Message-ID: <3481047.2631.1321230096029.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Robert Bonomi" <bonomi at mail.r-bonomi.com>

> In the 'classful' world, neither the /12 or the /16 spaces were referencible
> as a single object. Correct 'classful descriptions' would have been:
> "16 contiguous Class 'B's" "256 contiguous Class 'C's"

Fine.  But I think you're going to fine that synechdoche triumphs here, and
a Class-C *Sized* network is going to be called that, even if it's first 
octet is 191 or lower, Robert.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From rdobbins at arbor.net  Sun Nov 13 19:13:21 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 14 Nov 2011 01:13:21 +0000
Subject: Arguing against using public IP space
In-Reply-To: <30721173.2585.1321226978998.JavaMail.root@benjamin.baylink.com>
References: <30721173.2585.1321226978998.JavaMail.root@benjamin.baylink.com>
Message-ID: <E78E68D2-B790-430D-88F1-AD3019F0848E@arbor.net>


On Nov 14, 2011, at 6:29 AM, Jay Ashworth wrote:

> SCADA networks should be hard air-gapped from any other network.

Concur, GMTA.  My point is that without an airgap, the attacker can jump from a production network to the SCADA network, so we're in violent agreement.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From rbf+nanog at panix.com  Sun Nov 13 19:14:59 2011
From: rbf+nanog at panix.com (Brett Frankenberger)
Date: Sun, 13 Nov 2011 19:14:59 -0600
Subject: Arguing against using public IP space
In-Reply-To: <30721173.2585.1321226978998.JavaMail.root@benjamin.baylink.com>
References: <B9AEE1BF-E963-4B79-A705-D12301E7A823@arbor.net>
 <30721173.2585.1321226978998.JavaMail.root@benjamin.baylink.com>
Message-ID: <20111114011458.GA19365@panix.com>

On Sun, Nov 13, 2011 at 06:29:39PM -0500, Jay Ashworth wrote:
> 
> SCADA networks should be hard air-gapped from any other network.
> 
> In case you're in charge of one, and you didn't hear that, let me say
> it again:
> 
> *SCADA networks should he hard air-gapped from any other network.*
> 
> If you're in administrative control of one, and it's attacked because you
> didn't follow this rule, and someone dies because of it, I heartily, and
> perfectly seriously, encourage that you be charged with homicide.
> 
> We do it with Professional Engineers; I see no reason we shouldn't expect
> the same level of responsibility from other types.

What if you air-gap the SCADA network of which you are in
administrative control, and then there's a failure on it, and the people
responsible for troubleshooting it can't do it remotely (because of the
air gap), so the trouble continues for an extra hour while they drive
to the office, and that extra hour of failure causes someone to die. 
Should that result in a homicide charge?

What if you air-gap the SCADA network of which you are in
administrative control, but, having done so, you can't afford the level
of redundancy you could when it wasn't air-gapped, and a transport
failure leaves you without remote control of a system at a time when
it's needed to prevent a cascading failure, and that leads to someone
dieing.  Should that result in a homicide charge?

Air-gap means you have to build your own facilities for the entire
SCADA network.  No MPLS-VPN service from providers.  Can't even use
point-to-point TDM circuits (T1, for example) from providers, since
those are typically mixed in with other circuits in the carrier's DACS,
so it's only logical separation.  And even if you want to redefine
"air-gap" to be "air-gap, or at least no co-mingling in any packet
switching equipment", you've ruled out any use of commercial wireless
service (i.e. cellular) for backup paths.

A good engineer weighs all the tradeoffs and makes a judgement.  In
some systems, there's might be a safety component of availability that
justifies accepting some very small increase in the risk of outside
compromise.

You can argue that safety is paramount -- that the system needs to be
designed to never get into an unsafe condition because of a
communications failure (which, in fact is a good argument) -- that
there must always be sufficient local control to keep the system in a
safe state.  Then you can implement the air-gap policy, knowing that
while it might make remote control less reliable, there's no chance of,
say, the plant blowing up because of loss of remote control.  (Except,
of course, that that's only true if you have complete faith in the local
control system.  Sometimes remote monitoring can allow a human to see
and correct a developing unsafe condition that the control system was
never programmed to deal with.)

But even if the local control is completely safe in the loss-of-comm
failure case, it's still not as cut and dried as it sounds.  The plant
might not blow up.  But it might trip offline with there being no way
to restart it because of a comm failure.  Ok, fine, you say, it's still
in a safe condition.  Except, of course, that power outages, especially
widespread ones, can kill people.  Remote control of the power grid
might not be necessarily to keep plants from blowing up, but it's
certainly necessary in certain cases to keep it online.  (And in this
paragraph, I'm using the power grid as an example.  But the point I'm
making in this post is more general case.)

Sure, anytime there's an attack or failure on a SCADA network that
wouldn't have occurred had it been air-gapped, it's easy for people to
knee-jerk a "SCADA networks should be airgapped" response.  But that's
not really intelligent commentary unless you carefully consider what
risks are associated with air-gapping the network.

Practically speaking, non-trivial SCADA networks are almost never
completely air-gapped.  Have you talked to people who run them?

     -- Brett


From jra at baylink.com  Sun Nov 13 19:31:15 2011
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 13 Nov 2011 20:31:15 -0500 (EST)
Subject: Arguing against using public IP space
In-Reply-To: <20111114011458.GA19365@panix.com>
Message-ID: <3922450.2637.1321234275543.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Brett Frankenberger" <rbf+nanog at panix.com>

> What if you air-gap the SCADA network of which you are in
> administrative control, and then there's a failure on it, and the
> people responsible for troubleshooting it can't do it remotely (because of
> the air gap), so the trouble continues for an extra hour while they drive
> to the office, and that extra hour of failure causes someone to die.
> Should that result in a homicide charge?

I should think it would be your responsibility, as the chief engineer, to
make sure *you have filled all such possible holes in your operations plan*.

> What if you air-gap the SCADA network of which you are in
> administrative control, but, having done so, you can't afford the
> level of redundancy you could when it wasn't air-gapped, and a transport
> failure leaves you without remote control of a system at a time when
> it's needed to prevent a cascading failure, and that leads to someone
> dieing. Should that result in a homicide charge?

If it costs more to run, then it *costs more to run*.

> Air-gap means you have to build your own facilities for the entire
> SCADA network. No MPLS-VPN service from providers. Can't even use
> point-to-point TDM circuits (T1, for example) from providers, since
> those are typically mixed in with other circuits in the carrier's
> DACS, so it's only logical separation. And even if you want to redefine
> "air-gap" to be "air-gap, or at least no co-mingling in any packet
> switching equipment", you've ruled out any use of commercial wireless
> service (i.e. cellular) for backup paths.

*I* define "air gap" as "no way to move packets from the outside world
into the network.  I didn't say "100% dedicated facilities", though your
implication that that still leaves an attacker a way to reconfigure things
such that they could get in is absolutely correct.

> A good engineer weighs all the tradeoffs and makes a judgement. In
> some systems, there's might be a safety component of availability that
> justifies accepting some very small increase in the risk of outside
> compromise.

The line is pretty bright, I think, but you're correct in asserting that the
price difference goes up as the square of the number of nines.  But that's not
important now; we're talking about cases that aren't even *99%*, much less 4 or
5 nines of unlikelihood that an outsider can find a way to break in.
 
> You can argue that safety is paramount -- that the system needs to be
> designed to never get into an unsafe condition because of a
> communications failure (which, in fact is a good argument) -- that
> there must always be sufficient local control to keep the system in a
> safe state. Then you can implement the air-gap policy, knowing that
> while it might make remote control less reliable, there's no chance
> of, say, the plant blowing up because of loss of remote control. (Except,
> of course, that that's only true if you have complete faith in the
> local control system. Sometimes remote monitoring can allow a human to see
> and correct a developing unsafe condition that the control system was
> never programmed to deal with.)

Yes, but that's enablement for loss of locally staffed control, all by itself.

Even power utilities have a pretty good real rate of return these days; I have
no problem with them spending a little more of their revenue on safety, instead 
of profit.  If that takes regulators pointing guns at them, I'm fine with that.

> But even if the local control is completely safe in the loss-of-comm
> failure case, it's still not as cut and dried as it sounds. The plant
> might not blow up. But it might trip offline with there being no way
> to restart it because of a comm failure. Ok, fine, you say, it's still
> in a safe condition. Except, of course, that power outages, especially
> widespread ones, can kill people. Remote control of the power grid
> might not be necessarily to keep plants from blowing up, but it's
> certainly necessary in certain cases to keep it online. (And in this
> paragraph, I'm using the power grid as an example. But the point I'm
> making in this post is more general case.)

And I just read the Cracked piece talking about the 77 NYC blackout, which is
sort of weird, actually.  :-)  But the general case point *I* was making was
not that I expected a conviction.

It was that I expected a charge, and a trial.

If a bridge collapses, are we going to charge the Professional Engineer who 
signed off on it?
 
> Sure, anytime there's an attack or failure on a SCADA network that
> wouldn't have occurred had it been air-gapped, it's easy for people to
> knee-jerk a "SCADA networks should be airgapped" response. But that's
> not really intelligent commentary unless you carefully consider what
> risks are associated with air-gapping the network.
> 
> Practically speaking, non-trivial SCADA networks are almost never
> completely air-gapped. Have you talked to people who run them?

No, and yes my knee was jerking.  But based on the industry stuff I have seen
from out here, security isn't anywhere in the same *county* with where it needs
to be, and -- just as with RMS and the GPL -- maybe if some extremists knees jerk, 
the end result, while more moderate, will be more salutary.

If you were that chief, and you knew the result of you screwing up might be
the loss of your liberty, not just your job... you don't think you'd fight 
budget battles with your utility harder?  (That's often the reason for such 
regulations: to give middle to upper management more bullets to fire at the
(greedy) owners.)

Thanks for doing some of my math for me, though, Brett.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From jeff-kell at utc.edu  Sun Nov 13 19:36:18 2011
From: jeff-kell at utc.edu (Jeff Kell)
Date: Sun, 13 Nov 2011 20:36:18 -0500
Subject: Arguing against using public IP space
In-Reply-To: <20111113212756.GD73635@macbook.bluepipe.net>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
Message-ID: <4EC07092.9070101@utc.edu>

On 11/13/2011 4:27 PM, Phil Regnauld wrote:
> That's not exactly correct. NAT doesn't imply firewalling/filtering. 
> To illustrate this to customers, I've mounted attacks/scans on hosts 
> behind NAT devices, from the interconnect network immediately outside: 
> if you can point a route with the ext ip of the NAT device as the next 
> hop, it usually just forwards the packets... Phil 

"It depends" on your NAT model.  If you take a default Cisco PIX or ASA 
device...

(a) There is an option to "permit non-NAT traffic through the 
firewall".  If not selected (nat-control) then there must be a covering 
NAT rule for any inside host to communicate with the outside interface, 
let alone outside-to-inside.

(b) By default all inbound traffic is default-deny, only "return" 
traffic for inside-initiated connections is allowed.

Yes, it's stateful (which is another argument altogether for placing a 
stateful device in the chain) but by all means, it does not allow 
outside traffic into the inside, regardless of the addressing scheme on 
the inside.

Beyond that, using 1918 space decreases the possibility that a "new, 
unexpected" path to the inside network will result in exposure.  If you 
are using public space on the inside, and some path develops that 
bypasses the firewall, the routing information is already in place, you 
only need to affect the last hop.  You can then get end-to-end routing 
of inside hosts to an outside party.  Using 1918 space, with even 
nominal BCP adherence of the intermediate transit providers, you can't 
leak routing naturally.  (Yes, it's certainly possible, but it raises 
the bar).

If the added protection were trivial, I would think the PCI requirement 
1.3.8 requiring it would have been rejected long ago.

Jeff



From jay at west.net  Sun Nov 13 19:39:03 2011
From: jay at west.net (Jay Hennigan)
Date: Sun, 13 Nov 2011 17:39:03 -0800
Subject: Arguing against using public IP space
In-Reply-To: <4EC06106.2020303@west.net>
References: <4EC06106.2020303@west.net>
Message-ID: <4EC07137.7030706@west.net>

On 11/13/11 3:58 PM, Jason Lewis wrote:

> People keep pointing to this as unlikely.  I argue that spammers are
> currently doing this all over the world, maybe not as widespread wiith
> 1918 space.  If I can announce 1918 space to an ISP where my target
> is...it doesn't matter if everyone else ignores or drops it.  The ISP
> allowed it, so all their customers will route the traffic.   I still
> think it's a valid attack vector, discounting it because people would
> laugh at me, seems like a poor security posture.

It would be your target announcing the RFC1918 space, so the security
risk would be if his ISP, your ISP and all of the intermediate
peering/transit links were to honor those announcements and route the
traffic to the target.  Possible, and it has probably happened at some
point, but not likely.  The closer your logically to your target the
more likely such an attack would succeed.

I certainly don't recommend announcing RFC1918 space to the public
Internet.  Doing so is a bad thing.  If you do so there is indeed a
non-zero chance that someone close enough to you could connect to your
network and do damage.

Announcing RFC1918 space is less likely to route very far than
announcing public space that isn't allocated to you, however.  That's
what the spammers all over the world are doing.

In terms of security, most every SCADA system, as others have pointed
out, should not be connected to the public Internet AT ALL.  In this
case it really doesn't matter what addressing scheme is used.  Use
Novell IPX or Appletalk if you want.  Or MODBUS.

If, however, it is using IPv4, RFC1918 space in a different subnet than
anything used internally within the organization is a better choice than
any public space or subnets of RFC1918 space in use within the
organization.  This offers a degree of protection against mis-cabling
and other accidental or malicious vectors that could allow other
networks to communicate with the SCADA network.

It would probably be best if the SCADA hardware vendors were to ship
their gear with no IP addresses pre-programmed at all, as well as
preventing them from being configured until any default passwords are
changed.  Similarly, they should educate their installation contractors
about such things.

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV


From jgreco at ns.sol.net  Sun Nov 13 20:24:29 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Sun, 13 Nov 2011 20:24:29 -0600 (CST)
Subject: Arguing against using public IP space
In-Reply-To: <20111114011458.GA19365@panix.com>
Message-ID: <201111140224.pAE2OTjX061150@aurora.sol.net>

> Sure, anytime there's an attack or failure on a SCADA network that
> wouldn't have occurred had it been air-gapped, it's easy for people to
> knee-jerk a "SCADA networks should be airgapped" response.  But that's
> not really intelligent commentary unless you carefully consider what
> risks are associated with air-gapping the network.

Not to mention that it's not the only way for these things to get
infected.  Getting fixated on air-gapping is unrealistically ignoring
the other threats out there.

There needs to be a whole lot more security work done on SCADA nets.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From Valdis.Kletnieks at vt.edu  Sun Nov 13 20:43:32 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 13 Nov 2011 21:43:32 -0500
Subject: Arguing against using public IP space
In-Reply-To: Your message of "Sun, 13 Nov 2011 19:14:59 CST."
 <20111114011458.GA19365@panix.com>
References: <B9AEE1BF-E963-4B79-A705-D12301E7A823@arbor.net>
 <30721173.2585.1321226978998.JavaMail.root@benjamin.baylink.com>
 <20111114011458.GA19365@panix.com>
Message-ID: <81357.1321238612@turing-police.cc.vt.edu>

On Sun, 13 Nov 2011 19:14:59 CST, Brett Frankenberger said:

> What if you air-gap the SCADA network of which you are in
> administrative control, and then there's a failure on it, and the people
> responsible for troubleshooting it can't do it remotely (because of the
> air gap), so the trouble continues for an extra hour while they drive
> to the office, and that extra hour of failure causes someone to die. 
> Should that result in a homicide charge?

If you designed a life-critical airgapped network that didn't have a trained
warm body at the NOC 24/7 with an airgapped management console, and hot (or at
least warm) spares for both console and console monkey, yes, you *do* deserve
that negligent homicide charge.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111113/247b47fe/attachment.bin>

From joelja at bogus.com  Sun Nov 13 20:59:45 2011
From: joelja at bogus.com (Joel jaeggli)
Date: Mon, 14 Nov 2011 10:59:45 +0800
Subject: Arguing against using public IP space
In-Reply-To: <201111140224.pAE2OTjX061150@aurora.sol.net>
References: <201111140224.pAE2OTjX061150@aurora.sol.net>
Message-ID: <4EC08421.80708@bogus.com>

On 11/14/11 10:24 , Joe Greco wrote:
>> Sure, anytime there's an attack or failure on a SCADA network that
>> wouldn't have occurred had it been air-gapped, it's easy for people to
>> knee-jerk a "SCADA networks should be airgapped" response.  But that's
>> not really intelligent commentary unless you carefully consider what
>> risks are associated with air-gapping the network.
> 
> Not to mention that it's not the only way for these things to get
> infected.  Getting fixated on air-gapping is unrealistically ignoring
> the other threats out there.
> 
> There needs to be a whole lot more security work done on SCADA nets.

Stuxnet should provide a fairly illustrative example.

It doesn't really matter how well isolated from direct access it is if
it has a soft gooey center and a willing attacker.

> ... JG



From mysidia at gmail.com  Sun Nov 13 21:48:01 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 13 Nov 2011 21:48:01 -0600
Subject: Arguing against using public IP space
In-Reply-To: <CABE=bROZe-ZXkO=hrkRvi8PibzbYuHW6nBJ6tu_TJd_MF_inuQ@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAAAwwbXtyaALM=vi2iUM1rS-QfvPRB9DhyKW2K-BK_-sQyP2vw@mail.gmail.com>
 <CABE=bROZe-ZXkO=hrkRvi8PibzbYuHW6nBJ6tu_TJd_MF_inuQ@mail.gmail.com>
Message-ID: <CAAAwwbUSUzHO0q3vkBh3-sQHxnXc5=UE5w2R+MZ=Hmpa08wDhg@mail.gmail.com>

On Sun, Nov 13, 2011 at 3:03 PM, David Walker <davidianwalker at gmail.com> wrote:
> On 14/11/2011, Jimmy Hess <mysidia at gmail.com> wrote:
> A packet addressed to an endpoint that doesn't serve anything or have
> a client listening will be ignered (whatever) as a matter of course.
> Firewall or no firewall.
It will not go to a listening application,  neither will it be
completely ignored --
the receiving machine's  TCP stack will have a look at the packet.
On common operating systems there  are frequently unsafe applications
listening on ports;  on certain OSes, there will be no way to turn off
system applications,  or human error will leave them in place.

> That's fundamental to TCP/IP and secure.
It's fundamental to TCP/IP,  but not fundamentally secure.  TCP/IP
implementations have flaws.
If a host is meant solely as an endpoint, then it is exposed to undue
risk, if arbitrary packets can be addressed to its TCP/IP stack that
might have remotely exploitable bugs.

> The only reason we firewall (packet filter) is to provide access
> control (for whatever reason).
No, we also firewall to block access entirely to applications
attempting to establish a service on unapproved ports.    We also use
firewalls in certain forms to ensure that communications over a TCP/IP
socket comply with a protocol,  for example,  that a session
terminated on port 25 is actually a SMTP session.

The firewall might restrict the set of allowed SMTP commands, validate
the syntax of certain commands,  hide server version information,
prevent use of ESMTP pipelining from outside, etc.

> I apologize in advance if this is too pedestrian (you might know this
> but not agree with it) but I want to make a point:
> http://en.wikipedia.org/wiki/End-to-end_connectivity

End to end connectivity principal's purpose is not to provide
security.    It is to facilitate communications with other hosts and
networks.     When a private system _really_ has to be secure,  end to
end connectivity is inherently incompatible  with security objectives.

There is always a tradeoff involving sacrificing a level of security
against remote attack
when connecting a computer to a network,  and then again,  when
connecting the network to the internet.

A computer that is not connected to a network is perfectly secure
against network-based attacks.
A computer that is connected to LAN is at risk of potential
network-based attack from that LAN.

If that LAN is then connected through a firewall  through many to 1
NAT,  there is another layer of risk added.

If the NAT'ing firewall is then replaced with a simple many to 1 NAT
router,  there is another layer of risk added; there are new attacks
possible that still succeed in a NAT environment,  that the firewall
would have stopped.

Finally, if that that same computer is then given end to end
connectivity with no firewall,  there is a much   less encumbered
communications path available to that computer for launching
network-based attack;  the attack surface is greatly increased in such
a design.

If we are talking about nodes that interface with a SCADA network;
the concept of unfirewalled end-to-end connectivity approaches the
level of insanity.

Those are not systems where end-to-end public connectivity should be a
priority over security.

--
-JH


From owen at delong.com  Sun Nov 13 21:51:24 2011
From: owen at delong.com (Owen DeLong)
Date: Sun, 13 Nov 2011 19:51:24 -0800
Subject: Arguing against using public IP space
In-Reply-To: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
Message-ID: <2DE5DF4F-059C-4F39-81D4-363E49966282@delong.com>


On Nov 13, 2011, at 7:36 AM, Jason Lewis wrote:

> I don't want to start a flame war, but this article seems flawed to
> me.  It seems an IP is an IP.
> 
> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
> 
> I think I could announce private IP space, so doesn't that make this
> argument invalid?  I've always looked at private IP space as more of a
> resource and management choice and not a security feature.

Yes, the author of this article is sadly mistaken and woefully void
of clue on the issues he attempts to address.

You are completely correct.

Owen



From rdobbins at arbor.net  Mon Nov 14 00:21:47 2011
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 14 Nov 2011 06:21:47 +0000
Subject: Arguing against using public IP space
In-Reply-To: <201111140224.pAE2OTjX061150@aurora.sol.net>
References: <201111140224.pAE2OTjX061150@aurora.sol.net>
Message-ID: <EF60C45B-4227-4EF9-BFAF-FB96473F8670@arbor.net>

On Nov 14, 2011, at 9:24 AM, Joe Greco wrote:

> Getting fixated on air-gapping is unrealistically ignoring the other threats out there.

I don't think anyone in this thread is 'fixated' on the idea of airgapping; but it's generally a good idea whenever possible, and as restrictive a communications policy as is possible is definitely called for, amongst all the other things one ought to be doing.

It's also important to note that it's often impossible to *completely* airgap things, these days, due to various interdependencies, admin requirements (mentioned before), and so forth; perhaps bastioning is a more apt term.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From gaileywg at MANSFIELDCT.ORG  Mon Nov 14 08:42:32 2011
From: gaileywg at MANSFIELDCT.ORG (Sam (Walter) Gailey)
Date: Mon, 14 Nov 2011 14:42:32 +0000
Subject: Cable standards question
Message-ID: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>

Hello, newbie question of the morning time, but hopefully not too off-topic...

I run a small town network. A new building is being built that the town wants fiber access to. I have to specify for vendors what it is that the town expects in the cabling. I am (obviously) not a fiber expert, and I'm having trouble phrasing the language of the RFP so that we are assured a quality installation.

My question is this; Is there an appropriate standard to specify for fiber-optic cabling that if it is followed the fiber will be installed correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?

I'm envisioning something like;

"The vendor will provide fiber connectivity between (building A) and (building B). Vendor will be responsible for all building penetrations and terminations. When  installing the fiber-optic cable the vendor will follow the appropriate TIA/EIA 568 standards for fiber-optic cabling."

Any suggestions or examples of language would be very appreciated. Offlist contact is probably best.

Many thanks,

---Sam

From dseagrav at humancapitaldev.com  Mon Nov 14 08:57:31 2011
From: dseagrav at humancapitaldev.com (Daniel Seagraves)
Date: Mon, 14 Nov 2011 08:57:31 -0600
Subject: Cable standards question
In-Reply-To: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>
References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>
Message-ID: <9A40A794-56FE-4773-B6A8-7BAD9EDF77FE@humancapitaldev.com>


On Nov 14, 2011, at 8:42 AM, Sam (Walter) Gailey wrote:

> "The vendor will provide fiber connectivity between (building A) and (building B). Vendor will be responsible for all building penetrations and terminations. When  installing the fiber-optic cable the vendor will follow the appropriate TIA/EIA 568 standards for fiber-optic cabling."
> 
> Any suggestions or examples of language would be very appreciated. Offlist contact is probably best.

Is it appropriate to just say "When installing fiber-optic cable the vendor will ensure the resulting installation does not suck."?
That would seem to me to be the most direct solution to the problem. I mean, standards are all well and good, but what if the standard sucks?
Then you'd be up a creek.

Maybe there should be a legal definition of the concept of suck, so that suckage could be contractually minimized.



From jgreco at ns.sol.net  Mon Nov 14 08:58:37 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Mon, 14 Nov 2011 08:58:37 -0600 (CST)
Subject: Arguing against using public IP space
In-Reply-To: <4EC08421.80708@bogus.com>
Message-ID: <201111141458.pAEEwcS6072727@aurora.sol.net>

> On 11/14/11 10:24 , Joe Greco wrote:
> >> Sure, anytime there's an attack or failure on a SCADA network that
> >> wouldn't have occurred had it been air-gapped, it's easy for people to
> >> knee-jerk a "SCADA networks should be airgapped" response.  But that's
> >> not really intelligent commentary unless you carefully consider what
> >> risks are associated with air-gapping the network.
> > 
> > Not to mention that it's not the only way for these things to get
> > infected.  Getting fixated on air-gapping is unrealistically ignoring
> > the other threats out there.
> > 
> > There needs to be a whole lot more security work done on SCADA nets.
> 
> Stuxnet should provide a fairly illustrative example.
> 
> It doesn't really matter how well isolated from direct access it is if
> it has a soft gooey center and a willing attacker.

That's basically the case for so many things.

I was reading, recently, two articles on Ars Technica ("Die, VPN" and
"Live, VPN") which made it exceedingly clear that these sorts of designs
are still the rule for most companies.  I mean, I already knew that, but
it was *depressing* to read.

We've been very successful for many years designing things as though they
were going to be deployed on the public Internet, even if we do still put
them behind a firewall.  That's just belt-and-suspenders common sense.

We do run a VPN service, which I use heavily, but it really has little
to do with granting magical access to resources - the VPN endpoint is
actually outside any firewall.  I've so frequently found, over the years,
that some "free" Internet connection offering is crippled in some stupid
manner (transparent proxying with ad injection!), that the value added
is mostly just that of getting an Internet connection with no interference
by third parties.  The fact that third parties cannot do any meaningful
snooping is nice too.

I also recall a fairly surreal discussion with a NANOG'er who was
absolutely convinced that SSH key based access to other servers was
more secure than password based access along with some ACL's and
something like sshguard; my point was that compromise of the magic
host with the magic key would tend to be worse (because you've suddenly
got access to all the other servers) while having different secure
passwords for each host, along with some ACL's and sshguard, allow you
to retain some isolation within the network from an infected node.  It's
dependent on design and forethought, of course...  

Basically, getting access to some point in the network shouldn't really
allow you to go on a rampage through the rest of the network.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From rps at maine.edu  Mon Nov 14 09:00:36 2011
From: rps at maine.edu (Ray Soucy)
Date: Mon, 14 Nov 2011 10:00:36 -0500
Subject: Arguing against using public IP space
In-Reply-To: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
Message-ID: <CALFTrnMGODeixe2g0eg_gTmZvkL_89LSFtdgW4E5SZ-Qq1Xjbw@mail.gmail.com>

As far as I can see Red Tiger Security is Jonathan Pollet; and even
though they list Houston, Dubai, Milan, and Sydney as offices it looks
like Houston is the only one.? Is that right?? Seems a little
misleading.

It actually reminds me of a 16 year old kid I know who runs a web
hosting "company" that you'd think was a Fortune 500 by the way the
website reads, and he's more than happy to take your credit card
information and store it without being PCI compliant.

Credibility of the company aside,

At first I wanted to cut Jonathan some slack.? If he was going to
point to the use of public IPs as evidence that a firewall may not be
in use and then went on to discuss the potential risks of not having
any security, then that would have been appropriate.? But instead he
goes on about explaining what a public vs. private address is (poorly)
and proceeds to associate the security of the system with the use of
private IPs.

I just don't see him as credible in the security field after reading it.

Then again, he does have that interview on Fox News posted on his
website where he talks about terrorist plots to compromise the
integrity of nuclear power plants...

Honestly, people post stuff like this time and time again.  It's been
debunked so many times that a quick Google will probably give you what
you need to figure it out on your own.

On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis <jlewis at packetnexus.com> wrote:
> I don't want to start a flame war, but this article seems flawed to
> me. ?It seems an IP is an IP.
>
> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>
> I think I could announce private IP space, so doesn't that make this
> argument invalid? ?I've always looked at private IP space as more of a
> resource and management choice and not a security feature.
>
>



--
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From jgreco at ns.sol.net  Mon Nov 14 09:05:01 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Mon, 14 Nov 2011 09:05:01 -0600 (CST)
Subject: Arguing against using public IP space
In-Reply-To: <EF60C45B-4227-4EF9-BFAF-FB96473F8670@arbor.net>
Message-ID: <201111141505.pAEF51jX072831@aurora.sol.net>

> On Nov 14, 2011, at 9:24 AM, Joe Greco wrote:
> > Getting fixated on air-gapping is unrealistically ignoring the other thre=
> ats out there.
> 
> I don't think anyone in this thread is 'fixated' on the idea of airgapping;=

No, but it's clear that there are many designers out there who feel this
is the way to go.  That's why it's a good idea to cover the ground anyways.

>  but it's generally a good idea whenever possible, and as restrictive a com=
> munications policy as is possible is definitely called for, amongst all the=
>  other things one ought to be doing.

I think the part people forget about is that last part, "amongst all the
other things one ought to be doing."

> It's also important to note that it's often impossible to *completely* airg=
> ap things, these days, due to various interdependencies, admin requirements=
>  (mentioned before), and so forth; perhaps bastioning is a more apt term.

If it didn't turn into a situation where everyone's bastardizing^Wbastioning
your network in insecure ways.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From jlewis at lewis.org  Mon Nov 14 09:12:35 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 14 Nov 2011 10:12:35 -0500 (EST)
Subject: Cable standards question
In-Reply-To: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>
References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>
Message-ID: <Pine.LNX.4.61.1111141002570.24418@soloth.lewis.org>

On Mon, 14 Nov 2011, Sam (Walter) Gailey wrote:

> My question is this; Is there an appropriate standard to specify for fiber-optic cabling that if it is followed the fiber will be installed correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?
>
> I'm envisioning something like;
>
> "The vendor will provide fiber connectivity between (building A) and 
> (building B). Vendor will be responsible for all building penetrations 
> and terminations. When installing the fiber-optic cable the vendor will 
> follow the appropriate TIA/EIA 568 standards for fiber-optic cabling."

At minimum, I think you should probably specify the type and number of 
fibers you want.  i.e. Based on the distance and gear you'll be using, do 
you need single-mode, or will multi-mode do (as well as the core/cladding 
diameter)?  Generally, but not always, fiber uses one strand for transmit 
and another for receive, so a typical fiber run is done using duplex 
fiber.  Some optics can transmit and receive over one strand using 
different wavelengths.  You might even specify how you want the fiber 
terminated (SC, LC, cables hanging from the wall, fiber patch panel, 
etc.).

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From mike at cmkconsulting.com  Mon Nov 14 09:25:12 2011
From: mike at cmkconsulting.com (Mickey Fox)
Date: Mon, 14 Nov 2011 09:25:12 -0600
Subject: airgap / negligent homicide charge
Message-ID: <CAE5c7NJUUf1AcKqrD6zxef1LL+HU8xeCZLG5k8y8aW1obUXdow@mail.gmail.com>

The determination of whether a failure rises to the level of negligent
homicide will require a review of industry standards, company standards and
sometimes straight common-sence.

If the industry standard is airgap re security you are probably okay so
long as you review and address the very concerns and questions you are
raising in a responsible fashion that does not rely solely on expediency,
cost, etc., but looks to real-world scenarios and emergency / backup
procedures, equipment, testing and training.

Mickey Fox
CMK Consulting Services
On Nov 14, 2011 9:00 AM, <nanog-request at nanog.org> wrote:

> Send NANOG mailing list submissions to
>        nanog at nanog.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://mailman.nanog.org/mailman/listinfo/nanog
> or, via email, send a message with subject or body 'help' to
>        nanog-request at nanog.org
>
> You can reach the person managing the list at
>        nanog-owner at nanog.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NANOG digest..."
>
>
> Today's Topics:
>
>   1. Re: Arguing against using public IP space
>      (Valdis.Kletnieks at vt.edu)
>   2. Re: Arguing against using public IP space (Joel jaeggli)
>   3. Re: Arguing against using public IP space (Jimmy Hess)
>   4. Re: Arguing against using public IP space (Owen DeLong)
>   5. Re: Arguing against using public IP space (Dobbins, Roland)
>   6. Cable standards question (Sam (Walter) Gailey)
>   7. Re: Cable standards question (Daniel Seagraves)
>   8. Re: Arguing against using public IP space (Joe Greco)
>   9. Re: Arguing against using public IP space (Ray Soucy)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 13 Nov 2011 21:43:32 -0500
> From: Valdis.Kletnieks at vt.edu
> To: Brett Frankenberger <rbf+nanog at panix.com>
> Cc: NANOG <nanog at nanog.org>
> Subject: Re: Arguing against using public IP space
> Message-ID: <81357.1321238612 at turing-police.cc.vt.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> On Sun, 13 Nov 2011 19:14:59 CST, Brett Frankenberger said:
>
> > What if you air-gap the SCADA network of which you are in
> > administrative control, and then there's a failure on it, and the people
> > responsible for troubleshooting it can't do it remotely (because of the
> > air gap), so the trouble continues for an extra hour while they drive
> > to the office, and that extra hour of failure causes someone to die.
> > Should that result in a homicide charge?
>
> If you designed a life-critical airgapped network that didn't have a
> trained
> warm body at the NOC 24/7 with an airgapped management console, and hot
> (or at
> least warm) spares for both console and console monkey, yes, you *do*
> deserve
> that negligent homicide charge.
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 227 bytes
> Desc: not available
> URL: <
> http://mailman.nanog.org/pipermail/nanog/attachments/20111113/247b47fe/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 2
> Date: Mon, 14 Nov 2011 10:59:45 +0800
> From: Joel jaeggli <joelja at bogus.com>
> To: Joe Greco <jgreco at ns.sol.net>
> Cc: NANOG <nanog at nanog.org>
> Subject: Re: Arguing against using public IP space
> Message-ID: <4EC08421.80708 at bogus.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 11/14/11 10:24 , Joe Greco wrote:
> >> Sure, anytime there's an attack or failure on a SCADA network that
> >> wouldn't have occurred had it been air-gapped, it's easy for people to
> >> knee-jerk a "SCADA networks should be airgapped" response.  But that's
> >> not really intelligent commentary unless you carefully consider what
> >> risks are associated with air-gapping the network.
> >
> > Not to mention that it's not the only way for these things to get
> > infected.  Getting fixated on air-gapping is unrealistically ignoring
> > the other threats out there.
> >
> > There needs to be a whole lot more security work done on SCADA nets.
>
> Stuxnet should provide a fairly illustrative example.
>
> It doesn't really matter how well isolated from direct access it is if
> it has a soft gooey center and a willing attacker.
>
> > ... JG
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 13 Nov 2011 21:48:01 -0600
> From: Jimmy Hess <mysidia at gmail.com>
> To: David Walker <davidianwalker at gmail.com>
> Cc: nanog at nanog.org
> Subject: Re: Arguing against using public IP space
> Message-ID:
>        <CAAAwwbUSUzHO0q3vkBh3-sQHxnXc5=UE5w2R+MZ=Hmpa08wDhg at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Nov 13, 2011 at 3:03 PM, David Walker <davidianwalker at gmail.com>
> wrote:
> > On 14/11/2011, Jimmy Hess <mysidia at gmail.com> wrote:
> > A packet addressed to an endpoint that doesn't serve anything or have
> > a client listening will be ignered (whatever) as a matter of course.
> > Firewall or no firewall.
> It will not go to a listening application,  neither will it be
> completely ignored --
> the receiving machine's  TCP stack will have a look at the packet.
> On common operating systems there  are frequently unsafe applications
> listening on ports;  on certain OSes, there will be no way to turn off
> system applications,  or human error will leave them in place.
>
> > That's fundamental to TCP/IP and secure.
> It's fundamental to TCP/IP,  but not fundamentally secure.  TCP/IP
> implementations have flaws.
> If a host is meant solely as an endpoint, then it is exposed to undue
> risk, if arbitrary packets can be addressed to its TCP/IP stack that
> might have remotely exploitable bugs.
>
> > The only reason we firewall (packet filter) is to provide access
> > control (for whatever reason).
> No, we also firewall to block access entirely to applications
> attempting to establish a service on unapproved ports.    We also use
> firewalls in certain forms to ensure that communications over a TCP/IP
> socket comply with a protocol,  for example,  that a session
> terminated on port 25 is actually a SMTP session.
>
> The firewall might restrict the set of allowed SMTP commands, validate
> the syntax of certain commands,  hide server version information,
> prevent use of ESMTP pipelining from outside, etc.
>
> > I apologize in advance if this is too pedestrian (you might know this
> > but not agree with it) but I want to make a point:
> > http://en.wikipedia.org/wiki/End-to-end_connectivity
>
> End to end connectivity principal's purpose is not to provide
> security.    It is to facilitate communications with other hosts and
> networks.     When a private system _really_ has to be secure,  end to
> end connectivity is inherently incompatible  with security objectives.
>
> There is always a tradeoff involving sacrificing a level of security
> against remote attack
> when connecting a computer to a network,  and then again,  when
> connecting the network to the internet.
>
> A computer that is not connected to a network is perfectly secure
> against network-based attacks.
> A computer that is connected to LAN is at risk of potential
> network-based attack from that LAN.
>
> If that LAN is then connected through a firewall  through many to 1
> NAT,  there is another layer of risk added.
>
> If the NAT'ing firewall is then replaced with a simple many to 1 NAT
> router,  there is another layer of risk added; there are new attacks
> possible that still succeed in a NAT environment,  that the firewall
> would have stopped.
>
> Finally, if that that same computer is then given end to end
> connectivity with no firewall,  there is a much   less encumbered
> communications path available to that computer for launching
> network-based attack;  the attack surface is greatly increased in such
> a design.
>
> If we are talking about nodes that interface with a SCADA network;
> the concept of unfirewalled end-to-end connectivity approaches the
> level of insanity.
>
> Those are not systems where end-to-end public connectivity should be a
> priority over security.
>
> --
> -JH
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 13 Nov 2011 19:51:24 -0800
> From: Owen DeLong <owen at delong.com>
> To: Jason Lewis <jlewis at packetnexus.com>
> Cc: nanog at nanog.org
> Subject: Re: Arguing against using public IP space
> Message-ID: <2DE5DF4F-059C-4F39-81D4-363E49966282 at delong.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Nov 13, 2011, at 7:36 AM, Jason Lewis wrote:
>
> > I don't want to start a flame war, but this article seems flawed to
> > me.  It seems an IP is an IP.
> >
> >
> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
> >
> > I think I could announce private IP space, so doesn't that make this
> > argument invalid?  I've always looked at private IP space as more of a
> > resource and management choice and not a security feature.
>
> Yes, the author of this article is sadly mistaken and woefully void
> of clue on the issues he attempts to address.
>
> You are completely correct.
>
> Owen
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 14 Nov 2011 06:21:47 +0000
> From: "Dobbins, Roland" <rdobbins at arbor.net>
> To: NANOG Operators' Group <nanog at nanog.org>
> Subject: Re: Arguing against using public IP space
> Message-ID: <EF60C45B-4227-4EF9-BFAF-FB96473F8670 at arbor.net>
> Content-Type: text/plain; charset="us-ascii"
>
> On Nov 14, 2011, at 9:24 AM, Joe Greco wrote:
>
> > Getting fixated on air-gapping is unrealistically ignoring the other
> threats out there.
>
> I don't think anyone in this thread is 'fixated' on the idea of
> airgapping; but it's generally a good idea whenever possible, and as
> restrictive a communications policy as is possible is definitely called
> for, amongst all the other things one ought to be doing.
>
> It's also important to note that it's often impossible to *completely*
> airgap things, these days, due to various interdependencies, admin
> requirements (mentioned before), and so forth; perhaps bastioning is a more
> apt term.
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>                The basis of optimism is sheer terror.
>
>                          -- Oscar Wilde
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 14 Nov 2011 14:42:32 +0000
> From: "Sam (Walter) Gailey" <gaileywg at MANSFIELDCT.ORG>
> To: "nanog at nanog.org" <nanog at nanog.org>
> Subject: Cable standards question
> Message-ID:
>        <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2 at TN-Mail-1.mansfieldct.net
> >
> Content-Type: text/plain; charset="us-ascii"
>
> Hello, newbie question of the morning time, but hopefully not too
> off-topic...
>
> I run a small town network. A new building is being built that the town
> wants fiber access to. I have to specify for vendors what it is that the
> town expects in the cabling. I am (obviously) not a fiber expert, and I'm
> having trouble phrasing the language of the RFP so that we are assured a
> quality installation.
>
> My question is this; Is there an appropriate standard to specify for
> fiber-optic cabling that if it is followed the fiber will be installed
> correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?
>
> I'm envisioning something like;
>
> "The vendor will provide fiber connectivity between (building A) and
> (building B). Vendor will be responsible for all building penetrations and
> terminations. When  installing the fiber-optic cable the vendor will follow
> the appropriate TIA/EIA 568 standards for fiber-optic cabling."
>
> Any suggestions or examples of language would be very appreciated. Offlist
> contact is probably best.
>
> Many thanks,
>
> ---Sam
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 14 Nov 2011 08:57:31 -0600
> From: Daniel Seagraves <dseagrav at humancapitaldev.com>
> To: nanog at nanog.org
> Subject: Re: Cable standards question
> Message-ID: <9A40A794-56FE-4773-B6A8-7BAD9EDF77FE at humancapitaldev.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Nov 14, 2011, at 8:42 AM, Sam (Walter) Gailey wrote:
>
> > "The vendor will provide fiber connectivity between (building A) and
> (building B). Vendor will be responsible for all building penetrations and
> terminations. When  installing the fiber-optic cable the vendor will follow
> the appropriate TIA/EIA 568 standards for fiber-optic cabling."
> >
> > Any suggestions or examples of language would be very appreciated.
> Offlist contact is probably best.
>
> Is it appropriate to just say "When installing fiber-optic cable the
> vendor will ensure the resulting installation does not suck."?
> That would seem to me to be the most direct solution to the problem. I
> mean, standards are all well and good, but what if the standard sucks?
> Then you'd be up a creek.
>
> Maybe there should be a legal definition of the concept of suck, so that
> suckage could be contractually minimized.
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 14 Nov 2011 08:58:37 -0600 (CST)
> From: Joe Greco <jgreco at ns.sol.net>
> To: joelja at bogus.com (Joel jaeggli)
> Cc: NANOG <nanog at nanog.org>
> Subject: Re: Arguing against using public IP space
> Message-ID: <201111141458.pAEEwcS6072727 at aurora.sol.net>
> Content-Type: text/plain; charset=us-ascii
>
> > On 11/14/11 10:24 , Joe Greco wrote:
> > >> Sure, anytime there's an attack or failure on a SCADA network that
> > >> wouldn't have occurred had it been air-gapped, it's easy for people to
> > >> knee-jerk a "SCADA networks should be airgapped" response.  But that's
> > >> not really intelligent commentary unless you carefully consider what
> > >> risks are associated with air-gapping the network.
> > >
> > > Not to mention that it's not the only way for these things to get
> > > infected.  Getting fixated on air-gapping is unrealistically ignoring
> > > the other threats out there.
> > >
> > > There needs to be a whole lot more security work done on SCADA nets.
> >
> > Stuxnet should provide a fairly illustrative example.
> >
> > It doesn't really matter how well isolated from direct access it is if
> > it has a soft gooey center and a willing attacker.
>
> That's basically the case for so many things.
>
> I was reading, recently, two articles on Ars Technica ("Die, VPN" and
> "Live, VPN") which made it exceedingly clear that these sorts of designs
> are still the rule for most companies.  I mean, I already knew that, but
> it was *depressing* to read.
>
> We've been very successful for many years designing things as though they
> were going to be deployed on the public Internet, even if we do still put
> them behind a firewall.  That's just belt-and-suspenders common sense.
>
> We do run a VPN service, which I use heavily, but it really has little
> to do with granting magical access to resources - the VPN endpoint is
> actually outside any firewall.  I've so frequently found, over the years,
> that some "free" Internet connection offering is crippled in some stupid
> manner (transparent proxying with ad injection!), that the value added
> is mostly just that of getting an Internet connection with no interference
> by third parties.  The fact that third parties cannot do any meaningful
> snooping is nice too.
>
> I also recall a fairly surreal discussion with a NANOG'er who was
> absolutely convinced that SSH key based access to other servers was
> more secure than password based access along with some ACL's and
> something like sshguard; my point was that compromise of the magic
> host with the magic key would tend to be worse (because you've suddenly
> got access to all the other servers) while having different secure
> passwords for each host, along with some ACL's and sshguard, allow you
> to retain some isolation within the network from an infected node.  It's
> dependent on design and forethought, of course...
>
> Basically, getting access to some point in the network shouldn't really
> allow you to go on a rampage through the rest of the network.
>
> ... JG
> --
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> "We call it the 'one bite at the apple' rule. Give me one chance [and]
> then I
> won't contact you again." - Direct Marketing Ass'n position on e-mail
> spam(CNN)
> With 24 million small businesses in the US alone, that's way too many
> apples.
>
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 14 Nov 2011 10:00:36 -0500
> From: Ray Soucy <rps at maine.edu>
> To: Jason Lewis <jlewis at packetnexus.com>
> Cc: nanog at nanog.org
> Subject: Re: Arguing against using public IP space
> Message-ID:
>        <CALFTrnMGODeixe2g0eg_gTmZvkL_89LSFtdgW4E5SZ-Qq1Xjbw at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> As far as I can see Red Tiger Security is Jonathan Pollet; and even
> though they list Houston, Dubai, Milan, and Sydney as offices it looks
> like Houston is the only one.? Is that right?? Seems a little
> misleading.
>
> It actually reminds me of a 16 year old kid I know who runs a web
> hosting "company" that you'd think was a Fortune 500 by the way the
> website reads, and he's more than happy to take your credit card
> information and store it without being PCI compliant.
>
> Credibility of the company aside,
>
> At first I wanted to cut Jonathan some slack.? If he was going to
> point to the use of public IPs as evidence that a firewall may not be
> in use and then went on to discuss the potential risks of not having
> any security, then that would have been appropriate.? But instead he
> goes on about explaining what a public vs. private address is (poorly)
> and proceeds to associate the security of the system with the use of
> private IPs.
>
> I just don't see him as credible in the security field after reading it.
>
> Then again, he does have that interview on Fox News posted on his
> website where he talks about terrorist plots to compromise the
> integrity of nuclear power plants...
>
> Honestly, people post stuff like this time and time again.  It's been
> debunked so many times that a quick Google will probably give you what
> you need to figure it out on your own.
>
> On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis <jlewis at packetnexus.com>
> wrote:
> > I don't want to start a flame war, but this article seems flawed to
> > me. ?It seems an IP is an IP.
> >
> >
> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
> >
> > I think I could announce private IP space, so doesn't that make this
> > argument invalid? ?I've always looked at private IP space as more of a
> > resource and management choice and not a security feature.
> >
> >
>
>
>
> --
> Ray Soucy
>
> Epic Communications Specialist
>
> Phone: +1 (207) 561-3526
>
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/
>
>
>
> End of NANOG Digest, Vol 46, Issue 43
> *************************************
>

From jof at thejof.com  Mon Nov 14 09:38:38 2011
From: jof at thejof.com (Jonathan Lassoff)
Date: Mon, 14 Nov 2011 07:38:38 -0800
Subject: Cable standards question
In-Reply-To: <Pine.LNX.4.61.1111141002570.24418@soloth.lewis.org>
References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>
 <Pine.LNX.4.61.1111141002570.24418@soloth.lewis.org>
Message-ID: <CAHsqw9sqW8E=z9kk7yjUy5+E6_EzpjNW83krmmGBUL3C11a8rA@mail.gmail.com>

On Mon, Nov 14, 2011 at 7:12 AM, Jon Lewis <jlewis at lewis.org> wrote:

> On Mon, 14 Nov 2011, Sam (Walter) Gailey wrote:
>
>  My question is this; Is there an appropriate standard to specify for
>> fiber-optic cabling that if it is followed the fiber will be installed
>> correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?
>>
>> I'm envisioning something like;
>>
>> "The vendor will provide fiber connectivity between (building A) and
>> (building B). Vendor will be responsible for all building penetrations and
>> terminations. When installing the fiber-optic cable the vendor will follow
>> the appropriate TIA/EIA 568 standards for fiber-optic cabling."
>>
>
> At minimum, I think you should probably specify the type and number of
> fibers you want.  i.e. Based on the distance and gear you'll be using, do
> you need single-mode, or will multi-mode do (as well as the core/cladding
> diameter)?  Generally, but not always, fiber uses one strand for transmit
> and another for receive, so a typical fiber run is done using duplex fiber.
>  Some optics can transmit and receive over one strand using different
> wavelengths.  You might even specify how you want the fiber terminated (SC,
> LC, cables hanging from the wall, fiber patch panel, etc.).
>

I'd agree with this. I wouldn't worry about the standard so much as the
practical aspects of a run. Once you have an idea of the approximate
distance of the run, you can figure out which optics you plan on using.
This will determine what physical connectors you'll need and what your
approximate link budget will be.

Based on that information, you can figure out which type to ask for
(9um/125um single-mode, most likely), a range of path loss that you're
comfortable with, and the physical termination you'd like at either end.

Cheers,
jof

From jra at baylink.com  Mon Nov 14 09:59:37 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 14 Nov 2011 10:59:37 -0500 (EST)
Subject: Cable standards question
In-Reply-To: <CAHsqw9sqW8E=z9kk7yjUy5+E6_EzpjNW83krmmGBUL3C11a8rA@mail.gmail.com>
Message-ID: <30391048.2725.1321286377294.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jonathan Lassoff" <jof at thejof.com>

> I'd agree with this. I wouldn't worry about the standard so much as the
> practical aspects of a run. Once you have an idea of the approximate
> distance of the run, you can figure out which optics you plan on
> using. This will determine what physical connectors you'll need and what your
> approximate link budget will be.
> 
> Based on that information, you can figure out which type to ask for
> (9um/125um single-mode, most likely), a range of path loss that you're
> comfortable with, and the physical termination you'd like at either
> end.

You Jon people[1] are, as near as I can tell, answering a question the OP didn't
actually ask.  It may in fact be that he didn't realize he should spec the 
design down to that level, but it sounded to me like what he was looking for
was "what language should I put in there to constrain the quality of the
implementation?"

Cheers,
-- jra
[1] :-)
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From chipps at chipps.com  Mon Nov 14 10:05:52 2011
From: chipps at chipps.com (Kenneth M. Chipps Ph.D.)
Date: Mon, 14 Nov 2011 10:05:52 -0600
Subject: Cable standards question
In-Reply-To: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>
References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>
Message-ID: <003901cca2e7$49361d10$dba25730$@chipps.com>

BICSI has a sample RFQ for this purpose. You can use the whole thing or just
pull out the cabling phrase. You will need to update the standard names to
the current ones.

https://www.bicsi.org/single.aspx?l=1866

Kenneth M. Chipps Ph.D.

-----Original Message-----
From: Sam (Walter) Gailey [mailto:gaileywg at MANSFIELDCT.ORG] 
Sent: Monday, November 14, 2011 8:43 AM
To: nanog at nanog.org
Subject: Cable standards question

Hello, newbie question of the morning time, but hopefully not too
off-topic...

I run a small town network. A new building is being built that the town
wants fiber access to. I have to specify for vendors what it is that the
town expects in the cabling. I am (obviously) not a fiber expert, and I'm
having trouble phrasing the language of the RFP so that we are assured a
quality installation.

My question is this; Is there an appropriate standard to specify for
fiber-optic cabling that if it is followed the fiber will be installed
correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?

I'm envisioning something like;

"The vendor will provide fiber connectivity between (building A) and
(building B). Vendor will be responsible for all building penetrations and
terminations. When  installing the fiber-optic cable the vendor will follow
the appropriate TIA/EIA 568 standards for fiber-optic cabling."

Any suggestions or examples of language would be very appreciated. Offlist
contact is probably best.

Many thanks,

---Sam




From streiner at cluebyfour.org  Mon Nov 14 10:07:40 2011
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Mon, 14 Nov 2011 11:07:40 -0500 (EST)
Subject: Cable standards question
In-Reply-To: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>
References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>
Message-ID: <Pine.LNX.4.64.1111141030480.1046@whammy.cluebyfour.org>

On Mon, 14 Nov 2011, Sam (Walter) Gailey wrote:

> My question is this; Is there an appropriate standard to specify for 
> fiber-optic cabling that if it is followed the fiber will be installed 
> correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?
>
> I'm envisioning something like;
>
> "The vendor will provide fiber connectivity between (building A) and 
> (building B). Vendor will be responsible for all building penetrations 
> and terminations. When  installing the fiber-optic cable the vendor will 
> follow the appropriate TIA/EIA 568 standards for fiber-optic cabling."

How you phrase the requirements depends on what you want the end result to 
be.  Sorry to start this off with a wishy-washy statement, but when 
dealing with contractors, you have to be very specific with what you want, 
and stay involved during the project, to be sure the results are what you 
want.

It's a good idea to define very clearly what is "in scope" and "out of 
scope" for the contractor up front.  This can include things like the 
contractor being responsible for submitting any one-call requests 
per your localities' guidelines for any work that requires digging, or 
restoring any items that have to be removed (landscaping, sidewalks, 
paved roadways, etc) to facilitate digging.

For example, do the buildings in question already have usable entrance 
facilities for communications (aerial/underground entrances, suitable 
demarc locations in each building, cable pathways from the exterior 
penetrations to the demarc point)?  If not, you will generally need to 
spell out exactly what the fiber contractor (or a sub-contractor) is 
expected to provide (conduits from comms manhole/utility vault/pole/etc). 
Typically you will need to define a place in each building where the 
fiber will land, which will either be in a rack or on a wall.

Also, at a minimum, the contractor should 1. test all strands at the 
appropriate wavelengths, 2. provide you with documentation of the test 
results, and 3. general fit-and-finish/workmanship items such as making 
sure all connectors have dust caps and any required labeling of the 
termination bays.

Where I work, we have detailed construction / installation standards that 
get added to the bid package of any new construction or major renovation 
on our campus.  If you want, I can send you a copy (off-list) of the 
relevant pieces of our Division 27 specs that go out to contractors as 
part of our construction bid packages.

jms



From jasongurtz at npumail.com  Mon Nov 14 10:56:52 2011
From: jasongurtz at npumail.com (Jason Gurtz)
Date: Mon, 14 Nov 2011 11:56:52 -0500
Subject: Cable standards question
In-Reply-To: <Pine.LNX.4.64.1111141030480.1046@whammy.cluebyfour.org>
References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>
 <Pine.LNX.4.64.1111141030480.1046@whammy.cluebyfour.org>
Message-ID: <A92EAF652EC423438D55C14C60771C87040387C0@exchgsrv.nputilities.local>

> How you phrase the requirements depends on what you want the end result
> to be.  Sorry to start this off with a wishy-washy statement, but when
> dealing with contractors, you have to be very specific with what you
> want, and stay involved during the project, to be sure the results are
> what you want.

This is *really* great advice. Standards are good, but it pays to have
due-diligence done about specific products and methods.

To the OP:

I witnessed a municipal fiber build-out, managed by someone in another
department who had essentially zero networking experience. His
consultants' all seemed experienced in conceptual layout, but not so much
the specific physical details. While this project was basically a success,
99% of the difficulties had to do with physical access details, site
remediation (power, racks, site-local cabling), and the specific fiber
related equipment such as splice boxes and patch panels.

For instance, we ended up with a 23" telco rack filled with 19" equipment
and 23" to 19" converter panels. General tidiness; a contractor left a
large splice-box laying on the floor in the midst of a slack-spool instead
of wall or rack mounting. Another contractor developed a spider's nest of
wiring in our server room instead of structured cabling. Specifying exact
rack sizes, specific cable management, mounting locations, etc... would
have helped a lot. Photos of the specific areas would have helped
immensely.

Some of the delivered patch panels were of low quality (many of the
connectors were faulty, requiring extra labor to clean and re-polish).
Caveat emptor! Find what the good brands are and specify (maybe others can
comment here). Go take a look at vendor websites like Middle Atlantic and
see what options are out there. Some things are just easier and more
convenient to use. The devil is in the details.

A building-to-building connection is clearly easier than lighting up a
city but you will still be stuck with what you get. You can never plan
enough.

~JasonG


From dholmes at mwdh2o.com  Mon Nov 14 11:31:50 2011
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Mon, 14 Nov 2011 09:31:50 -0800
Subject: Cable standards question
In-Reply-To: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>
References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>
Message-ID: <922ACC42D498884AA02B3565688AF99534019DB3E0@USEXMBS01.mwd.h2o>

Formal construction contract bids use the Construction Specification Institute (CSI) format. There are 2 versions, I am familiar with and use the 1998 version. The 1998 CSI format is broken up into 16 divisions (mechanical, civil, electrical, architectural, etc.). Electrical, where network cabling specs reside in the CSI 1998 version, are located in Division 16. The standard fiber optic spec is Division 16 16745. A web search on "fiber optic 16745 spec" will turn up various examples from real fiber optic construction bids, usually government contracts for large-scale construction projects such as highways, University campuses, municipal fiber builds, etc.

My suggestion is to look at existing 16745 specs, and modify them to your requirements.

-----Original Message-----
From: Sam (Walter) Gailey [mailto:gaileywg at MANSFIELDCT.ORG]
Sent: Monday, November 14, 2011 6:43 AM
To: nanog at nanog.org
Subject: Cable standards question

Hello, newbie question of the morning time, but hopefully not too off-topic...

I run a small town network. A new building is being built that the town wants fiber access to. I have to specify for vendors what it is that the town expects in the cabling. I am (obviously) not a fiber expert, and I'm having trouble phrasing the language of the RFP so that we are assured a quality installation.

My question is this; Is there an appropriate standard to specify for fiber-optic cabling that if it is followed the fiber will be installed correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?

I'm envisioning something like;

"The vendor will provide fiber connectivity between (building A) and (building B). Vendor will be responsible for all building penetrations and terminations. When  installing the fiber-optic cable the vendor will follow the appropriate TIA/EIA 568 standards for fiber-optic cabling."

Any suggestions or examples of language would be very appreciated. Offlist contact is probably best.

Many thanks,

---Sam

This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.


From network.ipdog at gmail.com  Mon Nov 14 12:31:30 2011
From: network.ipdog at gmail.com (Network IP Dog)
Date: Mon, 14 Nov 2011 10:31:30 -0800
Subject: Copper not dead for super-fast broadband,
 says BT | Networking | ZDNet UK
Message-ID: <4ec15e90.b39c440a.60a9.03a0@mx.google.com>

http://www.zdnet.co.uk/news/networking/2011/11/11/copper-not-dead-for-super-
fast-broadband-says-bt-40094401/?ps=twitter

From Gabriel.McCall at thyssenkrupp.com  Mon Nov 14 12:50:20 2011
From: Gabriel.McCall at thyssenkrupp.com (McCall, Gabriel)
Date: Mon, 14 Nov 2011 13:50:20 -0500
Subject: Arguing against using public IP space
In-Reply-To: <002201cca25f$6c5340d0$44f9c270$@com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
Message-ID: <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>

Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet.

The fact that consumer cpe's typically do both nat and stateful firewalling does not mean that those functions are inseparable.


-----Original message-----
From: Chuck Church <chuckchurch at gmail.com>
To: &apos;Phil Regnauld&apos; <regnauld at nsrc.org>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Sent: Sun, Nov 13, 2011 23:53:19 GMT+00:00
Subject: RE: Arguing against using public IP space

-----Original Message-----
From: Phil Regnauld [mailto:regnauld at nsrc.org]


> PAT (overload) will have ports open listening for return traffic,
> on the external IP that's being "overloaded".

> What happens if you initiate traffic directed at the RFC1918
> network itself, and send that to the MAC address of the NAT device ?

> In many cases, it just works. That's how IP forwarding works, after
> all :)
>
> inside net ----------[NAT]-----------{ext net}----[attacker]
> 192.168.0.0/24 .254 1.2.3.4 1.2.3.5

> S:1.2.3.5 D:192.168.0.1 next hop: 1.2.3.4
>
> Now, on the way back *out* from the inside net, traffic from
> 192.168.0.1 back to 1.2.3.4 might get translated - it depends if
> what the NAT is programmed to do if it sees, say, a S/A packet
> with no corresponding SYN, on its way out. It might just get
> dropped. UDP would in some cases get natted, but since you
> know your destination port on 1.2.3.5, you know what to expect,
> and you can build an asymmetric connection since you control the
> attacking host.
>
> Either way, you've still injected traffic into the inside net.
>

That makes sense, but I'm wondering if that should be considered correct
behavior. Obviously a non-consumer grade router can have rules defining
what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
everything coming from the outside in to either a) match up with something
in the translation table, b) be a service the router itself is hosting
(http, etc), or c) be a port it explicitly forwards to the same inside host.
Anything not matching one of those 3 categories you'd think could be
dropped. Routing without translating ports and addresses seems like the
root of the issue.

Chuck




From charlesg at unixrealm.com  Mon Nov 14 13:11:08 2011
From: charlesg at unixrealm.com (Charles Gagnon)
Date: Mon, 14 Nov 2011 14:11:08 -0500
Subject: packet loss out of Texas on Cogent and GlobalCrossing
Message-ID: <CAJT7Wriwt_2aV3+MCBuEsW4hYLuF=NL34RT3XX3mY4Q4nMTT0g@mail.gmail.com>

I need the Nanog intellect,

We are seeing packet loss in certain scenarios only on traffic to and
from Austin, TX. The local provider is Time Warner and they are not
having (obvious) problems. We ran tests from NY and NJ over Internap
and AboveNet connections.We only see problems when the traffic goes
over gblx or cogent. Has anyone heard of problem with these carriers
out of Texas?
-- 
Charles Gagnon
charlesg at unixrealm.com


From bill at herrin.us  Mon Nov 14 13:32:24 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 14 Nov 2011 14:32:24 -0500
Subject: Arguing against using public IP space
In-Reply-To: <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us>
 <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
Message-ID: <CAP-guGVZH+Ffb=_h64dVe6wZL=1yYhvn1+iao5-KFJejgcO1jA@mail.gmail.com>

On Mon, Nov 14, 2011 at 1:50 PM, McCall, Gabriel
<Gabriel.McCall at thyssenkrupp.com> wrote:
> Chuck, you're right that this should not happen- but
> the reason it should not happen is because you have
> a properly functioning stateful firewall, not because
> you're using NAT. If your firewall is working properly,
> then having public addresses behind it is no less secure
> than private. And if your firewall is not working properly,
> then having private addresses behind it is no
> more secure than public. In either case, NAT gains
> you nothing over what you'd have with a firewalled
> public-address subnet.
>
> The fact that consumer cpe's typically do both nat
> and stateful firewalling does not mean that those
> functions are inseparable.

Gabriel,

This is not accurate.

First, many:1 NAT (sometimes also called PAT) is not separable from a
stateful firewall. You can build a stateful firewall without
many-to-one NAT but the reverse is not possible.

Second, while a security benefit from RFC 1918 addressing combined
with 1:1 NAT is dubious at best, the same is not true for the much
more commonly implemented many:1 NAT.

With RFC1918 plus many:1 NAT, most if not all functions of the
interior of the network are not addressable from far locations outside
the network, regardless of the correct or incorrect operation of the
security apparatus. This is an additional boundary which must be
bypassed in order to gain access to the network interior. While there
are a variety of techniques for circumventing this boundary no
combination of them guarantees successful breach. Hence it provides a
security benefit all on its own.

You would not rely on NAT+RFC1918 alone to secure a network and
neither would I. However, that's far from meaning that the use of
RFC1918 is never (or even rarely) operative in a network's security
process.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jra at baylink.com  Mon Nov 14 13:46:21 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 14 Nov 2011 14:46:21 -0500 (EST)
Subject: Cable standards question
In-Reply-To: <A92EAF652EC423438D55C14C60771C87040387C0@exchgsrv.nputilities.local>
Message-ID: <29777640.2763.1321299981428.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jason Gurtz" <jasongurtz at npumail.com>

> For instance, we ended up with a 23" telco rack filled with 19" equipment
> and 23" to 19" converter panels. General tidiness; a contractor left a
> large splice-box laying on the floor in the midst of a slack-spool instead
> of wall or rack mounting. Another contractor developed a spider's nest of
> wiring in our server room instead of structured cabling. Specifying exact
> rack sizes, specific cable management, mounting locations, etc... would
> have helped a lot. Photos of the specific areas would have helped
> immensely.

This seems like an altogether excellent time for me to remind people about

  http://bestpractices.wikia.com

and volunteer it[1] as a place in which to capture these sorts of, among other
things, pictures of installs, both good and bad -- along with notes as to
*why* they are specifically good and/or bad.

Cheers,
-- jra
[1]Yes, it's gotten a bit spammed up; I'll clean it out if you'll use it.  ;-)
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From charlesg at unixrealm.com  Mon Nov 14 14:52:27 2011
From: charlesg at unixrealm.com (Charles Gagnon)
Date: Mon, 14 Nov 2011 15:52:27 -0500
Subject: packet loss out of Texas on Cogent and GlobalCrossing
In-Reply-To: <03af01cca302$dae14440$90a3ccc0$@truenet.com>
References: <CAJT7Wriwt_2aV3+MCBuEsW4hYLuF=NL34RT3XX3mY4Q4nMTT0g@mail.gmail.com>
 <03af01cca302$dae14440$90a3ccc0$@truenet.com>
Message-ID: <CAJT7WrjP0g_7h-zOssL32zhypT05dtm2HJa4g0n+0nNZqnQdbA@mail.gmail.com>

Good point, I can't seem to reproduce with the looking glass
interfaces out there. They either don't use enough packets in sequence
or don't through the problem hops. On this path:

Send ICMP echos to 24.227.216.194, timeout is 2 seconds, ?maximum hops
are 32,1 ? ? ? 0ms ? ? 1ms ? ? 0ms ? ? 74.201.153.2212 ? ? ? 143ms
10ms ? ?0ms ? ? 216.52.95.893 ? ? ? 1ms ? ? 1ms ? ? 1ms
77.67.70.974 ? ? ? 1ms ? ? 1ms ? ? 1ms ? ? 213.200.66.2105 ? ? ? 3ms
? 1ms ? ? 2ms ? ? 66.198.111.976 ? ? ? 19ms ? ?7ms ? ? 7ms
216.6.87.97 ? ? ? 7ms ? ? 7ms ? ? 7ms ? ? 216.6.87.28 ? ? ? 6ms
7ms ? ? 7ms ? ? 66.198.154.149 ? ? ? 6ms ? ? 7ms ? ? 6ms
107.14.19.13210 ? ? ?107ms ? 108ms ? 113ms ? 66.109.10.1111 ? ? ?118ms
? 144ms ? 120ms ? 107.14.17.13912 ? ? ?119ms ? 120ms ? 120ms
72.179.205.5913 ? ? ?115ms ? 115ms ? 114ms ? 24.73.240.19514
115ms ? 115ms ? 115ms ? 24.73.240.252
I re-tested and using 100 msg counts, I get 3-6% packet loss on
anything after 10. On hops 1-10, I'm all clean. That 66.109.10.11
address is inside TimeWarner/RR so I'll keep trying to contact them.


On Mon, Nov 14, 2011 at 2:23 PM, Eric Tykwinski <eric-list at truenet.com> wrote:
> Have you check the relevant looking glass sites?
>
> http://www.cogentco.com/en/network/looking-glass
> http://www.globalcrossing.com/network/network_looking_glass.aspx
>
> We are connected to both providers, so everything is looking clean for us.
>
> Sincerely,
>
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
> F: 610-429-3222
>
> -----Original Message-----
> From: Charles Gagnon [mailto:charlesg at unixrealm.com]
> Sent: Monday, November 14, 2011 2:11 PM
> To: nanog at nanog.org
> Subject: packet loss out of Texas on Cogent and GlobalCrossing
>
> I need the Nanog intellect,
>
> We are seeing packet loss in certain scenarios only on traffic to and from
> Austin, TX. The local provider is Time Warner and they are not having
> (obvious) problems. We ran tests from NY and NJ over Internap and AboveNet
> connections.We only see problems when the traffic goes over gblx or cogent.
> Has anyone heard of problem with these carriers out of Texas?
> --
> Charles Gagnon
> charlesg at unixrealm.com
>
>
>



-- 
Charles Gagnon
charlesg at unixrealm.com


From jra at baylink.com  Mon Nov 14 14:55:14 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 14 Nov 2011 15:55:14 -0500 (EST)
Subject: Ok; let's have the "Does DNAT contribute to Security" argument one
 more time...
In-Reply-To: <29935980.2769.1321304092428.JavaMail.root@benjamin.baylink.com>
Message-ID: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>

Kill this subject if you're sick of it.

----- Original Message -----
> From: "Gabriel McCall" <Gabriel.McCall at thyssenkrupp.com>

>                                        If your firewall is working
> properly, then having public addresses behind it is no less secure
> than private. And if your firewall is not working properly, then
> having private addresses behind it is no more secure than public.

This assertion is frequently made -- it was made a couple other times
this morning -- but I continue to think that it doesn't hold much water,
primarly because it doesn't take into account *the probability of various
potential failure modes in a firewall*.

The basic assertion made by proponents of this theory, when analyzed,
amounts to "the probability that a firewall between a publicly routable 
internal network and the internet will fail in such a fashion as to pass
packets addressed to internal machines is of the same close order as the
probability that a DNAT router will fail in such a fashion as to allow
people outside it to address packets to *arbitrary* internal machine IP
addresses (assuming they have any way to determine what those are)."

Hopefully, my rephrasing makes it clearer why those of us who believe that
there is, in fact, *some* extra security contributed by RFC 1918 and DNAT
in the over all stack tend not to buy the arguments of those who say that
in fact, it contributes none: they never show their work, so we cannot 
evaluate their assertions.

But in fact, as someone pointed out this morning in the original thread:
even if you happen to *know* the internal 1918 IP of the NATted target, 
the default failure mode of the NAT box is "stop forwarding packets into
private network at all".

Certainly, individual NAT boxes can have other failure modes, but each of
those extra layers adds at least another 0 to the probability p-number,
in my not-a-mathematician estimation.

On the other hand, since a firewall's job is to stop packets you don't want,
if it stops doing it's just as a firewall, it's likely to keep on doing it's
other job: passing packets.  It certainly depends on the fundamental design
of the firewall, which I can't speak to generally... but you proponents of
"NAT contributes no security" can't, either.

> That makes sense, but I'm wondering if that should be considered correct
> behavior. Obviously a non-consumer grade router can have rules defining
> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
> everything coming from the outside in to either a) match up with
> something in the translation table, b) be a service the router itself is hosting
> (http, etc), or c) be a port it explicitly forwards to the same inside
> host.

> Anything not matching one of those 3 categories you'd think could be
> dropped. Routing without translating ports and addresses seems like
> the root of the issue.

It is.  And IME, the people who think NAT provides no security rarely if
ever seem to address that aspect of the issue. 

And, for what it's worth, I'm discussing the common case: 1-to-many incoming
DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on
other ports.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From Valdis.Kletnieks at vt.edu  Mon Nov 14 15:10:32 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 14 Nov 2011 16:10:32 -0500
Subject: Ok;
 let's have the "Does DNAT contribute to Security" argument one more
 time...
In-Reply-To: Your message of "Mon, 14 Nov 2011 15:55:14 EST."
 <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
Message-ID: <141376.1321305032@turing-police.cc.vt.edu>

On Mon, 14 Nov 2011 15:55:14 EST, Jay Ashworth said:

> On the other hand, since a firewall's job is to stop packets you don't want,

One of Marcus Ranum's "5 Stupidest Security Blunders" - "enumerating badness".
A firewall's job isn't to stop unwanted packets, it's to pass only wanted packets.

> if it stops doing it's just as a firewall, it's likely to keep on doing it's
> other job: passing packets.

As a result, a firewall that fails open rather than closed is mis-designed.

And if you're deploying a firewall and don't know if the failure mode is open or
closed, you probably get what you deserve when it fails.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111114/f2664b3b/attachment.bin>

From rubensk at gmail.com  Mon Nov 14 15:21:29 2011
From: rubensk at gmail.com (Rubens Kuhl)
Date: Mon, 14 Nov 2011 19:21:29 -0200
Subject: Ok; let's have the "Does DNAT contribute to Security" argument
 one more time...
In-Reply-To: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
References: <29935980.2769.1321304092428.JavaMail.root@benjamin.baylink.com>
 <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAGFn2k0tLEQAH_MLTZs=2TU0reMmaDL79k1Vp2+-Vn_m7A8AnQ@mail.gmail.com>

For the common good it doesn't matter if the "NAT is good" guys are
right or the "NAT is useless" guys are right, as they both fail to
decrease the numbers of their opposing parts. We must get IPv6 done
for both of them.

It seems that application reverse-proxies can make "NAT is good" guys
happy, so let's get it or some other solution on the market (both
commercial and open-source) and move on with what really matters,
getting v6 done.


Rubens


On Mon, Nov 14, 2011 at 6:55 PM, Jay Ashworth <jra at baylink.com> wrote:
> Kill this subject if you're sick of it.
>
> ----- Original Message -----
>> From: "Gabriel McCall" <Gabriel.McCall at thyssenkrupp.com>
>
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?If your firewall is working
>> properly, then having public addresses behind it is no less secure
>> than private. And if your firewall is not working properly, then
>> having private addresses behind it is no more secure than public.
>
> This assertion is frequently made -- it was made a couple other times
> this morning -- but I continue to think that it doesn't hold much water,
> primarly because it doesn't take into account *the probability of various
> potential failure modes in a firewall*.
>
> The basic assertion made by proponents of this theory, when analyzed,
> amounts to "the probability that a firewall between a publicly routable
> internal network and the internet will fail in such a fashion as to pass
> packets addressed to internal machines is of the same close order as the
> probability that a DNAT router will fail in such a fashion as to allow
> people outside it to address packets to *arbitrary* internal machine IP
> addresses (assuming they have any way to determine what those are)."
>
> Hopefully, my rephrasing makes it clearer why those of us who believe that
> there is, in fact, *some* extra security contributed by RFC 1918 and DNAT
> in the over all stack tend not to buy the arguments of those who say that
> in fact, it contributes none: they never show their work, so we cannot
> evaluate their assertions.
>
> But in fact, as someone pointed out this morning in the original thread:
> even if you happen to *know* the internal 1918 IP of the NATted target,
> the default failure mode of the NAT box is "stop forwarding packets into
> private network at all".
>
> Certainly, individual NAT boxes can have other failure modes, but each of
> those extra layers adds at least another 0 to the probability p-number,
> in my not-a-mathematician estimation.
>
> On the other hand, since a firewall's job is to stop packets you don't want,
> if it stops doing it's just as a firewall, it's likely to keep on doing it's
> other job: passing packets. ?It certainly depends on the fundamental design
> of the firewall, which I can't speak to generally... but you proponents of
> "NAT contributes no security" can't, either.
>
>> That makes sense, but I'm wondering if that should be considered correct
>> behavior. Obviously a non-consumer grade router can have rules defining
>> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
>> everything coming from the outside in to either a) match up with
>> something in the translation table, b) be a service the router itself is hosting
>> (http, etc), or c) be a port it explicitly forwards to the same inside
>> host.
>
>> Anything not matching one of those 3 categories you'd think could be
>> dropped. Routing without translating ports and addresses seems like
>> the root of the issue.
>
> It is. ?And IME, the people who think NAT provides no security rarely if
> ever seem to address that aspect of the issue.
>
> And, for what it's worth, I'm discussing the common case: 1-to-many incoming
> DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on
> other ports.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth ? ? ? ? ? ? ? ? ?Baylink ? ? ? ? ? ? ? ? ? ? ? jra at baylink.com
> Designer ? ? ? ? ? ? ? ? ? ? The Things I Think ? ? ? ? ? ? ? ? ? ? ? RFC 2100
> Ashworth & Associates ? ? http://baylink.pitas.com ? ? ? ? 2000 Land Rover DII
> St Petersburg FL USA ? ? ?http://photo.imageinc.us ? ? ? ? ? ? +1 727 647 1274
>
>


From bhmccie at gmail.com  Mon Nov 14 15:43:26 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Mon, 14 Nov 2011 15:43:26 -0600
Subject: Ok; let's have the "Does DNAT contribute to Security" argument
 one more time...
In-Reply-To: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
Message-ID: <4EC18B7E.8080607@gmail.com>

There really is no winner or "right way" on this thread. In IPv4 as a 
security guy we have often implemented NAT as an extra layer of 
obfuscation. In IPv6, that option really isn't there. So it's a cultural 
change for me. I'm not shedding any tears. We've talked to our FW 
vendors about various 6to6 and 4to6/6to4 options and we may consider it 
but given the push in the IPv6 community for native addressing I really 
am hesitant to add NAT functionality given that no one really knows what 
the IPv6 future holds.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/14/2011 02:55 PM, Jay Ashworth wrote:
> Kill this subject if you're sick of it.
>
> ----- Original Message -----
>    
>> From: "Gabriel McCall"<Gabriel.McCall at thyssenkrupp.com>
>>      
>    
>>                                         If your firewall is working
>> properly, then having public addresses behind it is no less secure
>> than private. And if your firewall is not working properly, then
>> having private addresses behind it is no more secure than public.
>>      
> This assertion is frequently made -- it was made a couple other times
> this morning -- but I continue to think that it doesn't hold much water,
> primarly because it doesn't take into account *the probability of various
> potential failure modes in a firewall*.
>
> The basic assertion made by proponents of this theory, when analyzed,
> amounts to "the probability that a firewall between a publicly routable
> internal network and the internet will fail in such a fashion as to pass
> packets addressed to internal machines is of the same close order as the
> probability that a DNAT router will fail in such a fashion as to allow
> people outside it to address packets to *arbitrary* internal machine IP
> addresses (assuming they have any way to determine what those are)."
>
> Hopefully, my rephrasing makes it clearer why those of us who believe that
> there is, in fact, *some* extra security contributed by RFC 1918 and DNAT
> in the over all stack tend not to buy the arguments of those who say that
> in fact, it contributes none: they never show their work, so we cannot
> evaluate their assertions.
>
> But in fact, as someone pointed out this morning in the original thread:
> even if you happen to *know* the internal 1918 IP of the NATted target,
> the default failure mode of the NAT box is "stop forwarding packets into
> private network at all".
>
> Certainly, individual NAT boxes can have other failure modes, but each of
> those extra layers adds at least another 0 to the probability p-number,
> in my not-a-mathematician estimation.
>
> On the other hand, since a firewall's job is to stop packets you don't want,
> if it stops doing it's just as a firewall, it's likely to keep on doing it's
> other job: passing packets.  It certainly depends on the fundamental design
> of the firewall, which I can't speak to generally... but you proponents of
> "NAT contributes no security" can't, either.
>
>    
>> That makes sense, but I'm wondering if that should be considered correct
>> behavior. Obviously a non-consumer grade router can have rules defining
>> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
>> everything coming from the outside in to either a) match up with
>> something in the translation table, b) be a service the router itself is hosting
>> (http, etc), or c) be a port it explicitly forwards to the same inside
>> host.
>>      
>    
>> Anything not matching one of those 3 categories you'd think could be
>> dropped. Routing without translating ports and addresses seems like
>> the root of the issue.
>>      
> It is.  And IME, the people who think NAT provides no security rarely if
> ever seem to address that aspect of the issue.
>
> And, for what it's worth, I'm discussing the common case: 1-to-many incoming
> DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on
> other ports.
>
> Cheers,
> -- jra
>    

From jra at baylink.com  Mon Nov 14 15:53:16 2011
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 14 Nov 2011 16:53:16 -0500 (EST)
Subject: Ok; let's have the "Does DNAT contribute to Security" argument
 one more time...
In-Reply-To: <141376.1321305032@turing-police.cc.vt.edu>
Message-ID: <31204866.2781.1321307596881.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Valdis Kletnieks" <Valdis.Kletnieks at vt.edu>

> > On the other hand, since a firewall's job is to stop packets you
> > don't want,
> 
> One of Marcus Ranum's "5 Stupidest Security Blunders" - "enumerating
> badness".
> A firewall's job isn't to stop unwanted packets, it's to pass only
> wanted packets.

>From 30,000ft those are equivalent. 

When you get down below 5000ft, it starts to matter which approach you
take to it.

There are lots and lots of people, though, whose exposure to firewalls is
"a set of rules you drop over a router" -- in consequence of which there are
a lot of *firewalls* that are designed that way.

You're correct in implying that that's strategically bad, but both components
of that paragraph impact the issue.

> > if it stops doing it's just as a firewall, it's likely to keep on
> > doing it's other job: passing packets.
> 
> As a result, a firewall that fails open rather than closed is
> mis-designed.
> 
> And if you're deploying a firewall and don't know if the failure mode
> is open or closed, you probably get what you deserve when it fails.

Can't argue with that at all.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From m.hallgren at free.fr  Mon Nov 14 15:54:47 2011
From: m.hallgren at free.fr (Michael Hallgren)
Date: Mon, 14 Nov 2011 22:54:47 +0100
Subject: Ok; let's have the "Does DNAT contribute to Security" argument
 one more time...
In-Reply-To: <4EC18B7E.8080607@gmail.com>
References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
 <4EC18B7E.8080607@gmail.com>
Message-ID: <1321307687.2817.8.camel@home>

Le lundi 14 novembre 2011 ? 15:43 -0600, -Hammer- a ?crit :
> There really is no winner or "right way" on this thread. In IPv4 as a 
> security guy we have often implemented NAT as an extra layer of 
> obfuscation. In IPv6, that option really isn't there. So it's a cultural 
> change for me. I'm not shedding any tears. We've talked to our FW 
> vendors about various 6to6 and 4to6/6to4 options and we may consider it 
> but given the push in the IPv6 community for native addressing I really 
> am hesitant to add NAT functionality given that no one really knows what 
> the IPv6 future holds.

I consider that a good way of looking a things. ;)

Cheers,
mh

> 
> -Hammer-
> 
> "I was a normal American nerd"
> -Jack Herer
> 
> 
> 
> On 11/14/2011 02:55 PM, Jay Ashworth wrote:
> > Kill this subject if you're sick of it.
> >
> > ----- Original Message -----
> >    
> >> From: "Gabriel McCall"<Gabriel.McCall at thyssenkrupp.com>
> >>      
> >    
> >>                                         If your firewall is working
> >> properly, then having public addresses behind it is no less secure
> >> than private. And if your firewall is not working properly, then
> >> having private addresses behind it is no more secure than public.
> >>      
> > This assertion is frequently made -- it was made a couple other times
> > this morning -- but I continue to think that it doesn't hold much water,
> > primarly because it doesn't take into account *the probability of various
> > potential failure modes in a firewall*.
> >
> > The basic assertion made by proponents of this theory, when analyzed,
> > amounts to "the probability that a firewall between a publicly routable
> > internal network and the internet will fail in such a fashion as to pass
> > packets addressed to internal machines is of the same close order as the
> > probability that a DNAT router will fail in such a fashion as to allow
> > people outside it to address packets to *arbitrary* internal machine IP
> > addresses (assuming they have any way to determine what those are)."
> >
> > Hopefully, my rephrasing makes it clearer why those of us who believe that
> > there is, in fact, *some* extra security contributed by RFC 1918 and DNAT
> > in the over all stack tend not to buy the arguments of those who say that
> > in fact, it contributes none: they never show their work, so we cannot
> > evaluate their assertions.
> >
> > But in fact, as someone pointed out this morning in the original thread:
> > even if you happen to *know* the internal 1918 IP of the NATted target,
> > the default failure mode of the NAT box is "stop forwarding packets into
> > private network at all".
> >
> > Certainly, individual NAT boxes can have other failure modes, but each of
> > those extra layers adds at least another 0 to the probability p-number,
> > in my not-a-mathematician estimation.
> >
> > On the other hand, since a firewall's job is to stop packets you don't want,
> > if it stops doing it's just as a firewall, it's likely to keep on doing it's
> > other job: passing packets.  It certainly depends on the fundamental design
> > of the firewall, which I can't speak to generally... but you proponents of
> > "NAT contributes no security" can't, either.
> >
> >    
> >> That makes sense, but I'm wondering if that should be considered correct
> >> behavior. Obviously a non-consumer grade router can have rules defining
> >> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
> >> everything coming from the outside in to either a) match up with
> >> something in the translation table, b) be a service the router itself is hosting
> >> (http, etc), or c) be a port it explicitly forwards to the same inside
> >> host.
> >>      
> >    
> >> Anything not matching one of those 3 categories you'd think could be
> >> dropped. Routing without translating ports and addresses seems like
> >> the root of the issue.
> >>      
> > It is.  And IME, the people who think NAT provides no security rarely if
> > ever seem to address that aspect of the issue.
> >
> > And, for what it's worth, I'm discussing the common case: 1-to-many incoming
> > DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on
> > other ports.
> >
> > Cheers,
> > -- jra
> >    




From marka at isc.org  Mon Nov 14 16:04:08 2011
From: marka at isc.org (Mark Andrews)
Date: Tue, 15 Nov 2011 09:04:08 +1100
Subject: Ok;
 let's have the "Does DNAT contribute to Security" argument one more
 time...
In-Reply-To: Your message of "Mon, 14 Nov 2011 15:43:26 MDT."
 <4EC18B7E.8080607@gmail.com>
References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
 <4EC18B7E.8080607@gmail.com>
Message-ID: <20111114220408.0AAC7171AAD9@drugs.dv.isc.org>


Firewalls and NATs are "warm fuzzy feeling" devices.  The best way
to keep secure is to run up to date software and to only provide
services you need.

Firewalls and NAT both inhibit inventions.  Both really do very little
with modern operating systems that have been designed to be connected
without a firewall in front of them to the Internet.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From gaileywg at MANSFIELDCT.ORG  Mon Nov 14 16:07:17 2011
From: gaileywg at MANSFIELDCT.ORG (Sam (Walter) Gailey)
Date: Mon, 14 Nov 2011 22:07:17 +0000
Subject: Cable standards question
In-Reply-To: <9A40A794-56FE-4773-B6A8-7BAD9EDF77FE@humancapitaldev.com>
References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net>
 <9A40A794-56FE-4773-B6A8-7BAD9EDF77FE@humancapitaldev.com>
Message-ID: <64BA4A04F13A7A43B289BAE7F07961F50AC94EB3@TN-Mail-1.mansfieldct.net>

First off, thanks to everyone who has replied, both on and off list, I've gotten some very good information on this, raising things I hadn't considered, particularly involving testing and warranties.

Daniel Seagraves wrote:
<Is it appropriate to just say "When installing fiber-optic cable the vendor will ensure the resulting installation does not suck."?>

Getting an installation that doesn't suck is indeed the core of the matter. However, "doesn't suck" is a rather vague concept as a point of law in case you have to sue your vendor for having installed something that sucks. That's why I was looking for a set of standards that I can point to and say (as an example)  "your installation sucks, and it sucks because you didn't follow X standard, and ran unshielded fiber at a 90 degree angle over a knife edge."

< Maybe there should be a legal definition of the concept of suck, so that suckage could be contractually minimized.>

Unfortunately vendors install suckage all the time. Our own particular horror story was one of our schools where half the school was experiencing intermittent issues of crosstalk, lag, unexplained packet loss, etc. Some days it was fine, others it wasn't and it took us some time to find out that the cabling vendor had connected the two network closets via plain old cat 5 cable, a run that was considerably longer than 300 feet. You wouldn't normally expect to have to specify to telecommunications vendors that you don't exceed the maximum cable length, but there it was. We replaced that link with multimode, and the problems immediately vanished. I'm sure others have similar stories. 

A number of people have asked for more details on the project and I deliberately didn't put those in because I was looking more for a standard that, if followed, produces acceptable link no matter what the project details are. For the curious, it's a simple point-to-point link involving an existing building and new construction that are about a mile apart . It will be singlemode, we will provide the racks on both ends, and we're specifying SC terminations. Whether we own or lease the fiber, lit or dark, depends on the economics of the quotes that come back to us. It's not a complicated project, but I shouldn't have to re-write a cabling spec as part of the RFP just to keep the vendors honest. A number of good references have been sent to me so I think I'm all set. Thanks, NANOG! :)

---Sam 



-----Original Message-----
From: Daniel Seagraves [mailto:dseagrav at humancapitaldev.com] 
Sent: Monday, November 14, 2011 9:58 AM
To: nanog at nanog.org
Subject: Re: Cable standards question


On Nov 14, 2011, at 8:42 AM, Sam (Walter) Gailey wrote:

> "The vendor will provide fiber connectivity between (building A) and (building B). Vendor will be responsible for all building penetrations and terminations. When  installing the fiber-optic cable the vendor will follow the appropriate TIA/EIA 568 standards for fiber-optic cabling."
> 
> Any suggestions or examples of language would be very appreciated. Offlist contact is probably best.

Is it appropriate to just say "When installing fiber-optic cable the vendor will ensure the resulting installation does not suck."?
That would seem to me to be the most direct solution to the problem. I mean, standards are all well and good, but what if the standard sucks?
Then you'd be up a creek.

Maybe there should be a legal definition of the concept of suck, so that suckage could be contractually minimized.




From lyndon at orthanc.ca  Mon Nov 14 17:01:30 2011
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Mon, 14 Nov 2011 15:01:30 -0800 (PST)
Subject: Ok; let's have the "Does DNAT contribute to Security" argument
 one more time...
In-Reply-To: <4EC18B7E.8080607@gmail.com>
References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
 <4EC18B7E.8080607@gmail.com>
Message-ID: <alpine.OSX.1.10.1111141447170.8578@rastawifi.orthanc.ca>

> There really is no winner or "right way" on this thread. In IPv4 as a 
> security guy we have often implemented NAT as an extra layer of obfuscation.

It's worse than just obfuscation.  The 'security' side effect of NAT can 
typically be implemented by four or five rules in a traditional firewall.

But a NAT implementation adds thousands of lines of code to the path the 
packets take, and any time you introduce complexity you decrease the 
overall security of the system.  And the complexity extends beyond the NAT 
box.  Hacking on IPsec, SIP, and lord knows what else to work around 
address rewriting adds even more opportunities for something to screw up.

If you want security, you have to DEcrease the number of lines of code in 
the switching path, not add to it.

Complexity is evil.  It's a shame this is no longer taught in computing 
courses. And I mean taught as a philosophy, not as a function of line 
count or any other bean-counter metrics.

--lyndon


From tvhawaii at shaka.com  Mon Nov 14 18:05:42 2011
From: tvhawaii at shaka.com (Michael Painter)
Date: Mon, 14 Nov 2011 14:05:42 -1000
Subject: Ok;
 let's have the "Does DNAT contribute to Security" argument one more
 time...
References: <31204866.2781.1321307596881.JavaMail.root@benjamin.baylink.com>
Message-ID: <3F3E6DC1F01848F9BCB6C9CC2F6CDD71@owner59e1f1502>

Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Valdis Kletnieks" <Valdis.Kletnieks at vt.edu>
> 
>>> On the other hand, since a firewall's job is to stop packets you
>>> don't want,
>> 
>> One of Marcus Ranum's "5 Stupidest Security Blunders" - "enumerating
>> badness".
>> A firewall's job isn't to stop unwanted packets, it's to pass only
>> wanted packets.
> 
> From 30,000ft those are equivalent.


Speaking of 30,000 ft., saw this on Dave Farber's IP list:

https://plus.google.com/u/0/110897184785831382163/posts/5qsNxFEaiML


From bill at herrin.us  Mon Nov 14 18:06:13 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 14 Nov 2011 19:06:13 -0500
Subject: Ok; let's have the "Does DNAT contribute to Security" argument
 one more time...
In-Reply-To: <alpine.OSX.1.10.1111141447170.8578@rastawifi.orthanc.ca>
References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
 <4EC18B7E.8080607@gmail.com>
 <alpine.OSX.1.10.1111141447170.8578@rastawifi.orthanc.ca>
Message-ID: <CAP-guGX__gLuAcH=CniRf21OaApSmq7xKWRYzKwxJg9ChKZoig@mail.gmail.com>

On Mon, Nov 14, 2011 at 6:01 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> But a NAT implementation adds thousands of lines of code to the path the
> packets take, and any time you introduce complexity you decrease the overall
> security of the system. ?And the complexity extends beyond the NAT box.
> ?Hacking on IPsec, SIP, and lord knows what else to work around address
> rewriting adds even more opportunities for something to screw up.
>
> If you want security, you have to DEcrease the number of lines of code in
> the switching path, not add to it.

Hi Lyndon,

Counterpoint:

Using two firewalls in serial from two different vendors doubles the
complexity. Yet it almost always improves security: fat fingers on one
firewall rarely repeat the same way on the second and a rogue packet
must pass both.

The same two firewalls in parallel surely reduces security.


Is complexity the enemy of security? In general principle yes, but as
with many things IT DEPENDS.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From mcdonald.richards at gmail.com  Mon Nov 14 18:09:30 2011
From: mcdonald.richards at gmail.com (McDonald Richards)
Date: Tue, 15 Nov 2011 11:09:30 +1100
Subject: packet loss out of Texas on Cogent and GlobalCrossing
In-Reply-To: <CAJT7WrjP0g_7h-zOssL32zhypT05dtm2HJa4g0n+0nNZqnQdbA@mail.gmail.com>
References: <CAJT7Wriwt_2aV3+MCBuEsW4hYLuF=NL34RT3XX3mY4Q4nMTT0g@mail.gmail.com>
 <03af01cca302$dae14440$90a3ccc0$@truenet.com>
 <CAJT7WrjP0g_7h-zOssL32zhypT05dtm2HJa4g0n+0nNZqnQdbA@mail.gmail.com>
Message-ID: <CACrsH-6DWPGqwKrjz1FOvzFLPyU-ujM8S27QogpWyj4cY0St+Q@mail.gmail.com>

I take multiple services from Global Crossing in San Jose and have had
reports of packet loss from Cogent users in Chicago and London (and been
able to reproduce).

In all cases it appears to be after wherever Cogents' "mci01" location is.

 10.|-- te0-3-0-3.mpd21.mci01.atl  0.0%   100  205.7 205.2 204.5 207.7   0.7

 11.|-- te0-5-0-4.mpd21.ord01.atl  7.0%   100  238.4 235.6 230.4 239.1   2.0

 12.|-- te0-0-0-5.ccr21.bos01.atl  4.0%   100  315.1 315.0 314.6 316.7   0.3

 13.|-- te0-0-0-2.mpd21.lon13.atl 10.0%   100  323.7 323.7 321.6 325.7   0.7

 14.|-- te2-1.ccr01.lon01.atlas.c  6.0%   100  324.6 332.8 314.9 523.0  38.5

 15.|-- te1-2.mpd01.lon01.atlas.c  9.0%   100  326.3 339.3 324.9 506.0  39.5


10.|-- te0-4-0-3.mpd21.mci01.atl  0.0%   100  206.1 208.9 204.6 225.8   5.3

 11.|-- te0-4-0-3.mpd21.ord01.atl  3.0%   100  239.2 237.0 228.7 239.5   1.9

 12.|-- te0-0-0-1.ccr21.ord03.atl  4.0%   100  239.1 237.4 228.3 240.9   2.0

 13.|-- te2-1.mpd02.ord03.atlas.c  4.0%   100  228.0 235.2 227.0 350.2  23.9


McDonald


On Tue, Nov 15, 2011 at 7:52 AM, Charles Gagnon <charlesg at unixrealm.com>wrote:

> Good point, I can't seem to reproduce with the looking glass
> interfaces out there. They either don't use enough packets in sequence
> or don't through the problem hops. On this path:
>
> Send ICMP echos to 24.227.216.194, timeout is 2 seconds,  maximum hops
> are 32,1       0ms     1ms     0ms     74.201.153.2212       143ms
> 10ms    0ms     216.52.95.893       1ms     1ms     1ms
> 77.67.70.974       1ms     1ms     1ms     213.200.66.2105       3ms
>   1ms     2ms     66.198.111.976       19ms    7ms     7ms
> 216.6.87.97       7ms     7ms     7ms     216.6.87.28       6ms
> 7ms     7ms     66.198.154.149       6ms     7ms     6ms
> 107.14.19.13210      107ms   108ms   113ms   66.109.10.1111      118ms
>   144ms   120ms   107.14.17.13912      119ms   120ms   120ms
> 72.179.205.5913      115ms   115ms   114ms   24.73.240.19514
> 115ms   115ms   115ms   24.73.240.252
> I re-tested and using 100 msg counts, I get 3-6% packet loss on
> anything after 10. On hops 1-10, I'm all clean. That 66.109.10.11
> address is inside TimeWarner/RR so I'll keep trying to contact them.
>
>
> On Mon, Nov 14, 2011 at 2:23 PM, Eric Tykwinski <eric-list at truenet.com>
> wrote:
> > Have you check the relevant looking glass sites?
> >
> > http://www.cogentco.com/en/network/looking-glass
> > http://www.globalcrossing.com/network/network_looking_glass.aspx
> >
> > We are connected to both providers, so everything is looking clean for
> us.
> >
> > Sincerely,
> >
> > Eric Tykwinski
> > TrueNet, Inc.
> > P: 610-429-8300
> > F: 610-429-3222
> >
> > -----Original Message-----
> > From: Charles Gagnon [mailto:charlesg at unixrealm.com]
> > Sent: Monday, November 14, 2011 2:11 PM
> > To: nanog at nanog.org
> > Subject: packet loss out of Texas on Cogent and GlobalCrossing
> >
> > I need the Nanog intellect,
> >
> > We are seeing packet loss in certain scenarios only on traffic to and
> from
> > Austin, TX. The local provider is Time Warner and they are not having
> > (obvious) problems. We ran tests from NY and NJ over Internap and
> AboveNet
> > connections.We only see problems when the traffic goes over gblx or
> cogent.
> > Has anyone heard of problem with these carriers out of Texas?
> > --
> > Charles Gagnon
> > charlesg at unixrealm.com
> >
> >
> >
>
>
>
> --
> Charles Gagnon
> charlesg at unixrealm.com
>
>

From jeff-kell at utc.edu  Mon Nov 14 18:12:54 2011
From: jeff-kell at utc.edu (Jeff Kell)
Date: Mon, 14 Nov 2011 19:12:54 -0500
Subject: Ok; let's have the "Does DNAT contribute to Security" argument
 one more time...
In-Reply-To: <CAGFn2k0tLEQAH_MLTZs=2TU0reMmaDL79k1Vp2+-Vn_m7A8AnQ@mail.gmail.com>
References: <29935980.2769.1321304092428.JavaMail.root@benjamin.baylink.com>
 <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
 <CAGFn2k0tLEQAH_MLTZs=2TU0reMmaDL79k1Vp2+-Vn_m7A8AnQ@mail.gmail.com>
Message-ID: <4EC1AE86.8060700@utc.edu>

On 11/14/2011 4:21 PM, Rubens Kuhl wrote:
> For the common good it doesn't matter if the "NAT is good" guys are
> right or the "NAT is useless" guys are right, as they both fail to
> decrease the numbers of their opposing parts. We must get IPv6 done
> for both of them.

Hehehe...  depending on your ISPs / transit providers / border
technology level, putting critical infrastructure on IPv6[only] might be
the safest most unreachable network of all :)

Jeff


From jeroen at mompl.net  Mon Nov 14 18:35:30 2011
From: jeroen at mompl.net (Jeroen van Aart)
Date: Mon, 14 Nov 2011 16:35:30 -0800
Subject: Arguing against using public IP space
In-Reply-To: <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
Message-ID: <4EC1B3D2.5060007@mompl.net>

William Herrin wrote:
> If your machine is addressed with a globally routable IP, a trivial
> failure of your security apparatus leaves your machine addressable
> from any other host in the entire world which wishes to send it

Isn't that the case with IPv6? That the IP is addressable from any host 
in the entire (IPv6) world? And isn't that considered a good thing?

I don't think that being addressable from anywhere is a security hole in 
and of itself. It's how you implement and (mis)configure your firewall 
and related things that is the (potential) security hole. Whether the IP 
is world addressable or not

> with all your stuff. Yet when you forget to throw the deadbolt, it
> does stop an intruder from simply turning the knob and wandering in.

Personally I prefer car analogies when it comes to explaining (complex) 
computer matters. ;-)

Greetings,
Jeroen

-- 
Earthquake Magnitude: 5.2
Date: Monday, November 14, 2011 22:08:15 UTC
Location: eastern Turkey
Latitude: 38.6644; Longitude: 43.0993
Depth: 10.00 km


From jon at smugmug.com  Mon Nov 14 19:06:59 2011
From: jon at smugmug.com (Jon Heise)
Date: Mon, 14 Nov 2011 17:06:59 -0800
Subject: equinix sv3 provider recommendations
Message-ID: <CAGaZ0PxnkFwzR5yxRzQCXtHZ-0THpRyf3r5-r+ARjfQx60M0Ww@mail.gmail.com>

I'm setting up internet connectivity in the equinix SV3 datacenter, we are
already a level3 customer what other providers have been reliable from sv3.

From smb at cs.columbia.edu  Mon Nov 14 19:15:22 2011
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Mon, 14 Nov 2011 20:15:22 -0500
Subject: airgap / negligent homicide charge
In-Reply-To: <CAE5c7NJUUf1AcKqrD6zxef1LL+HU8xeCZLG5k8y8aW1obUXdow@mail.gmail.com>
References: <CAE5c7NJUUf1AcKqrD6zxef1LL+HU8xeCZLG5k8y8aW1obUXdow@mail.gmail.com>
Message-ID: <3EFCE3CB-1D61-463E-8C3E-32425D1ECA29@cs.columbia.edu>

Here's a quote from a famous court case (T.J. Hooper) on liability and industry
standards:

    Indeed in most cases reasonable prudence is in face common prudence; but
    strictly it is never its measure; a whole calling may have unduly lagged
    in the adoption of new and available devices.  It may never set its own
    tests, however persuasive be its usages.  Courts must in the end say what
    is required; there are precautions so imperative that even their universal
    disregard will not excuse their omission. 

And here's a quote from a legal textbook:

    The standard of conduct imposed by the law is an external
    one, based upon what society demands generally of its
    members, rather than upon the actors personal morality or
    individual sense of right and wrong.  A failure to conform
    to the standard is negligence, therefore, even if it is due
    to clumsiness, stupidity, forgetfulness, an excitable
    temperament, or even sheer ignorance.  An honest blunder,
    or a mistaken belief that no damage will result, may absolve
    the actor from moral blame, but the harm to others is still
    as great, and the actors individual standards must give way
    in this area of the law to those of the public.  In other
    words, society may require of a person not to be awkward
    or a fool.

In other words, get real legal advice on the standard of care you should
observe.


On Nov 14, 2011, at 10:25 AM, Mickey Fox wrote:

> The determination of whether a failure rises to the level of negligent
> homicide will require a review of industry standards, company standards and
> sometimes straight common-sence.
> 
> If the industry standard is airgap re security you are probably okay so
> long as you review and address the very concerns and questions you are
> raising in a responsible fashion that does not rely solely on expediency,
> cost, etc., but looks to real-world scenarios and emergency / backup
> procedures, equipment, testing and training.
> 
> Mickey Fox
> CMK Consulting Services
> On Nov 14, 2011 9:00 AM, <nanog-request at nanog.org> wrote:
> 
>> Send NANOG mailing list submissions to
>>       nanog at nanog.org
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>       https://mailman.nanog.org/mailman/listinfo/nanog
>> or, via email, send a message with subject or body 'help' to
>>       nanog-request at nanog.org
>> 
>> You can reach the person managing the list at
>>       nanog-owner at nanog.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of NANOG digest..."
>> 
>> 
>> Today's Topics:
>> 
>>  1. Re: Arguing against using public IP space
>>     (Valdis.Kletnieks at vt.edu)
>>  2. Re: Arguing against using public IP space (Joel jaeggli)
>>  3. Re: Arguing against using public IP space (Jimmy Hess)
>>  4. Re: Arguing against using public IP space (Owen DeLong)
>>  5. Re: Arguing against using public IP space (Dobbins, Roland)
>>  6. Cable standards question (Sam (Walter) Gailey)
>>  7. Re: Cable standards question (Daniel Seagraves)
>>  8. Re: Arguing against using public IP space (Joe Greco)
>>  9. Re: Arguing against using public IP space (Ray Soucy)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Sun, 13 Nov 2011 21:43:32 -0500
>> From: Valdis.Kletnieks at vt.edu
>> To: Brett Frankenberger <rbf+nanog at panix.com>
>> Cc: NANOG <nanog at nanog.org>
>> Subject: Re: Arguing against using public IP space
>> Message-ID: <81357.1321238612 at turing-police.cc.vt.edu>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> On Sun, 13 Nov 2011 19:14:59 CST, Brett Frankenberger said:
>> 
>>> What if you air-gap the SCADA network of which you are in
>>> administrative control, and then there's a failure on it, and the people
>>> responsible for troubleshooting it can't do it remotely (because of the
>>> air gap), so the trouble continues for an extra hour while they drive
>>> to the office, and that extra hour of failure causes someone to die.
>>> Should that result in a homicide charge?
>> 
>> If you designed a life-critical airgapped network that didn't have a
>> trained
>> warm body at the NOC 24/7 with an airgapped management console, and hot
>> (or at
>> least warm) spares for both console and console monkey, yes, you *do*
>> deserve
>> that negligent homicide charge.
>> 
>> 
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: not available
>> Type: application/pgp-signature
>> Size: 227 bytes
>> Desc: not available
>> URL: <
>> http://mailman.nanog.org/pipermail/nanog/attachments/20111113/247b47fe/attachment-0001.bin
>>> 
>> 
>> ------------------------------
>> 
>> Message: 2
>> Date: Mon, 14 Nov 2011 10:59:45 +0800
>> From: Joel jaeggli <joelja at bogus.com>
>> To: Joe Greco <jgreco at ns.sol.net>
>> Cc: NANOG <nanog at nanog.org>
>> Subject: Re: Arguing against using public IP space
>> Message-ID: <4EC08421.80708 at bogus.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>> 
>> On 11/14/11 10:24 , Joe Greco wrote:
>>>> Sure, anytime there's an attack or failure on a SCADA network that
>>>> wouldn't have occurred had it been air-gapped, it's easy for people to
>>>> knee-jerk a "SCADA networks should be airgapped" response.  But that's
>>>> not really intelligent commentary unless you carefully consider what
>>>> risks are associated with air-gapping the network.
>>> 
>>> Not to mention that it's not the only way for these things to get
>>> infected.  Getting fixated on air-gapping is unrealistically ignoring
>>> the other threats out there.
>>> 
>>> There needs to be a whole lot more security work done on SCADA nets.
>> 
>> Stuxnet should provide a fairly illustrative example.
>> 
>> It doesn't really matter how well isolated from direct access it is if
>> it has a soft gooey center and a willing attacker.
>> 
>>> ... JG
>> 
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 3
>> Date: Sun, 13 Nov 2011 21:48:01 -0600
>> From: Jimmy Hess <mysidia at gmail.com>
>> To: David Walker <davidianwalker at gmail.com>
>> Cc: nanog at nanog.org
>> Subject: Re: Arguing against using public IP space
>> Message-ID:
>>       <CAAAwwbUSUzHO0q3vkBh3-sQHxnXc5=UE5w2R+MZ=Hmpa08wDhg at mail.gmail.com
>>> 
>> Content-Type: text/plain; charset=ISO-8859-1
>> 
>> On Sun, Nov 13, 2011 at 3:03 PM, David Walker <davidianwalker at gmail.com>
>> wrote:
>>> On 14/11/2011, Jimmy Hess <mysidia at gmail.com> wrote:
>>> A packet addressed to an endpoint that doesn't serve anything or have
>>> a client listening will be ignered (whatever) as a matter of course.
>>> Firewall or no firewall.
>> It will not go to a listening application,  neither will it be
>> completely ignored --
>> the receiving machine's  TCP stack will have a look at the packet.
>> On common operating systems there  are frequently unsafe applications
>> listening on ports;  on certain OSes, there will be no way to turn off
>> system applications,  or human error will leave them in place.
>> 
>>> That's fundamental to TCP/IP and secure.
>> It's fundamental to TCP/IP,  but not fundamentally secure.  TCP/IP
>> implementations have flaws.
>> If a host is meant solely as an endpoint, then it is exposed to undue
>> risk, if arbitrary packets can be addressed to its TCP/IP stack that
>> might have remotely exploitable bugs.
>> 
>>> The only reason we firewall (packet filter) is to provide access
>>> control (for whatever reason).
>> No, we also firewall to block access entirely to applications
>> attempting to establish a service on unapproved ports.    We also use
>> firewalls in certain forms to ensure that communications over a TCP/IP
>> socket comply with a protocol,  for example,  that a session
>> terminated on port 25 is actually a SMTP session.
>> 
>> The firewall might restrict the set of allowed SMTP commands, validate
>> the syntax of certain commands,  hide server version information,
>> prevent use of ESMTP pipelining from outside, etc.
>> 
>>> I apologize in advance if this is too pedestrian (you might know this
>>> but not agree with it) but I want to make a point:
>>> http://en.wikipedia.org/wiki/End-to-end_connectivity
>> 
>> End to end connectivity principal's purpose is not to provide
>> security.    It is to facilitate communications with other hosts and
>> networks.     When a private system _really_ has to be secure,  end to
>> end connectivity is inherently incompatible  with security objectives.
>> 
>> There is always a tradeoff involving sacrificing a level of security
>> against remote attack
>> when connecting a computer to a network,  and then again,  when
>> connecting the network to the internet.
>> 
>> A computer that is not connected to a network is perfectly secure
>> against network-based attacks.
>> A computer that is connected to LAN is at risk of potential
>> network-based attack from that LAN.
>> 
>> If that LAN is then connected through a firewall  through many to 1
>> NAT,  there is another layer of risk added.
>> 
>> If the NAT'ing firewall is then replaced with a simple many to 1 NAT
>> router,  there is another layer of risk added; there are new attacks
>> possible that still succeed in a NAT environment,  that the firewall
>> would have stopped.
>> 
>> Finally, if that that same computer is then given end to end
>> connectivity with no firewall,  there is a much   less encumbered
>> communications path available to that computer for launching
>> network-based attack;  the attack surface is greatly increased in such
>> a design.
>> 
>> If we are talking about nodes that interface with a SCADA network;
>> the concept of unfirewalled end-to-end connectivity approaches the
>> level of insanity.
>> 
>> Those are not systems where end-to-end public connectivity should be a
>> priority over security.
>> 
>> --
>> -JH
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 4
>> Date: Sun, 13 Nov 2011 19:51:24 -0800
>> From: Owen DeLong <owen at delong.com>
>> To: Jason Lewis <jlewis at packetnexus.com>
>> Cc: nanog at nanog.org
>> Subject: Re: Arguing against using public IP space
>> Message-ID: <2DE5DF4F-059C-4F39-81D4-363E49966282 at delong.com>
>> Content-Type: text/plain; charset=us-ascii
>> 
>> 
>> On Nov 13, 2011, at 7:36 AM, Jason Lewis wrote:
>> 
>>> I don't want to start a flame war, but this article seems flawed to
>>> me.  It seems an IP is an IP.
>>> 
>>> 
>> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>>> 
>>> I think I could announce private IP space, so doesn't that make this
>>> argument invalid?  I've always looked at private IP space as more of a
>>> resource and management choice and not a security feature.
>> 
>> Yes, the author of this article is sadly mistaken and woefully void
>> of clue on the issues he attempts to address.
>> 
>> You are completely correct.
>> 
>> Owen
>> 
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 5
>> Date: Mon, 14 Nov 2011 06:21:47 +0000
>> From: "Dobbins, Roland" <rdobbins at arbor.net>
>> To: NANOG Operators' Group <nanog at nanog.org>
>> Subject: Re: Arguing against using public IP space
>> Message-ID: <EF60C45B-4227-4EF9-BFAF-FB96473F8670 at arbor.net>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> On Nov 14, 2011, at 9:24 AM, Joe Greco wrote:
>> 
>>> Getting fixated on air-gapping is unrealistically ignoring the other
>> threats out there.
>> 
>> I don't think anyone in this thread is 'fixated' on the idea of
>> airgapping; but it's generally a good idea whenever possible, and as
>> restrictive a communications policy as is possible is definitely called
>> for, amongst all the other things one ought to be doing.
>> 
>> It's also important to note that it's often impossible to *completely*
>> airgap things, these days, due to various interdependencies, admin
>> requirements (mentioned before), and so forth; perhaps bastioning is a more
>> apt term.
>> 
>> -----------------------------------------------------------------------
>> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>> 
>>               The basis of optimism is sheer terror.
>> 
>>                         -- Oscar Wilde
>> 
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 6
>> Date: Mon, 14 Nov 2011 14:42:32 +0000
>> From: "Sam (Walter) Gailey" <gaileywg at MANSFIELDCT.ORG>
>> To: "nanog at nanog.org" <nanog at nanog.org>
>> Subject: Cable standards question
>> Message-ID:
>>       <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2 at TN-Mail-1.mansfieldct.net
>>> 
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> Hello, newbie question of the morning time, but hopefully not too
>> off-topic...
>> 
>> I run a small town network. A new building is being built that the town
>> wants fiber access to. I have to specify for vendors what it is that the
>> town expects in the cabling. I am (obviously) not a fiber expert, and I'm
>> having trouble phrasing the language of the RFP so that we are assured a
>> quality installation.
>> 
>> My question is this; Is there an appropriate standard to specify for
>> fiber-optic cabling that if it is followed the fiber will be installed
>> correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?
>> 
>> I'm envisioning something like;
>> 
>> "The vendor will provide fiber connectivity between (building A) and
>> (building B). Vendor will be responsible for all building penetrations and
>> terminations. When  installing the fiber-optic cable the vendor will follow
>> the appropriate TIA/EIA 568 standards for fiber-optic cabling."
>> 
>> Any suggestions or examples of language would be very appreciated. Offlist
>> contact is probably best.
>> 
>> Many thanks,
>> 
>> ---Sam
>> 
>> 
>> ------------------------------
>> 
>> Message: 7
>> Date: Mon, 14 Nov 2011 08:57:31 -0600
>> From: Daniel Seagraves <dseagrav at humancapitaldev.com>
>> To: nanog at nanog.org
>> Subject: Re: Cable standards question
>> Message-ID: <9A40A794-56FE-4773-B6A8-7BAD9EDF77FE at humancapitaldev.com>
>> Content-Type: text/plain; charset=us-ascii
>> 
>> 
>> On Nov 14, 2011, at 8:42 AM, Sam (Walter) Gailey wrote:
>> 
>>> "The vendor will provide fiber connectivity between (building A) and
>> (building B). Vendor will be responsible for all building penetrations and
>> terminations. When  installing the fiber-optic cable the vendor will follow
>> the appropriate TIA/EIA 568 standards for fiber-optic cabling."
>>> 
>>> Any suggestions or examples of language would be very appreciated.
>> Offlist contact is probably best.
>> 
>> Is it appropriate to just say "When installing fiber-optic cable the
>> vendor will ensure the resulting installation does not suck."?
>> That would seem to me to be the most direct solution to the problem. I
>> mean, standards are all well and good, but what if the standard sucks?
>> Then you'd be up a creek.
>> 
>> Maybe there should be a legal definition of the concept of suck, so that
>> suckage could be contractually minimized.
>> 
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 8
>> Date: Mon, 14 Nov 2011 08:58:37 -0600 (CST)
>> From: Joe Greco <jgreco at ns.sol.net>
>> To: joelja at bogus.com (Joel jaeggli)
>> Cc: NANOG <nanog at nanog.org>
>> Subject: Re: Arguing against using public IP space
>> Message-ID: <201111141458.pAEEwcS6072727 at aurora.sol.net>
>> Content-Type: text/plain; charset=us-ascii
>> 
>>> On 11/14/11 10:24 , Joe Greco wrote:
>>>>> Sure, anytime there's an attack or failure on a SCADA network that
>>>>> wouldn't have occurred had it been air-gapped, it's easy for people to
>>>>> knee-jerk a "SCADA networks should be airgapped" response.  But that's
>>>>> not really intelligent commentary unless you carefully consider what
>>>>> risks are associated with air-gapping the network.
>>>> 
>>>> Not to mention that it's not the only way for these things to get
>>>> infected.  Getting fixated on air-gapping is unrealistically ignoring
>>>> the other threats out there.
>>>> 
>>>> There needs to be a whole lot more security work done on SCADA nets.
>>> 
>>> Stuxnet should provide a fairly illustrative example.
>>> 
>>> It doesn't really matter how well isolated from direct access it is if
>>> it has a soft gooey center and a willing attacker.
>> 
>> That's basically the case for so many things.
>> 
>> I was reading, recently, two articles on Ars Technica ("Die, VPN" and
>> "Live, VPN") which made it exceedingly clear that these sorts of designs
>> are still the rule for most companies.  I mean, I already knew that, but
>> it was *depressing* to read.
>> 
>> We've been very successful for many years designing things as though they
>> were going to be deployed on the public Internet, even if we do still put
>> them behind a firewall.  That's just belt-and-suspenders common sense.
>> 
>> We do run a VPN service, which I use heavily, but it really has little
>> to do with granting magical access to resources - the VPN endpoint is
>> actually outside any firewall.  I've so frequently found, over the years,
>> that some "free" Internet connection offering is crippled in some stupid
>> manner (transparent proxying with ad injection!), that the value added
>> is mostly just that of getting an Internet connection with no interference
>> by third parties.  The fact that third parties cannot do any meaningful
>> snooping is nice too.
>> 
>> I also recall a fairly surreal discussion with a NANOG'er who was
>> absolutely convinced that SSH key based access to other servers was
>> more secure than password based access along with some ACL's and
>> something like sshguard; my point was that compromise of the magic
>> host with the magic key would tend to be worse (because you've suddenly
>> got access to all the other servers) while having different secure
>> passwords for each host, along with some ACL's and sshguard, allow you
>> to retain some isolation within the network from an infected node.  It's
>> dependent on design and forethought, of course...
>> 
>> Basically, getting access to some point in the network shouldn't really
>> allow you to go on a rampage through the rest of the network.
>> 
>> ... JG
>> --
>> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
>> "We call it the 'one bite at the apple' rule. Give me one chance [and]
>> then I
>> won't contact you again." - Direct Marketing Ass'n position on e-mail
>> spam(CNN)
>> With 24 million small businesses in the US alone, that's way too many
>> apples.
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 9
>> Date: Mon, 14 Nov 2011 10:00:36 -0500
>> From: Ray Soucy <rps at maine.edu>
>> To: Jason Lewis <jlewis at packetnexus.com>
>> Cc: nanog at nanog.org
>> Subject: Re: Arguing against using public IP space
>> Message-ID:
>>       <CALFTrnMGODeixe2g0eg_gTmZvkL_89LSFtdgW4E5SZ-Qq1Xjbw at mail.gmail.com
>>> 
>> Content-Type: text/plain; charset=ISO-8859-1
>> 
>> As far as I can see Red Tiger Security is Jonathan Pollet; and even
>> though they list Houston, Dubai, Milan, and Sydney as offices it looks
>> like Houston is the only one.? Is that right?? Seems a little
>> misleading.
>> 
>> It actually reminds me of a 16 year old kid I know who runs a web
>> hosting "company" that you'd think was a Fortune 500 by the way the
>> website reads, and he's more than happy to take your credit card
>> information and store it without being PCI compliant.
>> 
>> Credibility of the company aside,
>> 
>> At first I wanted to cut Jonathan some slack.? If he was going to
>> point to the use of public IPs as evidence that a firewall may not be
>> in use and then went on to discuss the potential risks of not having
>> any security, then that would have been appropriate.? But instead he
>> goes on about explaining what a public vs. private address is (poorly)
>> and proceeds to associate the security of the system with the use of
>> private IPs.
>> 
>> I just don't see him as credible in the security field after reading it.
>> 
>> Then again, he does have that interview on Fox News posted on his
>> website where he talks about terrorist plots to compromise the
>> integrity of nuclear power plants...
>> 
>> Honestly, people post stuff like this time and time again.  It's been
>> debunked so many times that a quick Google will probably give you what
>> you need to figure it out on your own.
>> 
>> On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis <jlewis at packetnexus.com>
>> wrote:
>>> I don't want to start a flame war, but this article seems flawed to
>>> me. ?It seems an IP is an IP.
>>> 
>>> 
>> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>>> 
>>> I think I could announce private IP space, so doesn't that make this
>>> argument invalid? ?I've always looked at private IP space as more of a
>>> resource and management choice and not a security feature.
>>> 
>>> 
>> 
>> 
>> 
>> --
>> Ray Soucy
>> 
>> Epic Communications Specialist
>> 
>> Phone: +1 (207) 561-3526
>> 
>> Networkmaine, a Unit of the University of Maine System
>> http://www.networkmaine.net/
>> 
>> 
>> 
>> End of NANOG Digest, Vol 46, Issue 43
>> *************************************
>> 
> 


		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From egon at egon.cc  Mon Nov 14 19:29:46 2011
From: egon at egon.cc (James Downs)
Date: Mon, 14 Nov 2011 17:29:46 -0800
Subject: airgap / negligent homicide charge
In-Reply-To: <3EFCE3CB-1D61-463E-8C3E-32425D1ECA29@cs.columbia.edu>
References: <CAE5c7NJUUf1AcKqrD6zxef1LL+HU8xeCZLG5k8y8aW1obUXdow@mail.gmail.com>
 <3EFCE3CB-1D61-463E-8C3E-32425D1ECA29@cs.columbia.edu>
Message-ID: <BCF156C3-AC06-4C09-9A7F-C039A6A73F01@egon.cc>


On Nov 14, 2011, at 5:15 PM, Steven Bellovin wrote:

> And here's a quote from a legal textbook:

>   in this area of the law to those of the public.  In other
>   words, society may require of a person not to be awkward

If only that were more generally true.

-j



From mysidia at gmail.com  Mon Nov 14 20:58:36 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 14 Nov 2011 20:58:36 -0600
Subject: Ok; let's have the "Does DNAT contribute to Security" argument
 one more time...
In-Reply-To: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
References: <29935980.2769.1321304092428.JavaMail.root@benjamin.baylink.com>
 <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAAAwwbW+KOq=gHbvJoikxs61U5Z-LsvNEf75aH4RQ0zx=6eYCA@mail.gmail.com>

On Mon, Nov 14, 2011 at 2:55 PM, Jay Ashworth <jra at baylink.com> wrote:

> The basic assertion made by proponents of this theory, when analyzed,
> amounts to "the probability that a firewall between a publicly routable
> internal network and the internet will fail in such a fashion as to pass
> packets addressed to internal machines is of the same close order as the
> probability that a DNAT router will fail in such a fashion as to allow
> people outside it to address packets to *arbitrary* internal machine IP
> addresses (assuming they have any way to determine what those are)."
[snip]

There is really no sound argument made that the probability is
inherently any different.
When we are referring to security devices failing to do what they are
supposed to do,
by definition,  the correct level of protection has been lost,  and
you have a serious
problem if this happens,  regardless of whether your firewall is a NAT
device or not.

What will be most important is you have solid layers of defense behind
the firewall,
such as host security,  IDS units,  monitoring, and scanning regimes
to detect the failure
of the firewall function.

The security appliance has failed, and all bets may be off.
It should be noted, that  "detecting"  a failed simple firewall with a
straight port scan
is a much simpler more easily automatable process than detecting a
failed 1:many
NAT firewall.

The ease of detecting the problem lowers the chance that you have a problem.


The potential security failure modes of a 1:many NAT firewall are much
more complicated
than "simply pass packets it's not supposed to pass";   the quirks of
the flaw mean that
with a NAT firewall, it is likely the failure of the firewall function
will go undetected by the
security admin,  resulting in a situation where you have an insidious problem...

that is, a problem that is not obvious,  but definitely exploitable to
a determined attacker.


Failure modes such as a "an intruder compromised the firewall"  and
injected a trojanned
firmware  result in equal risks regardless of whether NAT is implemented or not.


--
-JH


From Valdis.Kletnieks at vt.edu  Mon Nov 14 23:21:25 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 15 Nov 2011 00:21:25 -0500
Subject: Ok;
 let's have the "Does DNAT contribute to Security" argument one more
 time...
In-Reply-To: Your message of "Mon, 14 Nov 2011 19:06:13 EST."
 <CAP-guGX__gLuAcH=CniRf21OaApSmq7xKWRYzKwxJg9ChKZoig@mail.gmail.com>
References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
 <4EC18B7E.8080607@gmail.com>
 <alpine.OSX.1.10.1111141447170.8578@rastawifi.orthanc.ca>
 <CAP-guGX__gLuAcH=CniRf21OaApSmq7xKWRYzKwxJg9ChKZoig@mail.gmail.com>
Message-ID: <155340.1321334485@turing-police.cc.vt.edu>

On Mon, 14 Nov 2011 19:06:13 EST, William Herrin said:

> Using two firewalls in serial from two different vendors doubles the
> complexity. Yet it almost always improves security: fat fingers on one
> firewall rarely repeat the same way on the second and a rogue packet
> must pass both.

Fat fingers are actually not the biggest issue - a far bigger problem are brain
failures.  If you thought opening port 197 was a good idea, you will have done
it on both firewalls.  And it doesn't even help to run automated config
checkers - because you'll have marked port 197 as "good" in there as well. ;)

And it doesn't even help with fat-finger issues anyhow, because you *know* that
if your firewall admin is any good, they'll just write a script that loads both
firewalls from a master config file - and then proceed to fat-finger said
config file.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111115/9f2f1a57/attachment.bin>

From cb.list6 at gmail.com  Mon Nov 14 23:41:25 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Mon, 14 Nov 2011 21:41:25 -0800
Subject: Ok; let's have the "Does DNAT contribute to Security" argument
 one more time...
In-Reply-To: <155340.1321334485@turing-police.cc.vt.edu>
References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
 <4EC18B7E.8080607@gmail.com>
 <alpine.OSX.1.10.1111141447170.8578@rastawifi.orthanc.ca>
 <CAP-guGX__gLuAcH=CniRf21OaApSmq7xKWRYzKwxJg9ChKZoig@mail.gmail.com>
 <155340.1321334485@turing-police.cc.vt.edu>
Message-ID: <CAD6AjGS+DB3QzvYjx+skFXOE0U45afCXm-cqERY4k8HCiHtqKQ@mail.gmail.com>

On Nov 14, 2011 9:22 PM, <Valdis.Kletnieks at vt.edu> wrote:
>
> On Mon, 14 Nov 2011 19:06:13 EST, William Herrin said:
>
> > Using two firewalls in serial from two different vendors doubles the
> > complexity. Yet it almost always improves security: fat fingers on one
> > firewall rarely repeat the same way on the second and a rogue packet
> > must pass both.
>

Complexity equals downtime. I know at least one definition of security
includes availability .

> Fat fingers are actually not the biggest issue - a far bigger problem are
brain
> failures.  If you thought opening port 197 was a good idea, you will have
done
> it on both firewalls.  And it doesn't even help to run automated config
> checkers - because you'll have marked port 197 as "good" in there as
well. ;)
>
> And it doesn't even help with fat-finger issues anyhow, because you
*know* that
> if your firewall admin is any good, they'll just write a script that
loads both
> firewalls from a master config file - and then proceed to fat-finger said
> config file.

And, stateful firewalls are a very common dos vector.  Attacking firewall
sessions per second capacity and blowing up a session table can bring a
service down real quick. Furthermore, firewalls are frequently installed at
a choke point ... Which makes them a topological single point of
failure.... So, they are deployed in pairs .... And therefore have a nice
cascading failure behavior when hit with a dos.

Cb

From vton at integra.fr  Tue Nov 15 03:30:41 2011
From: vton at integra.fr (Viet-Hung Ton)
Date: Tue, 15 Nov 2011 10:30:41 +0100 (CET)
Subject: Foundry MRP cohabit with STP
In-Reply-To: <22933488.86198.1321348355390.JavaMail.root@FRM001P08ASU.itc.integra.fr>
Message-ID: <8538341.86454.1321349440970.JavaMail.root@FRM001P08ASU.itc.integra.fr>

Hi, 


We are deploying a network using MRP of Foundry (Metro Ring Protocol of Brocade now) and STP (in this case Rapid Spanning Tree Protocol-802.1W). The problem is that in some networking segment, we must enable both of protocols in the same interfaces and vlans for the correct function of our network. By the way, as MRP and STP are 2 protocols of loop prevention, the devices of Brocade force us choosing and activating just one among them that not our intention. 


Anybody has the same situation of some experiences in this case: how to make coexist these two protocols. (MRP and STP). 

Best thanks, 


Viet Ton. 





From fdelmotte1 at mac.com  Tue Nov 15 04:03:05 2011
From: fdelmotte1 at mac.com (Fabien Delmotte)
Date: Tue, 15 Nov 2011 11:03:05 +0100
Subject: Foundry MRP cohabit with STP
In-Reply-To: <8538341.86454.1321349440970.JavaMail.root@FRM001P08ASU.itc.integra.fr>
References: <8538341.86454.1321349440970.JavaMail.root@FRM001P08ASU.itc.integra.fr>
Message-ID: <2A56D0E2-DFA3-4BF9-9A61-2634593165B4@mac.com>

Hi,

You cannot enable MRP and STP on the same physical interface, but you can enable MRP on a specific interface and STP on another, the only issue is MRP and STP are using the CPU, so if you loose a hello packet you may have some network instability.

Regards

Fabien

P.S je suis en France si tu as besoin.

Le 15 nov. 2011 ? 10:30, Viet-Hung Ton a ?crit :

> Hi, 
> 
> 
> We are deploying a network using MRP of Foundry (Metro Ring Protocol of Brocade now) and STP (in this case Rapid Spanning Tree Protocol-802.1W). The problem is that in some networking segment, we must enable both of protocols in the same interfaces and vlans for the correct function of our network. By the way, as MRP and STP are 2 protocols of loop prevention, the devices of Brocade force us choosing and activating just one among them that not our intention. 
> 
> 
> Anybody has the same situation of some experiences in this case: how to make coexist these two protocols. (MRP and STP). 
> 
> Best thanks, 
> 
> 
> Viet Ton. 
> 
> 
> 
> 



From leigh.porter at ukbroadband.com  Tue Nov 15 04:57:32 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Tue, 15 Nov 2011 10:57:32 +0000
Subject: Arguing against using public IP space
In-Reply-To: <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
Message-ID: <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>



On 14 Nov 2011, at 18:52, "McCall, Gabriel" <Gabriel.McCall at thyssenkrupp.com> wrote:

> Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet.


Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure!

As somebody else mentioned on this thread, a NAT box with private space on one side fails closed.

--
Leigh


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From rcheung at rochester.rr.com  Tue Nov 15 05:34:15 2011
From: rcheung at rochester.rr.com (rcheung at rochester.rr.com)
Date: Tue, 15 Nov 2011 6:34:15 -0500
Subject: Cell-based OOB  management devices
In-Reply-To: <FCD26398C5EDE746BFC47F43EA52A173054DA958@dino.ad.hostasaurus.com>
Message-ID: <20111115113416.HO6GH.49151.root@hrndva-web09-z01>

David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client.


-RC


---- David Hubbard <dhubbard at dino.hostasaurus.com> wrote: 
> Hi all, I am looking at cellular-based devices as a higher
> speed alternative to dial-up backup access methods for
> out of band management during emergencies.  I was
> wondering if anyone had experiences with such devices
> they could share?
> 
> Devices I've found include Sierra Wireless AirLink Raven X,
> Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G.  I
> have no experience with any but they all appear to support
> the Sprint network which I assume would be ideal due to
> not having usage caps on data (currently).  The Opengear
> device runs linux and has four serial ports, a usb port
> for additional storage and ethernet, so it seems to have
> some small advantages over the others since it could double
> as an emergency self-contained management station you can
> SSH into and run diagnostics from.  All appear to have
> VPN/gateway support.
> 
> What none of them are clear on is how you would connect
> to it over cellular since I assume you're just paying for
> a typical data plan and it will randomly obtain IP 
> addresses.  Maybe some type of dynamic dns service so you
> can easily figure out your device's current IP?  How
> stable is the access to the device?  Any idea if any of
> them can do ipv6?
> 
> Thanks!
> 
> David
> 
> 



From rcheung at rochester.rr.com  Tue Nov 15 05:40:38 2011
From: rcheung at rochester.rr.com (rcheung at rochester.rr.com)
Date: Tue, 15 Nov 2011 6:40:38 -0500
Subject: Cell-based OOB  management devices
Message-ID: <20111115114038.FVF0E.49163.root@hrndva-web09-z01>

David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client.


-RC


---- David Hubbard <dhubbard at dino.hostasaurus.com> wrote: 
> Hi all, I am looking at cellular-based devices as a higher
> speed alternative to dial-up backup access methods for
> out of band management during emergencies.  I was
> wondering if anyone had experiences with such devices
> they could share?
> 
> Devices I've found include Sierra Wireless AirLink Raven X,
> Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G.  I
> have no experience with any but they all appear to support
> the Sprint network which I assume would be ideal due to
> not having usage caps on data (currently).  The Opengear
> device runs linux and has four serial ports, a usb port
> for additional storage and ethernet, so it seems to have
> some small advantages over the others since it could double
> as an emergency self-contained management station you can
> SSH into and run diagnostics from.  All appear to have
> VPN/gateway support.
> 
> What none of them are clear on is how you would connect
> to it over cellular since I assume you're just paying for
> a typical data plan and it will randomly obtain IP 
> addresses.  Maybe some type of dynamic dns service so you
> can easily figure out your device's current IP?  How
> stable is the access to the device?  Any idea if any of
> them can do ipv6?
> 
> Thanks!
> 
> David
> 
> 



From faisal at snappydsl.net  Tue Nov 15 07:49:17 2011
From: faisal at snappydsl.net (Faisal Imtiaz)
Date: Tue, 15 Nov 2011 08:49:17 -0500
Subject: Cell-based OOB  management devices
In-Reply-To: <20111115113416.HO6GH.49151.root@hrndva-web09-z01>
References: <20111115113416.HO6GH.49151.root@hrndva-web09-z01>
Message-ID: <9335C522-96E2-4E1D-AED8-A89406CBE0EF@snappydsl.net>

A very flexible solution can be done with the Mikrotik family of routers....see this as an example for more details..

http://mum.mikrotik.com/presentations/BR09/3G_Applications.pdf

Faisal

On Nov 15, 2011, at 6:34 AM, <rcheung at rochester.rr.com> wrote:

> David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client.
> 
> 
> -RC
> 
> 
> ---- David Hubbard <dhubbard at dino.hostasaurus.com> wrote: 
>> Hi all, I am looking at cellular-based devices as a higher
>> speed alternative to dial-up backup access methods for
>> out of band management during emergencies.  I was
>> wondering if anyone had experiences with such devices
>> they could share?
>> 
>> Devices I've found include Sierra Wireless AirLink Raven X,
>> Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G.  I
>> have no experience with any but they all appear to support
>> the Sprint network which I assume would be ideal due to
>> not having usage caps on data (currently).  The Opengear
>> device runs linux and has four serial ports, a usb port
>> for additional storage and ethernet, so it seems to have
>> some small advantages over the others since it could double
>> as an emergency self-contained management station you can
>> SSH into and run diagnostics from.  All appear to have
>> VPN/gateway support.
>> 
>> What none of them are clear on is how you would connect
>> to it over cellular since I assume you're just paying for
>> a typical data plan and it will randomly obtain IP 
>> addresses.  Maybe some type of dynamic dns service so you
>> can easily figure out your device's current IP?  How
>> stable is the access to the device?  Any idea if any of
>> them can do ipv6?
>> 
>> Thanks!
>> 
>> David
>> 
>> 
> 
> 
> 


From Valdis.Kletnieks at vt.edu  Tue Nov 15 08:17:20 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 15 Nov 2011 09:17:20 -0500
Subject: Arguing against using public IP space
In-Reply-To: Your message of "Tue, 15 Nov 2011 10:57:32 GMT."
 <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
 <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
Message-ID: <175192.1321366640@turing-police.cc.vt.edu>

On Tue, 15 Nov 2011 10:57:32 GMT, Leigh Porter said:

> Well this is not quite true, is it.. If your firewall is not working and you
> have private space internally then you are a lot better off then if you have
> public space internally! So if your firewall is not working then having private
> space on one side is a hell of a lot more secure!

By the same token, if your firewall fails closed rather than fails open, you're
more secure.

And this is totally overlooking the fact that the vast majority of *actual*
attacks these days are web-based drive-bys and similar things that most
firewalls are configured to pass through.  Think about it - if a NAT'ed
firewall provides any real protection against real attacks, why are there still
so many zombied systems out there?  I mean, Windows Firewall has been shipping
with inbound "default deny" since XP SP2 or so. How many years ago was that?
And what *real* security over and above that host-based firewall are you
getting from that appliance?

Or as Dr Phil would say "FIrewalls - how is that working out for you?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111115/b8912b51/attachment.bin>

From chuckchurch at gmail.com  Tue Nov 15 08:46:32 2011
From: chuckchurch at gmail.com (Chuck Church)
Date: Tue, 15 Nov 2011 09:46:32 -0500
Subject: Arguing against using public IP space
In-Reply-To: <175192.1321366640@turing-police.cc.vt.edu>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
 <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
 <175192.1321366640@turing-police.cc.vt.edu>
Message-ID: <001a01cca3a5$5efa1200$1cee3600$@com>

-----Original Message-----
From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] 
Sent: Tuesday, November 15, 2011 9:17 AM
To: Leigh Porter
Cc: nanog at nanog.org; McCall, Gabriel
Subject: Re: Arguing against using public IP space

> And this is totally overlooking the fact that the vast majority of
*actual* attacks these days are web-based drive-bys > and similar things
that most firewalls are configured to pass through.  Think about it - if a
NAT'ed firewall provides > any real protection against real attacks, why are
there still so many zombied systems out there?  I mean, Windows         >
Firewall has been shipping with inbound "default deny" since XP SP2 or so.
How many years ago was that?

Simple explanation is that most firewall rules are written to trust traffic
initiated by 'inside' (your users), and the return traffic gets trusted as
well.  This applies to both Window's own FW, and most hardware based
firewalls.  And NAT/PAT devices too.  There's nothing more dangerous than a
user with a web browser.  Honestly, FWs will keep out attacks initiated from
outside.  But for traffic permitted or initiated by the inside, IPS is only
way to go.  

Chuck  



From owen at delong.com  Tue Nov 15 08:52:19 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 15 Nov 2011 06:52:19 -0800
Subject: Arguing against using public IP space
In-Reply-To: <CAP-guGVZH+Ffb=_h64dVe6wZL=1yYhvn1+iao5-KFJejgcO1jA@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
 <CAP-guGVZH+Ffb=_h64dVe6wZL=1yYhvn1+iao5-KFJejgcO1jA@mail.gmail.com>
Message-ID: <D2ED9E0B-1128-4E90-8B78-A104F8298D5F@delong.com>


On Nov 14, 2011, at 11:32 AM, William Herrin wrote:

> On Mon, Nov 14, 2011 at 1:50 PM, McCall, Gabriel
> <Gabriel.McCall at thyssenkrupp.com> wrote:
>> Chuck, you're right that this should not happen- but
>> the reason it should not happen is because you have
>> a properly functioning stateful firewall, not because
>> you're using NAT. If your firewall is working properly,
>> then having public addresses behind it is no less secure
>> than private. And if your firewall is not working properly,
>> then having private addresses behind it is no
>> more secure than public. In either case, NAT gains
>> you nothing over what you'd have with a firewalled
>> public-address subnet.
>> 
>> The fact that consumer cpe's typically do both nat
>> and stateful firewalling does not mean that those
>> functions are inseparable.
> 
> Gabriel,
> 
> This is not accurate.
> 
> First, many:1 NAT (sometimes also called PAT) is not separable from a
> stateful firewall. You can build a stateful firewall without
> many-to-one NAT but the reverse is not possible.
> 

Actually, you can. You need a state machine, but, several recent incidents
have proven that the state machine in many of the lower-end consumer
appliances is not, in fact, a firewall. This has been explained earlier in the
thread, so I won't repeat it here.

> Second, while a security benefit from RFC 1918 addressing combined
> with 1:1 NAT is dubious at best, the same is not true for the much
> more commonly implemented many:1 NAT.
> 

Repeating this fallacy still doesn't make it true.

> With RFC1918 plus many:1 NAT, most if not all functions of the
> interior of the network are not addressable from far locations outside
> the network, regardless of the correct or incorrect operation of the
> security apparatus. This is an additional boundary which must be
> bypassed in order to gain access to the network interior. While there
> are a variety of techniques for circumventing this boundary no
> combination of them guarantees successful breach. Hence it provides a
> security benefit all on its own.

If the security apparatus malfunctions, nothing prevents it from malfunctioning
in a way that passes packets to the RFC-1918 addressed hosts.

> 
> You would not rely on NAT+RFC1918 alone to secure a network and
> neither would I. However, that's far from meaning that the use of
> RFC1918 is never (or even rarely) operative in a network's security
> process.

RFC-1918 and NAT as a security measure is, at best, a locking
screen door deployed in front of a vault door. If you take away the
vault door, the screen door really doesn't do much. If the vault door
is still there, the presence or absence of the screen door is largely
irrelevant.

Owen



From kuenzler at init7.net  Tue Nov 15 08:56:55 2011
From: kuenzler at init7.net (Fredy Kuenzler)
Date: Tue, 15 Nov 2011 15:56:55 +0100
Subject: Minimum Allocation Size by RIRs (IPv4)
Message-ID: <4EC27DB7.4000800@init7.net>

I'm trying to compile a comprehensive and up-to-date list of Minimum 
Allocation Sizes by the various RIRs. Any hint would be appreciated. I have 
so far:

ARIN:  https://www.arin.net/knowledge/ip_blocks.html

APNIC: 
http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations 
(seems that they have recently changed from /22 to /24, which is not too 
helpful...)

RIPE NCC: http://www.ripe.net/ripe/docs/ripe-510#5

Nothing found for AFRINIC and LACNIC yet, and legacy space, too.

-- 
Fredy K?nzler

Init Seven AG
AS13030
Elias-Canetti-Strasse 7
CH-8050 Z?rich
Skype:   flyingpotato
Phone:   +41 44 315 4400
Fax:     +41 44 315 4401
Twitter: @init7
http://www.init7.net/



From bill at herrin.us  Tue Nov 15 08:56:38 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 15 Nov 2011 09:56:38 -0500
Subject: Arguing against using public IP space
In-Reply-To: <175192.1321366640@turing-police.cc.vt.edu>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us>
 <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
 <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
 <175192.1321366640@turing-police.cc.vt.edu>
Message-ID: <CAP-guGXMNhCyA4J1jd6gNryuPD0whmKVkqBesjhNgk5M1FcjXw@mail.gmail.com>

On Tue, Nov 15, 2011 at 9:17 AM,  <Valdis.Kletnieks at vt.edu> wrote:
> And this is totally overlooking the fact that the vast majority of *actual*
> attacks these days are web-based drive-bys and similar things that most
> firewalls are configured to pass through.

Valdis,

A firewall's job is to prevent the success of ACTIVE attack vectors
against your network. If your firewall successfully restricts
attackers to passive attack vectors (drive-by downloads) and social
engineering vectors then it has done everything reasonably expected of
it. Those other parts of the overall network security picture are
dealt with elsewhere in system security apparatus. So it's no mistake
than in a discussion of firewalls those two attack vectors do not
feature prominently.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jlewis at lewis.org  Tue Nov 15 08:59:39 2011
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 15 Nov 2011 09:59:39 -0500 (EST)
Subject: Minimum Allocation Size by RIRs (IPv4)
In-Reply-To: <4EC27DB7.4000800@init7.net>
References: <4EC27DB7.4000800@init7.net>
Message-ID: <Pine.LNX.4.61.1111150958360.24418@soloth.lewis.org>

On Tue, 15 Nov 2011, Fredy Kuenzler wrote:

> I'm trying to compile a comprehensive and up-to-date list of Minimum 
> Allocation Sizes by the various RIRs. Any hint would be appreciated. I have 
> so far:
>
> ARIN:  https://www.arin.net/knowledge/ip_blocks.html
>
> APNIC: 
> http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations 
> (seems that they have recently changed from /22 to /24, which is not too 
> helpful...)
>
> RIPE NCC: http://www.ripe.net/ripe/docs/ripe-510#5
>
> Nothing found for AFRINIC and LACNIC yet, and legacy space, too.

I have some helpful links and at least a starting point for data (a couple 
of years old now) in this blog entry:

http://jonsblog.lewis.org/2008/01/19#bgp

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From owen at delong.com  Tue Nov 15 09:00:25 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 15 Nov 2011 07:00:25 -0800
Subject: Ok;
 let's have the "Does DNAT contribute to Security" argument one more
 time...
In-Reply-To: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
Message-ID: <A7FA7DB0-5C34-4338-AA04-54086426516E@delong.com>

> 
> On the other hand, since a firewall's job is to stop packets you don't want,
> if it stops doing it's just as a firewall, it's likely to keep on doing it's
> other job: passing packets.  It certainly depends on the fundamental design
> of the firewall, which I can't speak to generally... but you proponents of
> "NAT contributes no security" can't, either.
> 

Perhaps this misunderstanding of the job of a firewall explains your
errant conclusions about their failure modes better than anything else
in the thread.

I would say that your description above does not fit a stateful firewall, but,
instead describes a packet-filtering router.

A stateful firewall's job is to forward only those packets you have permitted.
If ti stops doing it's job, it's default failure mode is to stop forwarding
packets. Please explain to me how mutilating the packet header makes
any difference in this.

>> That makes sense, but I'm wondering if that should be considered correct
>> behavior. Obviously a non-consumer grade router can have rules defining
>> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
>> everything coming from the outside in to either a) match up with
>> something in the translation table, b) be a service the router itself is hosting
>> (http, etc), or c) be a port it explicitly forwards to the same inside
>> host.
> 
>> Anything not matching one of those 3 categories you'd think could be
>> dropped. Routing without translating ports and addresses seems like
>> the root of the issue.
> 
> It is.  And IME, the people who think NAT provides no security rarely if
> ever seem to address that aspect of the issue. 
> 

It's a lovely hypothetical description of how those devices should work.
IME, and, as has been explained earlier in the thread, it is not necessarily
how they ACTUALLY work. Since security depends not on the theoretical
ideal of how the devices should work, but, rather on how they actually
work, perhaps it is worth considering that our addressing reality instead
of theory is actually a feature rather than a bug.

> And, for what it's worth, I'm discussing the common case: 1-to-many incoming
> DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on
> other ports.

I think that is what the discussion has been about all along.

Owen



From bhmccie at gmail.com  Tue Nov 15 09:06:50 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Tue, 15 Nov 2011 09:06:50 -0600
Subject: Arguing against using public IP space
In-Reply-To: <CAP-guGXMNhCyA4J1jd6gNryuPD0whmKVkqBesjhNgk5M1FcjXw@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
 <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
 <175192.1321366640@turing-police.cc.vt.edu>
 <CAP-guGXMNhCyA4J1jd6gNryuPD0whmKVkqBesjhNgk5M1FcjXw@mail.gmail.com>
Message-ID: <4EC2800A.5090506@gmail.com>

Guys,
     Everyone is complaining about whether a FW serves its purpose or 
not. Take a step back. Security is about layers. Router ACLs to filter 
whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect HTTP 
payload. Patch management at the OS and Application layer on the server. 
Heuristics analyzing strategically placed SPAN feeds. The list goes on 
depending upon the size of your enterprise.

I don't think in a large environment you can avoid "complexity" these 
days. What you have to succeed at is managing that complexity. And L3 
FWs have a very important purpose. They filter garbage. You focus your 
IDS/IPS on what the FW is allowing. It's more than a screen door. But 
yes, it's LESS than a true vault door. It's all about mitigating the 
risk. You'll never be 100% full proof.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/15/2011 08:56 AM, William Herrin wrote:
> On Tue, Nov 15, 2011 at 9:17 AM,<Valdis.Kletnieks at vt.edu>  wrote:
>    
>> And this is totally overlooking the fact that the vast majority of *actual*
>> attacks these days are web-based drive-bys and similar things that most
>> firewalls are configured to pass through.
>>      
> Valdis,
>
> A firewall's job is to prevent the success of ACTIVE attack vectors
> against your network. If your firewall successfully restricts
> attackers to passive attack vectors (drive-by downloads) and social
> engineering vectors then it has done everything reasonably expected of
> it. Those other parts of the overall network security picture are
> dealt with elsewhere in system security apparatus. So it's no mistake
> than in a discussion of firewalls those two attack vectors do not
> feature prominently.
>
> Regards,
> Bill Herrin
>
>
>
>    

From bhmccie at gmail.com  Tue Nov 15 09:13:26 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Tue, 15 Nov 2011 09:13:26 -0600
Subject: Ok; let's have the "Does DNAT contribute to Security" argument
 one more time...
In-Reply-To: <A7FA7DB0-5C34-4338-AA04-54086426516E@delong.com>
References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
 <A7FA7DB0-5C34-4338-AA04-54086426516E@delong.com>
Message-ID: <4EC28196.5010206@gmail.com>

     There are some methods of security that NAT has a good use for. We 
use NAT to prevent reachibility. In other words, not only does an ACL 
have to allow traffic thru the FW, but a complimenting NAT rule has to 
allow the actual layer 3 reachibility. If not, even with the ACL, the 
routing path won't be available. It is a great "safety" check when we 
implement FW rules because it forces almost every manual entry to have 
two specific steps.

     In our layered environments, we also use local routing in some of 
our DMZs. In other words, a server on a subnet will only be aware of 
it's local broadcast domain. Even with a default GW, if it doesn't have 
a NAT in the FW, it can't route thru it. So even if a server gets 
compromised, the bad guy doesn't have a method to reach beyond the local 
DMZ without also making adjustments on the FW.

I don't think this complicates our design to much and definitely keeps 
us in check from human errors.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/15/2011 09:00 AM, Owen DeLong wrote:
>> On the other hand, since a firewall's job is to stop packets you don't want,
>> if it stops doing it's just as a firewall, it's likely to keep on doing it's
>> other job: passing packets.  It certainly depends on the fundamental design
>> of the firewall, which I can't speak to generally... but you proponents of
>> "NAT contributes no security" can't, either.
>>
>>      
> Perhaps this misunderstanding of the job of a firewall explains your
> errant conclusions about their failure modes better than anything else
> in the thread.
>
> I would say that your description above does not fit a stateful firewall, but,
> instead describes a packet-filtering router.
>
> A stateful firewall's job is to forward only those packets you have permitted.
> If ti stops doing it's job, it's default failure mode is to stop forwarding
> packets. Please explain to me how mutilating the packet header makes
> any difference in this.
>
>    
>>> That makes sense, but I'm wondering if that should be considered correct
>>> behavior. Obviously a non-consumer grade router can have rules defining
>>> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
>>> everything coming from the outside in to either a) match up with
>>> something in the translation table, b) be a service the router itself is hosting
>>> (http, etc), or c) be a port it explicitly forwards to the same inside
>>> host.
>>>        
>>      
>>> Anything not matching one of those 3 categories you'd think could be
>>> dropped. Routing without translating ports and addresses seems like
>>> the root of the issue.
>>>        
>> It is.  And IME, the people who think NAT provides no security rarely if
>> ever seem to address that aspect of the issue.
>>
>>      
> It's a lovely hypothetical description of how those devices should work.
> IME, and, as has been explained earlier in the thread, it is not necessarily
> how they ACTUALLY work. Since security depends not on the theoretical
> ideal of how the devices should work, but, rather on how they actually
> work, perhaps it is worth considering that our addressing reality instead
> of theory is actually a feature rather than a bug.
>
>    
>> And, for what it's worth, I'm discussing the common case: 1-to-many incoming
>> DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on
>> other ports.
>>      
> I think that is what the discussion has been about all along.
>
> Owen
>
>
>    

From cb.list6 at gmail.com  Tue Nov 15 09:20:50 2011
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Tue, 15 Nov 2011 07:20:50 -0800
Subject: Arguing against using public IP space
In-Reply-To: <4EC2800A.5090506@gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us>
 <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
 <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
 <175192.1321366640@turing-police.cc.vt.edu>
 <CAP-guGXMNhCyA4J1jd6gNryuPD0whmKVkqBesjhNgk5M1FcjXw@mail.gmail.com>
 <4EC2800A.5090506@gmail.com>
Message-ID: <CAD6AjGT+9AiWJ977G6Qm6X4Xyj_yUwmri8OATViV67m8cYWoeg@mail.gmail.com>

On Nov 15, 2011 7:09 AM, "-Hammer-" <bhmccie at gmail.com> wrote:
>
> Guys,
>    Everyone is complaining about whether a FW serves its purpose or not.
Take a step back. Security is about layers. Router ACLs to filter
whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect HTTP
payload. Patch management at the OS and Application layer on the server.
Heuristics analyzing strategically placed SPAN feeds. The list goes on
depending upon the size of your enterprise.
>

I would say security is about stopping threats , not layering in technology
and tools. Granted, layer is a good idea, throwing everything including the
kitchen sink at a problem will result in just a larger problem.

> I don't think in a large environment you can avoid "complexity" these
days. What you have to succeed at is managing that complexity. And L3 FWs
have a very important purpose. They filter garbage. You focus your IDS/IPS
on what the FW is allowing. It's more than a screen door. But yes, it's
LESS than a true vault door. It's all about mitigating the risk. You'll
never be 100% full proof.
>

Large environments have to force simplicity to combat the natural ebb of
complexity.  The largest operators live by one rule , KISS.

L3 network fw are an attack vector and single point of failure.

But, I think this thread is not changing anyone's mind at this point.

> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
>
> On 11/15/2011 08:56 AM, William Herrin wrote:
>>
>> On Tue, Nov 15, 2011 at 9:17 AM,<Valdis.Kletnieks at vt.edu>  wrote:
>>
>>>
>>> And this is totally overlooking the fact that the vast majority of
*actual*
>>> attacks these days are web-based drive-bys and similar things that most
>>> firewalls are configured to pass through.
>>>
>>
>> Valdis,
>>
>> A firewall's job is to prevent the success of ACTIVE attack vectors
>> against your network. If your firewall successfully restricts
>> attackers to passive attack vectors (drive-by downloads) and social
>> engineering vectors then it has done everything reasonably expected of
>> it. Those other parts of the overall network security picture are
>> dealt with elsewhere in system security apparatus. So it's no mistake
>> than in a discussion of firewalls those two attack vectors do not
>> feature prominently.
>>
>> Regards,
>> Bill Herrin
>>
>>
>>
>>

From bhmccie at gmail.com  Tue Nov 15 09:19:59 2011
From: bhmccie at gmail.com (-Hammer-)
Date: Tue, 15 Nov 2011 09:19:59 -0600
Subject: Arguing against using public IP space
In-Reply-To: <CAD6AjGT+9AiWJ977G6Qm6X4Xyj_yUwmri8OATViV67m8cYWoeg@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>	<201111131638.pADGcoiu007448@mail.r-bonomi.com>	<CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>	<20111113212756.GD73635@macbook.bluepipe.net>	<4EC03B30.2090007@dougbarton.us>	<001001cca255$b4a45450$1decfcf0$@com>	<20111113225924.GF73635@macbook.bluepipe.net>	<002201cca25f$6c5340d0$44f9c270$@com>	<28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>	<6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>	<175192.1321366640@turing-police.cc.vt.edu>	<CAP-guGXMNhCyA4J1jd6gNryuPD0whmKVkqBesjhNgk5M1FcjXw@mail.gmail.com>	<4EC2800A.5090506@gmail.com>
 <CAD6AjGT+9AiWJ977G6Qm6X4Xyj_yUwmri8OATViV67m8cYWoeg@mail.gmail.com>
Message-ID: <4EC2831F.3030009@gmail.com>

I see your side Cameron.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/15/2011 09:20 AM, Cameron Byrne wrote:
>
>
> On Nov 15, 2011 7:09 AM, "-Hammer-" <bhmccie at gmail.com 
> <mailto:bhmccie at gmail.com>> wrote:
> >
> > Guys,
> >    Everyone is complaining about whether a FW serves its purpose or 
> not. Take a step back. Security is about layers. Router ACLs to filter 
> whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect 
> HTTP payload. Patch management at the OS and Application layer on the 
> server. Heuristics analyzing strategically placed SPAN feeds. The list 
> goes on depending upon the size of your enterprise.
> >
>
> I would say security is about stopping threats , not layering in 
> technology and tools. Granted, layer is a good idea, throwing 
> everything including the kitchen sink at a problem will result in just 
> a larger problem.
>
> > I don't think in a large environment you can avoid "complexity" 
> these days. What you have to succeed at is managing that complexity. 
> And L3 FWs have a very important purpose. They filter garbage. You 
> focus your IDS/IPS on what the FW is allowing. It's more than a screen 
> door. But yes, it's LESS than a true vault door. It's all about 
> mitigating the risk. You'll never be 100% full proof.
> >
>
> Large environments have to force simplicity to combat the natural ebb 
> of complexity.  The largest operators live by one rule , KISS.
>
> L3 network fw are an attack vector and single point of failure.
>
> But, I think this thread is not changing anyone's mind at this point.
>
> > -Hammer-
> >
> > "I was a normal American nerd"
> > -Jack Herer
> >
> >
> >
> >
> > On 11/15/2011 08:56 AM, William Herrin wrote:
> >>
> >> On Tue, Nov 15, 2011 at 9:17 AM,<Valdis.Kletnieks at vt.edu 
> <mailto:Valdis.Kletnieks at vt.edu>>  wrote:
> >>
> >>>
> >>> And this is totally overlooking the fact that the vast majority of 
> *actual*
> >>> attacks these days are web-based drive-bys and similar things that 
> most
> >>> firewalls are configured to pass through.
> >>>
> >>
> >> Valdis,
> >>
> >> A firewall's job is to prevent the success of ACTIVE attack vectors
> >> against your network. If your firewall successfully restricts
> >> attackers to passive attack vectors (drive-by downloads) and social
> >> engineering vectors then it has done everything reasonably expected of
> >> it. Those other parts of the overall network security picture are
> >> dealt with elsewhere in system security apparatus. So it's no mistake
> >> than in a discussion of firewalls those two attack vectors do not
> >> feature prominently.
> >>
> >> Regards,
> >> Bill Herrin
> >>
> >>
> >>
> >>
>

From owen at delong.com  Tue Nov 15 09:32:37 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 15 Nov 2011 07:32:37 -0800
Subject: Arguing against using public IP space
In-Reply-To: <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
 <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
Message-ID: <F94EB274-D5AC-4018-927C-97E4F1114643@delong.com>


On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote:

> 
> 
> On 14 Nov 2011, at 18:52, "McCall, Gabriel" <Gabriel.McCall at thyssenkrupp.com> wrote:
> 
>> Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet.
> 
> 
> Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure!
> 
This is not true.

If your firewall is not working, it should not be passing packets.

If you put a router where you needed a firewall, then, this is not a failure of the firewall, but, a
failure of the network implementor and the address space will not have any impact whatsoever
on your lack of security.

> As somebody else mentioned on this thread, a NAT box with private space on one side fails closed.
> 

So does a firewall.

Owen



From cmorris at cs.odu.edu  Tue Nov 15 09:44:51 2011
From: cmorris at cs.odu.edu (Charles Morris)
Date: Tue, 15 Nov 2011 10:44:51 -0500
Subject: Ok; let's have the "Does DNAT contribute to Security" argument
 one more time...
In-Reply-To: <A7FA7DB0-5C34-4338-AA04-54086426516E@delong.com>
References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com>
 <A7FA7DB0-5C34-4338-AA04-54086426516E@delong.com>
Message-ID: <CABgawuaRTx_1Eof=2w19pT1H1vPvt=2DDSnxxSan=r_BS8fLsw@mail.gmail.com>

Against my better judgment to get in the middle of this classic
discussion, two points...


One, many firewalls have fail-safe capabilities, in addition to fail-secure;
even if they didn't it could be trivially programmed, or configured to
do so in series,
and as configuration is fairly arbitrary the comments about "how
firewalls work" aren't really valid.

My firewall most certainly works differently than yours ...

There are also issues with stateful failover versus stateless failover.

The two schools of thought on this issue are, as far as I know:
a) Fail as little as possible and as compartmentalized as possible,
attempting to keep service online at the expense of security (perhaps)
(fail-safe)
or
b) Fail with the intent to keep the network as secure as possible,
even if it means causing total service failure. (fail-secure)

I find both to be valid and each network should be individually
evaluated for application of A or B.
If you have a secretless, isolated, read-only environment there is no
reason to be concerned about people mucking about. in theory.


Two, I would almost guarantee the combination of NAT+firewall is
better than only firewall,
however the fact that NAT is inherently stateful and really quite
vulnerable to DoS makes for an interesting situation.

At least with only firewall you could revert to stateless mode during
a translation attack (if you chose 'A').
For a NAT to have a similar approach you would need a dark address
pool for static translation...
that doesn't seem likely or practical, saving a situation where you
paid for address time.

On the negative case, not having a NAT implies that you won't have any
NAT failures or NAT hardware costs :)
Perhaps unnecessary NAT is trading a theoretical protection (routing
isolation) for a real vulnerability (trans table overflow).


On Tue, Nov 15, 2011 at 10:00 AM, Owen DeLong <owen at delong.com> wrote:
>>
>> On the other hand, since a firewall's job is to stop packets you don't want,
>> if it stops doing it's just as a firewall, it's likely to keep on doing it's
>> other job: passing packets. ?It certainly depends on the fundamental design
>> of the firewall, which I can't speak to generally... but you proponents of
>> "NAT contributes no security" can't, either.
>>
>
> Perhaps this misunderstanding of the job of a firewall explains your
> errant conclusions about their failure modes better than anything else
> in the thread.
>
> I would say that your description above does not fit a stateful firewall, but,
> instead describes a packet-filtering router.
>
> A stateful firewall's job is to forward only those packets you have permitted.
> If ti stops doing it's job, it's default failure mode is to stop forwarding
> packets. Please explain to me how mutilating the packet header makes
> any difference in this.
>
>>> That makes sense, but I'm wondering if that should be considered correct
>>> behavior. Obviously a non-consumer grade router can have rules defining
>>> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
>>> everything coming from the outside in to either a) match up with
>>> something in the translation table, b) be a service the router itself is hosting
>>> (http, etc), or c) be a port it explicitly forwards to the same inside
>>> host.
>>
>>> Anything not matching one of those 3 categories you'd think could be
>>> dropped. Routing without translating ports and addresses seems like
>>> the root of the issue.
>>
>> It is. ?And IME, the people who think NAT provides no security rarely if
>> ever seem to address that aspect of the issue.
>>
>
> It's a lovely hypothetical description of how those devices should work.
> IME, and, as has been explained earlier in the thread, it is not necessarily
> how they ACTUALLY work. Since security depends not on the theoretical
> ideal of how the devices should work, but, rather on how they actually
> work, perhaps it is worth considering that our addressing reality instead
> of theory is actually a feature rather than a bug.
>
>> And, for what it's worth, I'm discussing the common case: 1-to-many incoming
>> DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on
>> other ports.
>
> I think that is what the discussion has been about all along.
>
> Owen
>
>
>


From jgreco at ns.sol.net  Tue Nov 15 09:54:50 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Tue, 15 Nov 2011 09:54:50 -0600 (CST)
Subject: Arguing against using public IP space
In-Reply-To: <F94EB274-D5AC-4018-927C-97E4F1114643@delong.com>
Message-ID: <201111151554.pAFFsoWL092906@aurora.sol.net>

> If you put a router where you needed a firewall, then, this is not a =
> failure of the firewall, but, a
> failure of the network implementor and the address space will not have =
> any impact whatsoever
> on your lack of security.

And the difference between a router and a firewall is ...?

Apparently, one bit.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From seitz at strato-rz.de  Tue Nov 15 10:22:09 2011
From: seitz at strato-rz.de (Christian Seitz)
Date: Tue, 15 Nov 2011 17:22:09 +0100
Subject: Minimum Allocation Size by RIRs (IPv4)
In-Reply-To: <4EC27DB7.4000800@init7.net>
References: <4EC27DB7.4000800@init7.net>
Message-ID: <4EC291B1.3080908@strato-rz.de>

Hello Fredy,

Am 15.11.2011 15:56, schrieb Fredy Kuenzler:
> I'm trying to compile a comprehensive and up-to-date list of Minimum
> Allocation Sizes by the various RIRs. Any hint would be appreciated. I have so
> far:
> 
> ARIN:  https://www.arin.net/knowledge/ip_blocks.html
> 
> APNIC:
> http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations
> (seems that they have recently changed from /22 to /24, which is not too
> helpful...)
> 
> RIPE NCC: http://www.ripe.net/ripe/docs/ripe-510#5
> 
> Nothing found for AFRINIC and LACNIC yet, and legacy space, too.

I made such a list some month ago and also found those links:

LACNIC: http://lacnic.net/en/registro/index.html
AfriNIC: http://www.afrinic.net/Registration/resources.htm
ARIN Micro Allocations: https://www.arin.net/knowledge/micro_allocations.html

Regards,

Christian Seitz
Network Operations

-- 
---------------------------------------------------------------------------
Telefon: +49 (0)30  - 398 02 205
Mobil  : +49 (0)172 - 389 8714
Telefax: +49 (0)30  - 398 02 222
E-Mail : seitz at strato-rz.de
Website: http://www.strato.de/
---------------------------------------------------------------------------
STRATO AG
Pascalstr. 10
10587 Berlin
---------------------------------------------------------------------------
Vorsitzender des Aufsichtsrates: Dirk Backofen
Vorstand: Damian Schmidt (Vorsitz), Julien Ardisson,
Christian Mueller, Christoph Steffens, Rene Wienholtz
Amtsgericht Berlin-Charlottenburg HRB 79450


From bill at herrin.us  Tue Nov 15 10:25:16 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 15 Nov 2011 11:25:16 -0500
Subject: Minimum Allocation Size by RIRs (IPv4)
In-Reply-To: <4EC27DB7.4000800@init7.net>
References: <4EC27DB7.4000800@init7.net>
Message-ID: <CAP-guGURYoe7uqFwcWn=bRBqrkcEXjFC0k9GFxfhFS4U1618kw@mail.gmail.com>

On Tue, Nov 15, 2011 at 9:56 AM, Fredy Kuenzler <kuenzler at init7.net> wrote:
> I'm trying to compile a comprehensive and up-to-date list of Minimum
> Allocation Sizes by the various RIRs. Any hint would be appreciated. I have
> so far:

Hi Fredy,

Due to the transfer processes which will sustain IPv4 as the regional
free pools exhaust, the minimum allocation size can be expected to
drop to /24 in essentially all /8's within the next 24 months.

Regards,
Bill Herrin





-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From rubensk at gmail.com  Tue Nov 15 10:30:55 2011
From: rubensk at gmail.com (Rubens Kuhl)
Date: Tue, 15 Nov 2011 14:30:55 -0200
Subject: Minimum Allocation Size by RIRs (IPv4)
In-Reply-To: <4EC27DB7.4000800@init7.net>
References: <4EC27DB7.4000800@init7.net>
Message-ID: <CAGFn2k1H+WN+KYuZ0g1RNRD3oBXK5tCL1Vy6ci8_GWGRODtPLg@mail.gmail.com>

On Tue, Nov 15, 2011 at 12:56 PM, Fredy Kuenzler <kuenzler at init7.net> wrote:
> I'm trying to compile a comprehensive and up-to-date list of Minimum
> Allocation Sizes by the various RIRs. Any hint would be appreciated. I have
> so far:

NIRs (National Internet Registries) in the APNIC and LACNIC area need
to be mapped as well as their policies sometimes differ from the RIRs
(although they are converging due to IPv4 exhaustion).

LACNIC: /24 - http://lacnic.net/en/politicas/manual3.html
NIC.br: /24 - http://registro.br/provedor/numeracao/regras.html
NIC.mx: /24 - http://www.iar.mx/jsf/static_content/services/resources_request/portable_ip_asn_wish/eligibilityCheck.jsf

Rubens


From rfinnesey at gmail.com  Tue Nov 15 11:05:41 2011
From: rfinnesey at gmail.com (Ryan Finnesey)
Date: Tue, 15 Nov 2011 12:05:41 -0500
Subject: Cell-based OOB  management devices
In-Reply-To: <20111115114038.FVF0E.49163.root@hrndva-web09-z01>
References: <20111115114038.FVF0E.49163.root@hrndva-web09-z01>
Message-ID: <002501cca3b9$1b877080$52965180$@gmail.com>

We do this with at&t with a custom APN works great no need to VPN.  If you want to use Sprint take a look at Sprint Data Link.  You can use your IPs on the data cards.

Cheers
Ryan


-----Original Message-----
From: rcheung at rochester.rr.com [mailto:rcheung at rochester.rr.com] 
Sent: Tuesday, November 15, 2011 6:41 AM
To: nanog at nanog.org; David Hubbard
Subject: Re: Cell-based OOB management devices

David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client.


-RC


---- David Hubbard <dhubbard at dino.hostasaurus.com> wrote: 
> Hi all, I am looking at cellular-based devices as a higher speed 
> alternative to dial-up backup access methods for out of band 
> management during emergencies.  I was wondering if anyone had 
> experiences with such devices they could share?
> 
> Devices I've found include Sierra Wireless AirLink Raven X, Digi's 
> ConnectWAN 3G or 4G and Opengear's ACM5004-G.  I have no experience 
> with any but they all appear to support the Sprint network which I 
> assume would be ideal due to not having usage caps on data 
> (currently).  The Opengear device runs linux and has four serial 
> ports, a usb port for additional storage and ethernet, so it seems to 
> have some small advantages over the others since it could double as an 
> emergency self-contained management station you can SSH into and run 
> diagnostics from.  All appear to have VPN/gateway support.
> 
> What none of them are clear on is how you would connect to it over 
> cellular since I assume you're just paying for a typical data plan and 
> it will randomly obtain IP addresses.  Maybe some type of dynamic dns 
> service so you can easily figure out your device's current IP?  How 
> stable is the access to the device?  Any idea if any of them can do 
> ipv6?
> 
> Thanks!
> 
> David
> 
> 





From owen at delong.com  Tue Nov 15 11:08:07 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 15 Nov 2011 09:08:07 -0800
Subject: Arguing against using public IP space
In-Reply-To: <201111151554.pAFFsoWL092906@aurora.sol.net>
References: <201111151554.pAFFsoWL092906@aurora.sol.net>
Message-ID: <5CBF6B7A-D16E-487B-B70D-1F36B1CDBECB@delong.com>


On Nov 15, 2011, at 7:54 AM, Joe Greco wrote:

>> If you put a router where you needed a firewall, then, this is not a =
>> failure of the firewall, but, a
>> failure of the network implementor and the address space will not have =
>> any impact whatsoever
>> on your lack of security.
> 
> And the difference between a router and a firewall is ...?
> 
> Apparently, one bit.

IMHO, a firewall does not route packets by default, but, rather only forwards
those packets which match configured policies.

A router, OTOH, routes packets by default, but, may be configured with some
policy about which packets to forward.

The difference functionally is what happens when the configuration is
lost or corrupted. Essentially fail open vs. fail closed.

Owen



From leigh.porter at ukbroadband.com  Tue Nov 15 11:14:44 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Tue, 15 Nov 2011 17:14:44 +0000
Subject: Arguing against using public IP space
In-Reply-To: <F94EB274-D5AC-4018-927C-97E4F1114643@delong.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
 <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
 <F94EB274-D5AC-4018-927C-97E4F1114643@delong.com>
Message-ID: <8B492826-660E-466A-A31D-11616E5805A4@ukbroadband.com>


On 15 Nov 2011, at 15:36, "Owen DeLong" <owen at delong.com> wrote:

> 
> On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote:
> 
>> 
>> 
>> On 14 Nov 2011, at 18:52, "McCall, Gabriel" <Gabriel.McCall at thyssenkrupp.com> wrote:
>> 
>>> Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet.
>> 
>> 
>> Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure!
>> 
> This is not true.
> 
> If your firewall is not working, it should not be passing packets.

And of course, things always fail just the way we want them to.

> 
> If you put a router where you needed a firewall, then, this is not a failure of the firewall, but, a
> failure of the network implementor and the address space will not have any impact whatsoever
> on your lack of security.

This is not really a well made point, sorry. It's about a firewall failing, perhaps due to software error or hardware issue or because somebody failed to correctly configure a firewall rule. 

The point about private space is that is forces security in a way in which public space and a firewall does not.

With private space, you are forces to explicitly configure NAT holes or VPN connections whereas with public space your boxes by default are accessible by the whole Internet. By default, on a private space network, nothing can get to it.



> 
>> As somebody else mentioned on this thread, a NAT box with private space on one side fails closed.
>> 
> 
> So does a firewall.

If it fails just how you want it to.

--
Leigh


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From leigh.porter at ukbroadband.com  Tue Nov 15 11:16:23 2011
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Tue, 15 Nov 2011 17:16:23 +0000
Subject: Arguing against using public IP space
In-Reply-To: <001a01cca3a5$5efa1200$1cee3600$@com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
 <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
 <175192.1321366640@turing-police.cc.vt.edu>
 <001a01cca3a5$5efa1200$1cee3600$@com>
Message-ID: <56433BFF-2BDF-4C12-928F-B0C576047F24@ukbroadband.com>

Quite right.. I bet all Iran's nuclear facilities have air gaps but they let people in with laptops and USB sticks.

-- 
Leigh


On 15 Nov 2011, at 14:48, "Chuck Church" <chuckchurch at gmail.com> wrote:

> -----Original Message-----
> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] 
> Sent: Tuesday, November 15, 2011 9:17 AM
> To: Leigh Porter
> Cc: nanog at nanog.org; McCall, Gabriel
> Subject: Re: Arguing against using public IP space
> 
>> And this is totally overlooking the fact that the vast majority of
> *actual* attacks these days are web-based drive-bys > and similar things
> that most firewalls are configured to pass through.  Think about it - if a
> NAT'ed firewall provides > any real protection against real attacks, why are
> there still so many zombied systems out there?  I mean, Windows         >
> Firewall has been shipping with inbound "default deny" since XP SP2 or so.
> How many years ago was that?
> 
> Simple explanation is that most firewall rules are written to trust traffic
> initiated by 'inside' (your users), and the return traffic gets trusted as
> well.  This applies to both Window's own FW, and most hardware based
> firewalls.  And NAT/PAT devices too.  There's nothing more dangerous than a
> user with a web browser.  Honestly, FWs will keep out attacks initiated from
> outside.  But for traffic permitted or initiated by the inside, IPS is only
> way to go.  
> 
> Chuck  
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From paul4004 at gmail.com  Tue Nov 15 11:15:06 2011
From: paul4004 at gmail.com (PC)
Date: Tue, 15 Nov 2011 10:15:06 -0700
Subject: Cell-based OOB management devices
In-Reply-To: <002501cca3b9$1b877080$52965180$@gmail.com>
References: <20111115114038.FVF0E.49163.root@hrndva-web09-z01>
 <002501cca3b9$1b877080$52965180$@gmail.com>
Message-ID: <CAJAdsDnNsOKd9HD0rYBefD0ovcAh1Lw__8pge3mGsx2p-U40OQ@mail.gmail.com>

Second this.  Custom APN to AT&T with ipsec lan2lan VPN built to the
provider.  Works great for this.

Once you get rid of the vpn need, you can use any cheap console server.
I've seen solutions ranging from little opengear boxes (which are great to
ship to a remote site to help a tech set something up, BTW), to home-brew
solutions involving anything that can run OpenWRT, has a usb port, and can
run screen or ser2net.

Prices for low volume (10mb/month) data plans typically are less than
analog lines, too.



On Tue, Nov 15, 2011 at 10:05 AM, Ryan Finnesey <rfinnesey at gmail.com> wrote:

> We do this with at&t with a custom APN works great no need to VPN.  If you
> want to use Sprint take a look at Sprint Data Link.  You can use your IPs
> on the data cards.
>
> Cheers
> Ryan
>
>
> -----Original Message-----
> From: rcheung at rochester.rr.com [mailto:rcheung at rochester.rr.com]
> Sent: Tuesday, November 15, 2011 6:41 AM
> To: nanog at nanog.org; David Hubbard
> Subject: Re: Cell-based OOB management devices
>
> David, a Sprint aircard can be had with a static-ip, so that should ease
> remote connectivity requirements. Or, you can opt for the Datalink (private
> VPN) service, which separates your aircard traffic from other customers
> within a VRF, obviating the need to run a separate VPN client.
>
>
> -RC
>
>
> ---- David Hubbard <dhubbard at dino.hostasaurus.com> wrote:
> > Hi all, I am looking at cellular-based devices as a higher speed
> > alternative to dial-up backup access methods for out of band
> > management during emergencies.  I was wondering if anyone had
> > experiences with such devices they could share?
> >
> > Devices I've found include Sierra Wireless AirLink Raven X, Digi's
> > ConnectWAN 3G or 4G and Opengear's ACM5004-G.  I have no experience
> > with any but they all appear to support the Sprint network which I
> > assume would be ideal due to not having usage caps on data
> > (currently).  The Opengear device runs linux and has four serial
> > ports, a usb port for additional storage and ethernet, so it seems to
> > have some small advantages over the others since it could double as an
> > emergency self-contained management station you can SSH into and run
> > diagnostics from.  All appear to have VPN/gateway support.
> >
> > What none of them are clear on is how you would connect to it over
> > cellular since I assume you're just paying for a typical data plan and
> > it will randomly obtain IP addresses.  Maybe some type of dynamic dns
> > service so you can easily figure out your device's current IP?  How
> > stable is the access to the device?  Any idea if any of them can do
> > ipv6?
> >
> > Thanks!
> >
> > David
> >
> >
>
>
>
>
>

From bill at herrin.us  Tue Nov 15 11:15:06 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 15 Nov 2011 12:15:06 -0500
Subject: Arguing against using public IP space
In-Reply-To: <4EC1B3D2.5060007@mompl.net>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <4EC1B3D2.5060007@mompl.net>
Message-ID: <CAP-guGVvaJbjBLdRWpNhv=TbQmJPPVbYOzFWwFdcMqK_AkceDA@mail.gmail.com>

On Mon, Nov 14, 2011 at 7:35 PM, Jeroen van Aart <jeroen at mompl.net> wrote:
> William Herrin wrote:
>> If your machine is addressed with a globally routable IP, a trivial
>> failure of your security apparatus leaves your machine addressable
>> from any other host in the entire world which wishes to send it
>
> Isn't that the case with IPv6? That the IP is addressable from any host in
> the entire (IPv6) world? And isn't that considered a good thing?

Hi Jeroen,

Yes, according to almost every application developer asked it's a good thing.

Me? I'm not so sure. Historically, enterprises moved away from global
addressability even when IP addresses were free, *before* address
scarcity became an issue. There's a lesson in there somewhere and I'm
not convinced it's that "they were dumb."


> I don't think that being addressable from anywhere is a security hole in and
> of itself. It's how you implement and (mis)configure your firewall and
> related things that is the (potential) security hole. Whether the IP is
> world addressable or not

I agree. That your computer is globally addressable is NOT a security
hole. It does not directly or indirectly make you vulnerable to
attack. But the inverse doesn't follow.

That your computer is not globally addressable ADDS one layer of
security in a process you hope has enough layers to prevent an attack
from penetrating.

And make no mistake: successful security is about layers, about DEPTH.
You can seek layers from other sources but a shallow security process
will tend to be easily breached.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From rfinnesey at gmail.com  Tue Nov 15 11:24:20 2011
From: rfinnesey at gmail.com (Ryan Finnesey)
Date: Tue, 15 Nov 2011 12:24:20 -0500
Subject: Cell-based OOB management devices
In-Reply-To: <CAJAdsDnNsOKd9HD0rYBefD0ovcAh1Lw__8pge3mGsx2p-U40OQ@mail.gmail.com>
References: <20111115114038.FVF0E.49163.root@hrndva-web09-z01>
 <002501cca3b9$1b877080$52965180$@gmail.com>
 <CAJAdsDnNsOKd9HD0rYBefD0ovcAh1Lw__8pge3mGsx2p-U40OQ@mail.gmail.com>
Message-ID: <033901cca3bb$6ab4d6f0$401e84d0$@gmail.com>

We pay $4 per SIM with at&t then about $2.50 per MB.

 

Cheers

Ryan

 

 

From: PC [mailto:paul4004 at gmail.com] 
Sent: Tuesday, November 15, 2011 12:15 PM
To: Ryan Finnesey
Cc: rcheung at rochester.rr.com; nanog at nanog.org; David Hubbard
Subject: Re: Cell-based OOB management devices

 

Second this.  Custom APN to AT&T with ipsec lan2lan VPN built to the
provider.  Works great for this.

Once you get rid of the vpn need, you can use any cheap console server.
I've seen solutions ranging from little opengear boxes (which are great to
ship to a remote site to help a tech set something up, BTW), to home-brew
solutions involving anything that can run OpenWRT, has a usb port, and can
run screen or ser2net.

Prices for low volume (10mb/month) data plans typically are less than analog
lines, too.




On Tue, Nov 15, 2011 at 10:05 AM, Ryan Finnesey <rfinnesey at gmail.com> wrote:

We do this with at&t with a custom APN works great no need to VPN.  If you
want to use Sprint take a look at Sprint Data Link.  You can use your IPs on
the data cards.

Cheers
Ryan



-----Original Message-----
From: rcheung at rochester.rr.com [mailto:rcheung at rochester.rr.com]
Sent: Tuesday, November 15, 2011 6:41 AM
To: nanog at nanog.org; David Hubbard
Subject: Re: Cell-based OOB management devices

David, a Sprint aircard can be had with a static-ip, so that should ease
remote connectivity requirements. Or, you can opt for the Datalink (private
VPN) service, which separates your aircard traffic from other customers
within a VRF, obviating the need to run a separate VPN client.


-RC


---- David Hubbard <dhubbard at dino.hostasaurus.com> wrote:
> Hi all, I am looking at cellular-based devices as a higher speed
> alternative to dial-up backup access methods for out of band
> management during emergencies.  I was wondering if anyone had
> experiences with such devices they could share?
>
> Devices I've found include Sierra Wireless AirLink Raven X, Digi's
> ConnectWAN 3G or 4G and Opengear's ACM5004-G.  I have no experience
> with any but they all appear to support the Sprint network which I
> assume would be ideal due to not having usage caps on data
> (currently).  The Opengear device runs linux and has four serial
> ports, a usb port for additional storage and ethernet, so it seems to
> have some small advantages over the others since it could double as an
> emergency self-contained management station you can SSH into and run
> diagnostics from.  All appear to have VPN/gateway support.
>
> What none of them are clear on is how you would connect to it over
> cellular since I assume you're just paying for a typical data plan and
> it will randomly obtain IP addresses.  Maybe some type of dynamic dns
> service so you can easily figure out your device's current IP?  How
> stable is the access to the device?  Any idea if any of them can do
> ipv6?
>
> Thanks!
>
> David
>
>





 


From Valdis.Kletnieks at vt.edu  Tue Nov 15 11:31:26 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 15 Nov 2011 12:31:26 -0500
Subject: Arguing against using public IP space
In-Reply-To: Your message of "Tue, 15 Nov 2011 09:56:38 EST."
 <CAP-guGXMNhCyA4J1jd6gNryuPD0whmKVkqBesjhNgk5M1FcjXw@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
 <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
 <175192.1321366640@turing-police.cc.vt.edu>
 <CAP-guGXMNhCyA4J1jd6gNryuPD0whmKVkqBesjhNgk5M1FcjXw@mail.gmail.com>
Message-ID: <7408.1321378286@turing-police.cc.vt.edu>

On Tue, 15 Nov 2011 09:56:38 EST, William Herrin said:

> A firewall's job is to prevent the success of ACTIVE attack vectors
> against your network. If your firewall successfully restricts
> attackers to passive attack vectors (drive-by downloads) and social
> engineering vectors then it has done everything reasonably expected of
> it. Those other parts of the overall network security picture are
> dealt with elsewhere in system security apparatus. So it's no mistake
> than in a discussion of firewalls those two attack vectors do not
> feature prominently.

You missed the point - in the greater scheme of things, the threat model has
moved on, so the entire "ZOMG We can't deploy IPv6 because there's no NAT for
security" is a total crock of bovine manure. There are *so many* lower-hanging
fruit these days that if you're trying to *actually* improve your site's
security, you'd just punt worrying about the NAT stuff and focus on doing a
better job defending against the threats that are actually succeeding in
breaking into systems.

In another year or two, lack of IPv6 deployment is going to start impacting
the "availability" part of the security triad.  I'd worry about *that* more than
"how many NATs can dance on the head of a pin".

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111115/b6678cf0/attachment.bin>

From theckman at linode.com  Tue Nov 15 11:50:26 2011
From: theckman at linode.com (Tim Heckman)
Date: Tue, 15 Nov 2011 12:50:26 -0500
Subject: Packets dropped passing from Qwest to Verizon
Message-ID: <48A01A9F-7E07-4CC3-B57D-F4D6E8E53E26@linode.com>

Hello,

I'm looking looking for a POC at Qwest (AS209) or Verizon (AS701) to help diagnose what looks like a stale bogon filter.  The packets drop where Qwest (63.146.26.210) peers with Verizon (152.63.2.130).  

Thanks in advance!

Regards,
Tim H.

From jgreco at ns.sol.net  Tue Nov 15 11:54:45 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Tue, 15 Nov 2011 11:54:45 -0600 (CST)
Subject: Arguing against using public IP space
In-Reply-To: <5CBF6B7A-D16E-487B-B70D-1F36B1CDBECB@delong.com>
Message-ID: <201111151754.pAFHsk4t094745@aurora.sol.net>

> On Nov 15, 2011, at 7:54 AM, Joe Greco wrote:
> >> If you put a router where you needed a firewall, then, this is not a =
> >> failure of the firewall, but, a
> >> failure of the network implementor and the address space will not have =
> >> any impact whatsoever
> >> on your lack of security.
> > 
> > And the difference between a router and a firewall is ...?
> > 
> > Apparently, one bit.
> 
> IMHO, a firewall does not route packets by default, but, rather only forwards
> those packets which match configured policies.
> 
> A router, OTOH, routes packets by default, but, may be configured with some
> policy about which packets to forward.
> 
> The difference functionally is what happens when the configuration is
> lost or corrupted. Essentially fail open vs. fail closed.

1 vs 0.  As I said... one bit.

Understanding this fundamental truth is helpful in understanding why
people use "routers" as "firewalls" and "firewalls" as "routers".
Because they're basically the same thing, with a one bit difference.

And some products, say like FreeBSD (which forms the heart of things
like pfSense, so let's not even begin to argue that it "isn't a
firewall") can actually be configured to default either way.  

So basically, while we would all prefer that firewalls default to deny,
it probably isn't as important a distinction as this thread is making
it out to be, because even a "default to deny" firewall fails when a
naive admin makes a typo and allows all traffic from 0/0 inadvertently.
It's just a matter of statistical likelihood.

Or perhaps a better argument would be that routers really ought to
default to deny.  :-)  I'd be fine with that, but I can hear the
screaming already.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From drais at icantclick.org  Tue Nov 15 12:02:28 2011
From: drais at icantclick.org (david raistrick)
Date: Tue, 15 Nov 2011 13:02:28 -0500 (EST)
Subject: Arguing against using public IP space
In-Reply-To: <201111151754.pAFHsk4t094745@aurora.sol.net>
References: <201111151754.pAFHsk4t094745@aurora.sol.net>
Message-ID: <alpine.BSF.2.00.1111151259270.76404@murf.icantclick.org>

On Tue, 15 Nov 2011, Joe Greco wrote:

> Or perhaps a better argument would be that routers really ought to
> default to deny.  :-)  I'd be fine with that, but I can hear the
> screaming already.

er.  you've forgotten "en; conf t; ip routing" to turn off the default "no 
ip routing" (or "no ip forwarding" is my memory, but my config archive 
says otherwise)

so we had default to deny in routers for a long time....


--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html



From rps at maine.edu  Tue Nov 15 12:32:48 2011
From: rps at maine.edu (Ray Soucy)
Date: Tue, 15 Nov 2011 13:32:48 -0500
Subject: Arguing against using public IP space
In-Reply-To: <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us>
 <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
 <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
Message-ID: <CALFTrnOeCm=GrY6JkBMftUTuF9GCMaGanY+SuhX8YpQT50yqHw@mail.gmail.com>

On Tue, Nov 15, 2011 at 5:57 AM, Leigh Porter
<leigh.porter at ukbroadband.com> wrote:
> As somebody else mentioned on this thread, a NAT box with private space on one side fails closed.

This is a myth; just like NAT provides security is a myth.

It doesn't matter if your firewall performs NAT or not; if it fails,
traffic will more than likely stop flowing.

The conditions for a non-NAT firewall to fail open are very specific.
You often need to engineer it to have that functionality.

Either type of firewall system can be designed to fail open or fail closed.




-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From Valdis.Kletnieks at vt.edu  Tue Nov 15 12:38:52 2011
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 15 Nov 2011 13:38:52 -0500
Subject: Arguing against using public IP space
In-Reply-To: Your message of "Tue, 15 Nov 2011 17:16:23 GMT."
 <56433BFF-2BDF-4C12-928F-B0C576047F24@ukbroadband.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
 <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
 <175192.1321366640@turing-police.cc.vt.edu>
 <001a01cca3a5$5efa1200$1cee3600$@com>
 <56433BFF-2BDF-4C12-928F-B0C576047F24@ukbroadband.com>
Message-ID: <9649.1321382332@turing-police.cc.vt.edu>

On Tue, 15 Nov 2011 17:16:23 GMT, Leigh Porter said:
> Quite right.. I bet all Iran's nuclear facilities have air gaps but they let
> people in with laptops and USB sticks.

And that's the point - *most* networks have so many bigger issues that the
whole "NAT makes us secure" mantra is dangerous self-delusion.

If you have machines in the NAT area where you're actually concerned that "ZOMG
the firewall might fail and expose them", why aren't they airgapped? As the
Iranians discovered, if the attacker gets a foothold inside the NAT you're
screwed anyhow, and *that* is probably a lot more likely scenario than a
fail-open firewall..



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111115/2f1b40bc/attachment.bin>

From jgreco at ns.sol.net  Tue Nov 15 12:56:10 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Tue, 15 Nov 2011 12:56:10 -0600 (CST)
Subject: Arguing against using public IP space
In-Reply-To: <alpine.BSF.2.00.1111151259270.76404@murf.icantclick.org>
Message-ID: <201111151856.pAFIuBFI095432@aurora.sol.net>

> On Tue, 15 Nov 2011, Joe Greco wrote:
> > Or perhaps a better argument would be that routers really ought to
> > default to deny.  :-)  I'd be fine with that, but I can hear the
> > screaming already.
> 
> er.  you've forgotten "en; conf t; ip routing" to turn off the default "no 
> ip routing" (or "no ip forwarding" is my memory, but my config archive 
> says otherwise)
> 
> so we had default to deny in routers for a long time....

My bad.

But seriously, now, I'm going to wander a bit far to make a point that
I hope people get.

In the '90's, during the rapid ISP growth era, one of the local policies
here was that all boxes should be protected by a competent on-box 
firewall.  The problem with this was that it was tough to implement in 
practice, since for the most part, boxes varied in interface 
configuration, etc., etc.  Writing a custom ruleset for each box was 
nearly prohibitive.

I also had clients where I saw similar problems.  You'd see all sorts of
pseudo-strange rulesets being written, and wildly differing policies about
things like ssh, etc., which made administration a challenge too.  But a
large percentage seemed to go firewall-free.  Bleh.

So as part of the standard build, I designed an automatic firewall script
that basically looked at the system IP configuration, derived reasonable
defaults, and then allowed an abstract policy to be specified, such as

TCP_ALLOW="80 443"

and the rest was automatic.  This may seem trivial to many of you, and I
will even concede that it *should* be, but the point is that by having
this installed by default, it made it MORE annoying to disable the
firewall than it was to create a simple configuration for it.  So suddenly
all servers built through the build scripts reliably had firewall rules
in place.  I know some readers here may still be using variations on those
scripts, and they've served us well over the years too.

Now I want to stress the point here:  It wasn't that there was this magic 
firewall script, because to be sure some engs still rolled their own for 
various reasons.  The point is that SOME firewall was going to be running.
And that's the desired result.

In any case, to bring the discussion home, I suspect that part of the
problem with routers and fw rules is that there's a lack of a "default to
being firewalled".  Because it's hard to do that and do it right without
also being so painful that an admin just installs a "pass all" rule to
get things working, and then forgets about it all.

Those of you who work for large service providers or enterprises and have
this all worked out - well, I'm not talking about you, of course.  You
have incentive and motivation to get this kind of thing working on your
fleets of a thousand routers.  Great.  But it's still a problem for many
others.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From michael at rancid.berkeley.edu  Tue Nov 15 13:22:06 2011
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Tue, 15 Nov 2011 11:22:06 -0800
Subject: Arguing against using public IP space
In-Reply-To: <CAP-guGVvaJbjBLdRWpNhv=TbQmJPPVbYOzFWwFdcMqK_AkceDA@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <4EC1B3D2.5060007@mompl.net>
 <CAP-guGVvaJbjBLdRWpNhv=TbQmJPPVbYOzFWwFdcMqK_AkceDA@mail.gmail.com>
Message-ID: <4EC2BBDE.1050508@rancid.berkeley.edu>

On 11/15/11 09:15, William Herrin wrote:
> On Mon, Nov 14, 2011 at 7:35 PM, Jeroen van Aart<jeroen at mompl.net>  wrote:
>> William Herrin wrote:
>>> If your machine is addressed with a globally routable IP, a trivial
>>> failure of your security apparatus leaves your machine addressable
>>> from any other host in the entire world which wishes to send it
>>
>> Isn't that the case with IPv6? That the IP is addressable from any host in
>> the entire (IPv6) world? And isn't that considered a good thing?
>
> Hi Jeroen,
>
> Yes, according to almost every application developer asked it's a good thing.
>
> Me? I'm not so sure. Historically, enterprises moved away from global
> addressability even when IP addresses were free, *before* address
> scarcity became an issue. There's a lesson in there somewhere and I'm
> not convinced it's that "they were dumb."

> And make no mistake: successful security is about layers, about DEPTH.
> You can seek layers from other sources but a shallow security process
> will tend to be easily breached.

Hi Bill:

I am not sure if the enterprises were dumb for doing private address 
space, but I have a few hints that they might have been. (E.g. there's a 
*lot* of RFC1918 space out there.  Why does the overwhelming majority 
use 192.168.0.0/24 or 192.168.1.0/24 or 10.0.0.0/24?)

But what definitely *is* dumb is are the following two axioms, at least 
one of which is expressed in the article:

1. You need NAT/private ip address space to have security.

2. Once you have NAT/private ip address space, you have security.

On the surface those axioms clearly violate your notion of security 
layers and they clearly violate common sense.  Yet we find them lurking 
just beneath the surface, including in the debate about the utility of 
IPv6 ULAs, as well as in the article.

michael


From michael at rancid.berkeley.edu  Tue Nov 15 13:27:58 2011
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Tue, 15 Nov 2011 11:27:58 -0800
Subject: Arguing against using public IP space
In-Reply-To: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
Message-ID: <4EC2BD3E.9000505@rancid.berkeley.edu>

On 11/13/11 07:36, Jason Lewis wrote:
> I don't want to start a flame war, but this article seems flawed to
> me.  It seems an IP is an IP.
>
> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>
> I think I could announce private IP space, so doesn't that make this
> argument invalid?  I've always looked at private IP space as more of a
> resource and management choice and not a security feature.

Really, the article doesn't make much sense.  The claim is that SCADA 
systems come with "public IP addresses by default" and that SCADA 
engineers are too ignorant of Internet security practices to know to 
re-configure them. First, the ignorance factor goes right back to the 
two axioms I mentioned in my reply to Bill.  If you aren't paying 
attention, then you don't have security, regardless of which IP address 
space you use.

Second, there's the point that the SCADA systems come with public IP 
addresses by default.  So what?  The article incorrectly confuses 
"public" IP addresses with "routable" IP addresses.  As an example, when 
I worked in the College of Chemistry at UC Berkeley, there was a lab 
with NMR machines that all came with public IP addresses by 
default--those of the manufacturer.  Of course, since the manufacturer 
was in Germany, and we were in the US those IP addresses weren't 
routable in our network.  Are SCADA systems similarly configured?  The 
article doesn't say if the manufacturers pre-configure addresses within 
the client's IP blocks or their own, or even 1.2.3.0/24.

If the manufacturer went to the trouble of configuring the system on 
routable IP addresses, then the SCADA engineer can easily specify which 
set of addresses.  If the manufacturer really does configure "public" IP 
addresses "by default" then it's unlikely that those "public" IP 
addresses are actually _routable_ on the network which is using the 
SCADA system.

Oh, and the article treats RFC1918 and RFC4193 is equivalent, which is 
WRONG WRONG WRONG!

michael



From owen at delong.com  Tue Nov 15 14:16:08 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 15 Nov 2011 12:16:08 -0800
Subject: Arguing against using public IP space
In-Reply-To: <CAP-guGVvaJbjBLdRWpNhv=TbQmJPPVbYOzFWwFdcMqK_AkceDA@mail.gmail.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <4EC1B3D2.5060007@mompl.net>
 <CAP-guGVvaJbjBLdRWpNhv=TbQmJPPVbYOzFWwFdcMqK_AkceDA@mail.gmail.com>
Message-ID: <971B1F8E-0B72-42E9-A9FD-FCD8DC4F7850@delong.com>


On Nov 15, 2011, at 9:15 AM, William Herrin wrote:

> On Mon, Nov 14, 2011 at 7:35 PM, Jeroen van Aart <jeroen at mompl.net> wrote:
>> William Herrin wrote:
>>> If your machine is addressed with a globally routable IP, a trivial
>>> failure of your security apparatus leaves your machine addressable
>>> from any other host in the entire world which wishes to send it
>> 
>> Isn't that the case with IPv6? That the IP is addressable from any host in
>> the entire (IPv6) world? And isn't that considered a good thing?
> 
> Hi Jeroen,
> 
> Yes, according to almost every application developer asked it's a good thing.
> 
> Me? I'm not so sure. Historically, enterprises moved away from global
> addressability even when IP addresses were free, *before* address
> scarcity became an issue. There's a lesson in there somewhere and I'm
> not convinced it's that "they were dumb."

I'm not sure how you can make that case since RFC-1918 and it's predecessors
RFC-1597 and RFC-1627 came after address scarcity was already a known
problem. The oldest of these three (RFC 1597 is dated March, 1994. IPv6
development (spurred by the fact that IPv4 addresses were becoming
scarce) started in earnest somewhere between 1990-1992 depending on
who you ask).

If your initial assertion were true, then, there might be some sort of lesson
from your follow-on statement. In this case, however, since the assertion
is false, the follow-on lesson is likely just that some enterprises jumped
on the NAT bandwagon sooner than others in pursuit of certain coolness
or other convenience factors unrelated to delivering a good internet
experience to their end users.

Also, since the internet was such a radically different thing back then
as compared to what it is now, I'm not sure that any such lesson
would inherently be useful in the modern age.

> 
> 
>> I don't think that being addressable from anywhere is a security hole in and
>> of itself. It's how you implement and (mis)configure your firewall and
>> related things that is the (potential) security hole. Whether the IP is
>> world addressable or not
> 
> I agree. That your computer is globally addressable is NOT a security
> hole. It does not directly or indirectly make you vulnerable to
> attack. But the inverse doesn't follow.
> 
> That your computer is not globally addressable ADDS one layer of
> security in a process you hope has enough layers to prevent an attack
> from penetrating.
> 

This statement is absurd. I can have a globally unique address on a
system that does not have any external connectivity. The fact that the
address is global in scope does not in any way make that system any
less secure than a system which uses an address that is not globally
unique.

Addressability is not reachability. Addressability has nothing to do with
security. Reachability has a little bit to do with security, but, in any sane
modern implementation, not a lot.

> And make no mistake: successful security is about layers, about DEPTH.
> You can seek layers from other sources but a shallow security process
> will tend to be easily breached.
> 


This is the only thing you've said here that I can actually agree with.
Given the penalties associated with non-global addressing and
the rewards available from global addressing combined with the
absolutely minimal protection afforded by non-global addressing,
I find it hard to imagine a scenario in which the benefits would
ever outweigh the costs.

Owen



From owen at delong.com  Tue Nov 15 14:23:26 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 15 Nov 2011 12:23:26 -0800
Subject: Arguing against using public IP space
In-Reply-To: <8B492826-660E-466A-A31D-11616E5805A4@ukbroadband.com>
References: <CA+buB7eG7z0kxh-UZgJqvE8pQqFwY3iRkS+Up7buCLqTi5Dctg@mail.gmail.com>
 <201111131638.pADGcoiu007448@mail.r-bonomi.com>
 <CAP-guGUBuvpNiUEe2c_rxa8CJJr-LM1ub0zEJrwsY-H0C5JJ1Q@mail.gmail.com>
 <20111113212756.GD73635@macbook.bluepipe.net>
 <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com>
 <20111113225924.GF73635@macbook.bluepipe.net>
 <002201cca25f$6c5340d0$44f9c270$@com>
 <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur>
 <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com>
 <F94EB274-D5AC-4018-927C-97E4F1114643@delong.com>
 <8B492826-660E-466A-A31D-11616E5805A4@ukbroadband.com>
Message-ID: <69ACE97A-D95A-4FE1-99DF-A4D88EFA016B@delong.com>


On Nov 15, 2011, at 9:14 AM, Leigh Porter wrote:

> 
> On 15 Nov 2011, at 15:36, "Owen DeLong" <owen at delong.com> wrote:
> 
>> 
>> On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote:
>> 
>>> 
>>> 
>>> On 14 Nov 2011, at 18:52, "McCall, Gabriel" <Gabriel.McCall at thyssenkrupp.com> wrote:
>>> 
>>>> Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet.
>>> 
>>> 
>>> Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure!
>>> 
>> This is not true.
>> 
>> If your firewall is not working, it should not be passing packets.
> 
> And of course, things always fail just the way we want them to.
> 

Your stateful firewall is no more likely to fail open than your header-mutilating
device.

>> 
>> If you put a router where you needed a firewall, then, this is not a failure of the firewall, but, a
>> failure of the network implementor and the address space will not have any impact whatsoever
>> on your lack of security.
> 
> This is not really a well made point, sorry. It's about a firewall failing, perhaps due to software error or hardware issue or because somebody failed to correctly configure a firewall rule. 
> 

The assertion I was countering is that a header-mangling device is inherently more secure than
a stateful firewall that does not mangle headers. I believe that the above paragraph addresses
the fact that both are equally likely to fail in an open manner. The problem I was primarily attempting
to convey is that many people confuse packet filtering routers for firewalls. Routers have many
ways in which they tend to fail open. Their default unconfigured mode is to pass all traffic.

This is not the case with a properly designed stateful firewall.

> The point about private space is that is forces security in a way in which public space and a firewall does not.
> 

And my point is that it does not actually do so. If your header-mutilating device breaks or is
badly designed or misconfigured, it is just as likely to pass traffic to your private-addressed
internal hosts as a badly designed or misconfigured firewall. The only difference is the
trivial difference in what it takes to get said traffic to the appliance in question.

> With private space, you are forces to explicitly configure NAT holes or VPN connections whereas with public space your boxes by default are accessible by the whole Internet. By default, on a private space network, nothing can get to it.
> 

Or deliver packets already addressed to the internal host to the external mac address of
the header-mutilating device, or own the internal host through other means and have it
create a tunnel which the header-mutilating device happily mistakes for a permitted
stateful outbound flow, or...

I realize you like to live in this fantasy land where private space makes things more secure
because it allows you to be lazy about your security posture in other areas. This is a common
fallacy that is well liked by many an IT department in the world.

It's still a fallacy, and, arguably one that has systematically reduced security overall.

> 
> 
>> 
>>> As somebody else mentioned on this thread, a NAT box with private space on one side fails closed.
>>> 
>> 
>> So does a firewall.
> 
> If it fails just how you want it to.
> 

If the firewall's default state is don't forward anything, the likelihood of it failing closed
is just as high as the theoretical likelihood that a header-mutilating device will do so.
In fact, arguably more so.

Owen



From jra at baylink.com  Tue Nov 15 14:55:42 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 15 Nov 2011 15:55:42 -0500 (EST)
Subject: Arguing against using public IP space
In-Reply-To: <175192.1321366640@turing-police.cc.vt.edu>
Message-ID: <4025227.2911.1321390542053.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Valdis Kletnieks" <Valdis.Kletnieks at vt.edu>

> And this is totally overlooking the fact that the vast majority of *actual*
> attacks these days are web-based drive-bys and similar things that most
> firewalls are configured to pass through. Think about it - if a NAT'ed
> firewall provides any real protection against real attacks, why are there still
> so many zombied systems out there? I mean, Windows Firewall has been shipping
> with inbound "default deny" since XP SP2 or so. How many years ago was that?
> And what *real* security over and above that host-based firewall are you
> getting from that appliance?
> 
> Or as Dr Phil would say "FIrewalls - how is that working out for you?"

Do you have actual honest-to-ghod numbers, Valdis?

And aren't you making here the same assumption for which we chastise people
who run DNS resolvers that wildcard to advertising pages for NXDOMAIN:

That all the world's a workstation?

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From jra at baylink.com  Tue Nov 15 15:10:32 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 15 Nov 2011 16:10:32 -0500 (EST)
Subject: Arguing against using public IP space
In-Reply-To: <F94EB274-D5AC-4018-927C-97E4F1114643@delong.com>
Message-ID: <30335127.2913.1321391432299.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Owen DeLong" <owen at delong.com>

> If your firewall is not working, it should not be passing packets.

Yes; your arguments all seem to depend on that property being true.

But we call it a *failure* for a reason, Owen.  

What the probability is of a firewall failing in such a fashion as to *stop
filtering, but still pass packets* depends -- as you have pointed out -- 
entirely on its design.

As *I* have pointed out, not all firewalls are created equal, and there are
a helluva a lot of them out there for which this desirable property *simply
is not true*.

Sticking your head in the sand on this point is not especially productive.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From jra at baylink.com  Tue Nov 15 15:16:12 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 15 Nov 2011 16:16:12 -0500 (EST)
Subject: Have they stopped teaching Defense in Depth?
In-Reply-To: <CAP-guGVvaJbjBLdRWpNhv=TbQmJPPVbYOzFWwFdcMqK_AkceDA@mail.gmail.com>
Message-ID: <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "William Herrin" <bill at herrin.us>

> That your computer is not globally addressable ADDS one layer of
> security in a process you hope has enough layers to prevent an attack
> from penetrating.
> 
> And make no mistake: successful security is about layers, about DEPTH.
> You can seek layers from other sources but a shallow security process
> will tend to be easily breached.

This is precisely the point I've been trying to make, and it ties in to my
observations in response in the SCADA thread: not only does the number of
layers matter, so does their "thickness".  Certainly, if you're trying to
"air-gap" a SCADA network to protect it from attack, then you are admitting
a certain degree of vulnerability if your circuit passes through any sort of
transport multiplexer, like a DACS, as that's a place an attacker could
reconfigure to take control of your traffic.

But mounting *that* attack requires insider knowledge of 4 or 5 layers of 
extra information which will be necessary to exploit such an attack.

My estimation is that that makes that layer of your defense in depth "thicker"
than some other layers might be.

Those who think NAT provides no security seem still to be mounting the strawman
that we think it *provides* security, rather than merely contributing some bits
thereto...


Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From jra at baylink.com  Tue Nov 15 15:19:29 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 15 Nov 2011 16:19:29 -0500 (EST)
Subject: Arguing against using public IP space
In-Reply-To: <201111151754.pAFHsk4t094745@aurora.sol.net>
Message-ID: <3759251.2917.1321391969507.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Joe Greco" <jgreco at ns.sol.net>

> And some products, say like FreeBSD (which forms the heart of things
> like pfSense, so let's not even begin to argue that it "isn't a
> firewall") can actually be configured to default either way.

By Owen's definition, it's not.

> So basically, while we would all prefer that firewalls default to deny,
> it probably isn't as important a distinction as this thread is making
> it out to be, because even a "default to deny" firewall fails when a
> naive admin makes a typo and allows all traffic from 0/0
> inadvertently. It's just a matter of statistical likelihood.
> 
> Or perhaps a better argument would be that routers really ought to
> default to deny. :-) I'd be fine with that, but I can hear the
> screaming already.

But you're missing an important point here, Joe: we're not talking about
default configuration... we're talking about *failure modes*, which are by
definition unpredictable.

All you can really do there is figure the probabilities... and the probability
is that a *router-based* firewall (which as you and I agree, is a helluva lot
of firewalls) will *be more likely* to fail into pass traffic mode than into
don't pass traffic mode.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From jra at baylink.com  Tue Nov 15 15:23:04 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 15 Nov 2011 16:23:04 -0500 (EST)
Subject: Arguing against using public IP space
In-Reply-To: <69ACE97A-D95A-4FE1-99DF-A4D88EFA016B@delong.com>
Message-ID: <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Owen DeLong" <owen at delong.com>


> >> If your firewall is not working, it should not be passing packets.
> >
> > And of course, things always fail just the way we want them to.
> 
> Your stateful firewall is no more likely to fail open than your
> header-mutilating device.

Please show your work.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From owen at delong.com  Tue Nov 15 15:45:11 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 15 Nov 2011 16:45:11 -0500
Subject: Arguing against using public IP space
In-Reply-To: <30335127.2913.1321391432299.JavaMail.root@benjamin.baylink.com>
References: <30335127.2913.1321391432299.JavaMail.root@benjamin.baylink.com>
Message-ID: <E303F5E0-FBA2-4B11-A432-F1E5834E8667@delong.com>



Sent from my iPad

On Nov 15, 2011, at 4:10 PM, Jay Ashworth <jra at baylink.com> wrote:

> ----- Original Message -----
>> From: "Owen DeLong" <owen at delong.com>
> 
>> If your firewall is not working, it should not be passing packets.
> 
> Yes; your arguments all seem to depend on that property being true.
> 
> But we call it a *failure* for a reason, Owen.  

If your firewall has failed to such an extent, all bets are off about what it does or does not pas regardless of whether or not it mutilates the headers.

> 
> What the probability is of a firewall failing in such a fashion as to *stop
> filtering, but still pass packets* depends -- as you have pointed out -- 
> entirely on its design.
> 
> As *I* have pointed out, not all firewalls are created equal, and there are
> a helluva a lot of them out there for which this desirable property *simply
> is not true*.

Then I would, by definition call them routers, not firewalls.

> 
> Sticking your head in the sand on this point is not especially productive.

I'm not sticking my head in the sand about anything. I am pointing out that mutilating the packet header only reduces security. It does not improve it.

Owen



From marka at isc.org  Tue Nov 15 15:50:55 2011
From: marka at isc.org (Mark Andrews)
Date: Wed, 16 Nov 2011 08:50:55 +1100
Subject: Have they stopped teaching Defense in Depth?
In-Reply-To: Your message of "Tue, 15 Nov 2011 16:16:12 CDT."
 <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com>
References: <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com>
Message-ID: <20111115215055.72C851737568@drugs.dv.isc.org>


In message <33284158.2915.1321391772464.JavaMail.root at benjamin.baylink.com>, Jay Ashworth write
s:
> ----- Original Message -----
> > From: "William Herrin" <bill at herrin.us>
> 
> > That your computer is not globally addressable ADDS one layer of
> > security in a process you hope has enough layers to prevent an attack
> > from penetrating.
> > 
> > And make no mistake: successful security is about layers, about DEPTH.
> > You can seek layers from other sources but a shallow security process
> > will tend to be easily breached.
> 
> This is precisely the point I've been trying to make, and it ties in to my
> observations in response in the SCADA thread: not only does the number of
> layers matter, so does their "thickness".  Certainly, if you're trying to
> "air-gap" a SCADA network to protect it from attack, then you are admitting
> a certain degree of vulnerability if your circuit passes through any sort of
> transport multiplexer, like a DACS, as that's a place an attacker could
> reconfigure to take control of your traffic.
> 
> But mounting *that* attack requires insider knowledge of 4 or 5 layers of 
> extra information which will be necessary to exploit such an attack.
> 
> My estimation is that that makes that layer of your defense in depth "thicker"
> than some other layers might be.
> 
> Those who think NAT provides no security seem still to be mounting the strawman
> that we think it *provides* security, rather than merely contributing some bits
> thereto...

Most of us actually think that what ever benefit it adds over a
firewall is miniscule compared to its negative consequences and
once the cost benefit analysis is done that it is not worth it.
Remember the cost of NAT is not solely borne by the entity deploying
the NAT.  If it was there would be little debate here.  The cost
of you deploying NAT is borne by everyone of us.  It add a little
bit to the cost of every router.

If you want to use unroutable addresses then use a bastion host /
proxy.  Don't expect to be able to open a TCP socket and have it
connect to something on the outside.  Do it right or don't do it
at all.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From bill at herrin.us  Tue Nov 15 16:01:09 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 15 Nov 2011 17:01:09 -0500
Subject: Have they stopped teaching Defense in Depth?
In-Reply-To: <20111115215055.72C851737568@drugs.dv.isc.org>
References: <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com>
 <20111115215055.72C851737568@drugs.dv.isc.org>
Message-ID: <CAP-guGWW4kmyB5xE+8Q_EXqoEZf4Qm5OUOn+r7_U_gumfpd0pA@mail.gmail.com>

On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews <marka at isc.org> wrote:
> If you want to use unroutable addresses then use a bastion host /
> proxy. ?Don't expect to be able to open a TCP socket and have it
> connect to something on the outside. ?Do it right or don't do it
> at all.

Mark,

What is a modern NAT but a bastion host proxy for which application
compatibility has been maximized?

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jgreco at ns.sol.net  Tue Nov 15 16:13:32 2011
From: jgreco at ns.sol.net (Joe Greco)
Date: Tue, 15 Nov 2011 16:13:32 -0600 (CST)
Subject: Arguing against using public IP space
In-Reply-To: <3759251.2917.1321391969507.JavaMail.root@benjamin.baylink.com>
Message-ID: <201111152213.pAFMDWZh097519@aurora.sol.net>

> ----- Original Message -----
> > From: "Joe Greco" <jgreco at ns.sol.net>
> 
> > And some products, say like FreeBSD (which forms the heart of things
> > like pfSense, so let's not even begin to argue that it "isn't a
> > firewall") can actually be configured to default either way.
> 
> By Owen's definition, it's not.

Then Owen's definition is wrong, because the vast majority of "firewall"
devices out there are software-based devices.

> > So basically, while we would all prefer that firewalls default to deny,
> > it probably isn't as important a distinction as this thread is making
> > it out to be, because even a "default to deny" firewall fails when a
> > naive admin makes a typo and allows all traffic from 0/0
> > inadvertently. It's just a matter of statistical likelihood.
> > 
> > Or perhaps a better argument would be that routers really ought to
> > default to deny. :-) I'd be fine with that, but I can hear the
> > screaming already.
> 
> But you're missing an important point here, Joe: we're not talking about
> default configuration... we're talking about *failure modes*, which are by
> definition unpredictable.

But I'm *not* missing the point.  You missed mine.  The fact of the 
matter is that routers don't come with firewall-by-default, we've 
failed to find ways to make it easier for people to firewall things 
properly than it is to open the gates.  Or even notice that their 
gates are wide open.  That's a problem.

> All you can really do there is figure the probabilities... and the probability
> is that a *router-based* firewall (which as you and I agree, is a helluva lot
> of firewalls) will *be more likely* to fail into pass traffic mode than into
> don't pass traffic mode.

That depends on too many factors to really be able to make that call.
On the equally cutting side for NAT proponents, there are some attacks
against NAT devices that often succeed that shouldn't.

I'm not trying to defend the firewall thing.  That discussion is boring
and dull, it's about the state of one bit, as I pointed out, which is
the NANOG equivalent of how many angels can dance on the head of a pin.
I was merely taking what seemed to be a good opportunity to point out
that there's a more abstract failing here, which is that we have failed
to make it easy to firewall by default.  I don't mean "default to
blocking packets."  I mean that we've failed to make it easy for router
owners to do abstract things like say "this network's a bunch of
clients, and should be statefully firewalled for outbound connections
only" and make it as easy (or easier) to do that than it is to open
the connection wide open.  Failing to put roadblocks in place where
you could have roadblocks makes a network easier to penetrate.  But I
think I've made my point.

The obvious, real, clear problem with many SCADA networks is that 
they're built out of garbage, with garbage software stacks, with no
apparent thought given to security.  On the Internet, we've typically
dealt with that sort of stuff by beating it senseless (open SMTP relay,
etc) and then replacing it.  Adding layers to protect the "soft gooey
center", as someone put it, helps, of course, but is only a band-aid
solution.

Who here would go passwordless on their OOB management network?  

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From tayeb.meftah at gmail.com  Mon Nov 14 14:51:07 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Mon, 14 Nov 2011 22:51:07 +0200
Subject: OpenSource IPTV and VoD Solution
Message-ID: <EF973041EE95421DBA1CAD4DF7A32307@work>

Hello Guys
i'm looking for a solution to stream diferent DVB transponders through RTSP
VLC look like complicated a bit
i use MumuDVB for Multicasting
but i didn't found anything for RTSP
any help Would by welcome
thank you
    Meftah Tayeb
IT Consulting
http://www.tmvoip.com/ 
phone: +21321656139
Mobile: +213660347746


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6633 (20111115) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


From galu at packetdam.com  Tue Nov 15 17:28:42 2011
From: galu at packetdam.com (Vlad Galu)
Date: Tue, 15 Nov 2011 23:28:42 +0000
Subject: OpenSource IPTV and VoD Solution
In-Reply-To: <EF973041EE95421DBA1CAD4DF7A32307@work>
References: <EF973041EE95421DBA1CAD4DF7A32307@work>
Message-ID: <5435AB89-62D4-425B-BAB2-BC0FAE7604BB@packetdam.com>

Have a look at RTMPD [1]. Although it is mainly RTMP, it supports RTSP.

[1] http://www.rtmpd.com

On Nov 14, 2011, at 8:51 PM, Meftah Tayeb wrote:

> Hello Guys
> i'm looking for a solution to stream diferent DVB transponders through RTSP
> VLC look like complicated a bit
> i use MumuDVB for Multicasting
> but i didn't found anything for RTSP
> any help Would by welcome
> thank you
>    Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/ 
> phone: +21321656139
> Mobile: +213660347746
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6633 (20111115) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 

--
PacketDam: a cost-effective
software solution against DDoS
http://www.packetdam.com






From tayeb.meftah at gmail.com  Mon Nov 14 16:25:18 2011
From: tayeb.meftah at gmail.com (Meftah Tayeb)
Date: Tue, 15 Nov 2011 00:25:18 +0200
Subject: OpenSource IPTV and VoD Solution
References: <EF973041EE95421DBA1CAD4DF7A32307@work>
 <5435AB89-62D4-425B-BAB2-BC0FAE7604BB@packetdam.com>
Message-ID: <7D02F35711B04FE8AEE7FEAB3B127C08@work>

thank you for that
is a rtsp server no problem
but how do i stream Live DVB traffic through it ?
Thank you

----- Original Message ----- 
From: "Vlad Galu" <galu at packetdam.com>
To: "Meftah Tayeb" <tayeb.meftah at gmail.com>
Cc: <nanog at nanog.org>
Sent: Wednesday, November 16, 2011 1:28 AM
Subject: Re: OpenSource IPTV and VoD Solution


Have a look at RTMPD [1]. Although it is mainly RTMP, it supports RTSP.

[1] http://www.rtmpd.com

On Nov 14, 2011, at 8:51 PM, Meftah Tayeb wrote:

> Hello Guys
> i'm looking for a solution to stream diferent DVB transponders through 
> RTSP
> VLC look like complicated a bit
> i use MumuDVB for Multicasting
> but i didn't found anything for RTSP
> any help Would by welcome
> thank you
>    Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/
> phone: +21321656139
> Mobile: +213660347746
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature database 6633 (20111115) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>

--
PacketDam: a cost-effective
software solution against DDoS
http://www.packetdam.com






__________ Information from ESET NOD32 Antivirus, version of virus signature 
database 6633 (20111115) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




__________ Information from ESET NOD32 Antivirus, version of virus signature database 6633 (20111115) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





From marka at isc.org  Tue Nov 15 19:20:29 2011
From: marka at isc.org (Mark Andrews)
Date: Wed, 16 Nov 2011 12:20:29 +1100
Subject: Arguing against using public IP space
In-Reply-To: Your message of "Tue, 15 Nov 2011 16:23:04 CDT."
 <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com>
References: <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com>
Message-ID: <20111116012029.66D99173B09C@drugs.dv.isc.org>


In message <29838609.2919.1321392184239.JavaMail.root at benjamin.baylink.com>, Ja
y Ashworth writes:
> > >> If your firewall is not working, it should not be passing packets.
> > >
> > > And of course, things always fail just the way we want them to.
> > 
> > Your stateful firewall is no more likely to fail open than your
> > header-mutilating device.
> 
> Please show your work.

Prove to me that all NAT won't pass packets not addressed directly
to it.  Show your work.

You are making assumptions about how the NAT is designed.  Many
NATs only take packets addressed to particular address ranges and
process them though the state tables.  All the rest of the packets
are treated as normal traffic which may or may not be forwarded
depending apon the way the base platform is configured which is
usually as a router.  Many NAT's will honour LSR.

Unless you know the internals of a NAT you cannot say whether it
fails open or closed.

Given that most NATs only use a small set of address on the inside
it is actually feasible to probe through a NAT using LSR.  Most
attacks don't do this as there are lots of lower hanging fruit but
if it is a targeted attack then yes you can expect to see LSR based
attacks which depending apon how the NAT is built may pass through
it without even being noticed.

Now can we put to bed that NAT provides any real security.  If you
want security add and configure a firewall.  That firewall can be
in the same box as the NAT.  It can use the same state tables as
the NAT but it is the firewall, not the NAT functionality, that
provides the protection.

Mark

> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.co
> m
> Designer                     The Things I Think                       RFC 210
> 0
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DI
> I
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 127
> 4
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From kauer at biplane.com.au  Tue Nov 15 20:07:56 2011
From: kauer at biplane.com.au (Karl Auer)
Date: Wed, 16 Nov 2011 13:07:56 +1100
Subject: Arguing against using public IP space
In-Reply-To: <20111116012029.66D99173B09C@drugs.dv.isc.org>
References: <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com>
 <20111116012029.66D99173B09C@drugs.dv.isc.org>
Message-ID: <1321409276.2514.251.camel@karl>

On Wed, 2011-11-16 at 12:20 +1100, Mark Andrews wrote:
> You are making assumptions about how the NAT is designed.
> [...]
> Unless you know the internals of a NAT you cannot say whether it
> fails open or closed.

Indeed not!

From 2010, during an identical discussion:

   http://seclists.org/nanog/2010/Apr/1166

To me, "fail" means that a system stops doing what it was designed to
do. The results are by definition undefined. Others seem to think that
"fail" means a kind of default.

> it is actually feasible to probe through a NAT using LSR.

What's LSR in this context? Loose source routing, I'm guessing.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111116/b40568c4/attachment.bin>

From bill at herrin.us  Tue Nov 15 20:44:20 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 15 Nov 2011 21:44:20 -0500
Subject: Arguing against using public IP space
In-Reply-To: <20111116012029.66D99173B09C@drugs.dv.isc.org>
References: <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com>
 <20111116012029.66D99173B09C@drugs.dv.isc.org>
Message-ID: <CAP-guGXXM_Dci6QrzR2AQmFOnKh0AFs2XdVVY-H-MPDXcRrLBw@mail.gmail.com>

On Tue, Nov 15, 2011 at 8:20 PM, Mark Andrews <marka at isc.org> wrote:
> Given that most NATs only use a small set of address on the inside
> it is actually feasible to probe through a NAT using LSR.
> Most attacks don't do this as there are lots of lower hanging fruit

Mark,

My car can be slim-jimmed. Yet the lock is sufficiently operative in
the security process that the two times the vehicle has been broken in
to the vagrant put a rock through the window instead of jimmying the
lock.

That's what it MEANS when you say that there's lower hanging fruit to
be found elsewhere. It means that the feature you're describing is
operative in the process of obstructing an attacker.



As an aside to the debate, I boldly suggest that any firewall vendor
which actually implements LSR or any of the IP source route
functionality anywhere in their code deserves to be tarred and
feathered. The security implications of source routing have been long
understood. Code which implements source routing has no business
existing in a commercial firewall product where it could accidentally
be called. Please, by all means, take this opportunity to out any such
errors which you can document.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From marka at isc.org  Tue Nov 15 21:07:19 2011
From: marka at isc.org (Mark Andrews)
Date: Wed, 16 Nov 2011 14:07:19 +1100
Subject: Arguing against using public IP space
In-Reply-To: Your message of "Tue, 15 Nov 2011 21:44:20 CDT."
 <CAP-guGXXM_Dci6QrzR2AQmFOnKh0AFs2XdVVY-H-MPDXcRrLBw@mail.gmail.com>
References: <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com>
 <20111116012029.66D99173B09C@drugs.dv.isc.org>
 <CAP-guGXXM_Dci6QrzR2AQmFOnKh0AFs2XdVVY-H-MPDXcRrLBw@mail.gmail.com>
Message-ID: <20111116030719.93485173BD2E@drugs.dv.isc.org>


In message <CAP-guGXXM_Dci6QrzR2AQmFOnKh0AFs2XdVVY-H-MPDXcRrLBw at mail.gmail.com>
, William Herrin writes:
> On Tue, Nov 15, 2011 at 8:20 PM, Mark Andrews <marka at isc.org> wrote:
> > Given that most NATs only use a small set of address on the inside
> > it is actually feasible to probe through a NAT using LSR.
> > Most attacks don't do this as there are lots of lower hanging fruit
> 
> Mark,
> 
> My car can be slim-jimmed. Yet the lock is sufficiently operative in
> the security process that the two times the vehicle has been broken in
> to the vagrant put a rock through the window instead of jimmying the
> lock.
> 
> That's what it MEANS when you say that there's lower hanging fruit to
> be found elsewhere. It means that the feature you're describing is
> operative in the process of obstructing an attacker.
> 
> As an aside to the debate, I boldly suggest that any firewall vendor
> which actually implements LSR or any of the IP source route
> functionality anywhere in their code deserves to be tarred and
> feathered. The security implications of source routing have been long
> understood. Code which implements source routing has no business
> existing in a commercial firewall product where it could accidentally
> be called. Please, by all means, take this opportunity to out any such
> errors which you can document.

Indeed.

A NAT mangles packets.  A firewall provides protection.  You can
combine the two but expecting one to do the job of the other is
just wrong and doesn't work.

> Regards,
> Bill Herrin
> 
> 
> --=20
> William D. Herrin ................ herrin at dirtside.com=A0 bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From jra at baylink.com  Tue Nov 15 21:08:29 2011
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 15 Nov 2011 22:08:29 -0500 (EST)
Subject: Arguing against using public IP space
In-Reply-To: <20111116012029.66D99173B09C@drugs.dv.isc.org>
Message-ID: <28327223.2951.1321412909463.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Mark Andrews" <marka at isc.org>

> In message
> <29838609.2919.1321392184239.JavaMail.root at benjamin.baylink.com>, Ja
> y Ashworth writes:
> > > >> If your firewall is not working, it should not be passing
> > > >> packets.
> > > >
> > > > And of course, things always fail just the way we want them to.
> > >
> > > Your stateful firewall is no more likely to fail open than your
> > > header-mutilating device.
> >
> > Please show your work.
> 
> Prove to me that all NAT won't pass packets not addressed directly
> to it. Show your work.

I did not *assert* that.  So I don't have to prove that. 

What I *asserted* was that inbound 1:N DNAT *reduces the probability of 
an attacker being able to target a specific inbound attack to a specific 
computer*.  QED.

> You are making assumptions about how the NAT is designed. Many
> NATs only take packets addressed to particular address ranges and
> process them though the state tables. All the rest of the packets
> are treated as normal traffic which may or may not be forwarded
> depending apon the way the base platform is configured which is
> usually as a router. Many NAT's will honour LSR.

As someone pointed out elsewhere, that's bad, but it's bad whether the box
does NAT or not; even if the internal network is unrouted public space,
that would be troublesome.

> Unless you know the internals of a NAT you cannot say whether it
> fails open or closed.

It's probably impossible to determine whether any box's response to
any failure will be pass or drop, with any reliability.  All you can
figure is probabilities.
 
> Given that most NATs only use a small set of address on the inside
> it is actually feasible to probe through a NAT using LSR. Most
> attacks don't do this as there are lots of lower hanging fruit but
> if it is a targeted attack then yes you can expect to see LSR based
> attacks which depending apon how the NAT is built may pass through
> it without even being noticed.

Someone else has already addressed "low-hanging fruit", so I won't.  I do 
concur, though: if you have specific examples of boxes which, as you allege, 
respect LSR to 1918 internal addresses, please, name and shame.
 
> Now can we put to bed that NAT provides any real security. If you
> want security add and configure a firewall. That firewall can be
> in the same box as the NAT. It can use the same state tables as
> the NAT but it is the firewall, not the NAT functionality, that
> provides the protection.

Nope; I'm afraid we still can't.  As long as you continue to strawman that
I/we are even *alleging* that NAT "provides" security (rather than 
"contributing" to it, we're just going to keep talking past each other, Mark.

As long as you keep defining protection as "one thing in one place", I'll
keep assuming you're flapping your jaws to dry your teeth. ("provides *the*
protection")

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From marka at isc.org  Tue Nov 15 22:54:15 2011
From: marka at isc.org (Mark Andrews)
Date: Wed, 16 Nov 2011 15:54:15 +1100
Subject: Arguing against using public IP space
In-Reply-To: Your message of "Tue, 15 Nov 2011 22:08:29 CDT."
 <28327223.2951.1321412909463.JavaMail.root@benjamin.baylink.com>
References: <28327223.2951.1321412909463.JavaMail.root@benjamin.baylink.com>
Message-ID: <20111116045415.960C4173C5E3@drugs.dv.isc.org>


In message <28327223.2951.1321412909463.JavaMail.root at benjamin.baylink.com>, Ja
y Ashworth writes:
> ----- Original Message -----
> > From: "Mark Andrews" <marka at isc.org>
> 
> > In message
> > <29838609.2919.1321392184239.JavaMail.root at benjamin.baylink.com>, Ja
> > y Ashworth writes:
> > > > >> If your firewall is not working, it should not be passing
> > > > >> packets.
> > > > >
> > > > > And of course, things always fail just the way we want them to.
> > > >
> > > > Your stateful firewall is no more likely to fail open than your
> > > > header-mutilating device.
> > >
> > > Please show your work.
> > 
> > Prove to me that all NAT won't pass packets not addressed directly
> > to it. Show your work.
> 
> I did not *assert* that.  So I don't have to prove that. 
> 
> What I *asserted* was that inbound 1:N DNAT *reduces the probability of 
> an attacker being able to target a specific inbound attack to a specific 
> computer*.  QED.
> 
> > You are making assumptions about how the NAT is designed. Many
> > NATs only take packets addressed to particular address ranges and
> > process them though the state tables. All the rest of the packets
> > are treated as normal traffic which may or may not be forwarded
> > depending apon the way the base platform is configured which is
> > usually as a router. Many NAT's will honour LSR.
> 
> As someone pointed out elsewhere, that's bad, but it's bad whether the box
> does NAT or not; even if the internal network is unrouted public space,
> that would be troublesome.

Actually LSR is not bad in and of itself.  The actual problem was
badly designed firewall code that failed properly examine the LSR
option.  Rather than fix the firewall code people choose to drop
packets with LSR options.

> > Unless you know the internals of a NAT you cannot say whether it
> > fails open or closed.
> 
> It's probably impossible to determine whether any box's response to
> any failure will be pass or drop, with any reliability.  All you can
> figure is probabilities.
>  
> > Given that most NATs only use a small set of address on the inside
> > it is actually feasible to probe through a NAT using LSR. Most
> > attacks don't do this as there are lots of lower hanging fruit but
> > if it is a targeted attack then yes you can expect to see LSR based
> > attacks which depending apon how the NAT is built may pass through
> > it without even being noticed.
> 
> Someone else has already addressed "low-hanging fruit", so I won't.  I do 
> concur, though: if you have specific examples of boxes which, as you allege, 
> respect LSR to 1918 internal addresses, please, name and shame.

Why do they need to be "named and shamed"?  They are NOT firewalls.  It
is not their job to block LSR traffic.  The fact that you think NATs
should be doing this is yet another indication that you don't understand
the difference between a NAT and a firewall.
  
> > Now can we put to bed that NAT provides any real security. If you
> > want security add and configure a firewall. That firewall can be
> > in the same box as the NAT. It can use the same state tables as
> > the NAT but it is the firewall, not the NAT functionality, that
> > provides the protection.
> 
> Nope; I'm afraid we still can't.  As long as you continue to strawman that
> I/we are even *alleging* that NAT "provides" security (rather than 
> "contributing" to it, we're just going to keep talking past each other, Mark.
> 
> As long as you keep defining protection as "one thing in one place", I'll
> keep assuming you're flapping your jaws to dry your teeth. ("provides *the*
> protection")
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.co
> m
> Designer                     The Things I Think                       RFC 210
> 0
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DI
> I
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 127
> 4
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From galu at packetdam.com  Tue Nov 15 23:18:04 2011
From: galu at packetdam.com (Vlad Galu)
Date: Wed, 16 Nov 2011 05:18:04 +0000
Subject: OpenSource IPTV and VoD Solution
In-Reply-To: <7D02F35711B04FE8AEE7FEAB3B127C08@work>
References: <EF973041EE95421DBA1CAD4DF7A32307@work>
 <5435AB89-62D4-425B-BAB2-BC0FAE7604BB@packetdam.com>
 <7D02F35711B04FE8AEE7FEAB3B127C08@work>
Message-ID: <524AFED3-C49A-417D-996A-5A9579421608@packetdam.com>


On Nov 14, 2011, at 10:25 PM, Meftah Tayeb wrote:

> thank you for that
> is a rtsp server no problem
> but how do i stream Live DVB traffic through it ?
> Thank you
> 

To be honest I haven't followed its development closely lately (although I contribute occasionally with
networking related patches and improvements) so I can't answer that, but you should be able to send
your stream to RTMPD using either MumuDVB or VLC, then demux it to as many (hundreds or even
thousands, it is *that* good) clients as you need.

I should have pointed you to the wiki  [1] and the mailing list [2], sorry.

HTH.

[1] http://wiki.rtmpd.com/
[2] http://groups.google.com/group/c-rtmp-server?pli=1

--
PacketDam: a cost-effective
software solution against DDoS
http://www.packetdam.com






From lorell at hathcock.org  Tue Nov 15 23:21:05 2011
From: lorell at hathcock.org (Lorell Hathcock)
Date: Tue, 15 Nov 2011 23:21:05 -0600
Subject: FW: Savvis broken link / underperforming between DC and Atlanta?
Message-ID: <000001cca41f$8a912050$9fb360f0$@hathcock.org>

All:

 

I did not see a reply to this.  Anyone else having a problem on this link?

 

Lorell

 

From: Lorell Hathcock [mailto:lorell at hathcock.org] 
Sent: Friday, November 11, 2011 9:10 AM
To: nanog at nanog.org
Subject: Savvis broken link / underperforming between DC and Atlanta?

 

Any one else seeing this?

 

This was done yesterday from Hawaii.

 

tracert speedtest.saas.infor.com

  3     5 ms     5 ms     4 ms  ip64-75-240-210.aloha.net [64.75.240.210]

  4     5 ms     5 ms     5 ms  hnl-edge-02.inet.qwest.net [67.129.94.69]

  5     *        *        *     Request timed out.

  6    56 ms    56 ms    56 ms  63-235-40-18.dia.static.qwest.net
[63.235.40.18]

  7    58 ms    58 ms    59 ms  cr1-tenge-0-3-5-0.sanfrancisco.savvis.net
[204.70.200.198]

  8   138 ms   138 ms   138 ms  cr1-bundle-pos2.Washington.savvis.net
[204.70.200.90]

  9   135 ms   136 ms   136 ms  hr1-tengig-2-0-0.sterling2dc2.savvis.net
[204.70.197.74]

10   139 ms   136 ms   137 ms  165.193.78.106

11     *        *        *     Request timed out.

12     *        *        *     Request timed out.

13     *        *        *     Request timed out.

 

But from Houston it was fine yesterday.   It took a different route.

 

Today I have the same problem from Houston.

 

tracert speedtest.saas.infor.com

  4     2 ms     2 ms     2 ms  te4-1.3509.ccr01.iah02.atlas.cogentco.com
[66.28.6.21]

  5     3 ms     2 ms     2 ms  te0-2-0-4.ccr21.iah01.atlas.cogentco.com
[154.54.3.149]

  6     9 ms    10 ms     8 ms  te0-1-0-5.ccr21.dfw01.atlas.cogentco.com
[154.54.2.225]

  7     8 ms     8 ms     8 ms  te7-3.mpd01.dfw03.atlas.cogentco.com
[154.54.6.66]

  8    15 ms     8 ms    12 ms  aer1-ge-4-2.dallasequinix.savvis.net
[208.175.175.5]

  9    17 ms     8 ms    15 ms  204.70.207.182

10    10 ms     9 ms    10 ms  cr1-tengig0-7-5-0.Dallas.savvis.net
[204.70.200.170]

11    37 ms    37 ms    37 ms  cr1-tengig-0-7-0-0.Washington.savvis.net
[204.70.196.105]

12    36 ms    36 ms    36 ms  hr1-tengig-2-0-0.sterling2dc2.savvis.net
[204.70.197.74]

13    37 ms    36 ms    37 ms  165.193.78.106

14     *        *        *     Request timed out.

15     *        *        *     Request timed out.

16     *        *        *     Request timed out.

 

This the end IP address is in Rackspace in Atlanta I am told.  Known issues
out there?  Any de-peering going on?  Or is this just a firewall or private
IP space that is not responding to traceroute information requests?

 

Thanks for any help,

 

Lorell Hathcock


From aservin at lacnic.net  Tue Nov 15 23:33:46 2011
From: aservin at lacnic.net (Arturo Servin)
Date: Wed, 16 Nov 2011 13:33:46 +0800
Subject: Minimum Allocation Size by RIRs (IPv4)
In-Reply-To: <CAGFn2k1H+WN+KYuZ0g1RNRD3oBXK5tCL1Vy6ci8_GWGRODtPLg@mail.gmail.com>
References: <4EC27DB7.4000800@init7.net>
 <CAGFn2k1H+WN+KYuZ0g1RNRD3oBXK5tCL1Vy6ci8_GWGRODtPLg@mail.gmail.com>
Message-ID: <7EBFADB7-8607-4673-8298-8312A7B0F63F@lacnic.net>


	/24 as minimal allocation is only for end-users and critical infrastructure.

	For ISPs (LIRs) the minimal allocation is /22.

/as


On 16 Nov 2011, at 00:30, Rubens Kuhl wrote:

> LACNIC: /24 - http://lacnic.net/en/politicas/manual3.html


From christopher.morrow at gmail.com  Tue Nov 15 23:58:47 2011
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Wed, 16 Nov 2011 00:58:47 -0500
Subject: Question about operational concerns with Routing Protocol Security
Message-ID: <CAL9jLabKfhP6d6R+yK6uvzLJ+_A+r4yP5Z5cMT62g3f2kveXEQ@mail.gmail.com>

Howdy,
while enjoying some (oddly not controversial) meeting time at the
IETF, one of the presenters (Sam Hartman[1]) noted he's looking for
some people to chat with with respect to 'deployment scenarios'
surrounding network gear and protocol security.

Today that probably takes the form of things like: "Hey, be sure to
copy the password into the config before turning up the interfaces!"

I can imagine other methods as well, for things like:
  eBGP
  iBGP
  ISIS
  OSPF

would any of the folks on-list that currently have key material
(passwords and such) configured for these protocols AND who also
deploy new gear into the field be willing to chat some w