Re: Problems with removing NAT from a network

[Benson Schliesser]

On Jan 7, 2011, at 12:39 AM, Matthew Kaufman wrote:

> On 1/6/2011 9:28 PM, Dan Wing wrote:
>> 
>> Skype could make it work with direct UDP packets in about 92% of
>> cases, per Google's published direct-to-direct statistic at
>> http://code.google.com/apis/talk/libjingle/important_concepts.html
>> 
> If one end is behind a NAT64 and there is no mechanism for discovering the 
> NAT64's IPv6 interface prefix and mapping algorithm (and at present there is 
> not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 
> literal addresses (that is to say, addresses learned via a mechanism other 
> than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on 
> the IPv4 Internet through said NAT64.
> 
> That's the case we're discussing here.
> 
> It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. 
> Even the protocol described in the referenced document, Jingle (as it 
> essentially uses ICE) fails. The candidate IPv4 addresses for the end that's 
> on the IPv4 Internet (local and STUN-derived) that are delivered over 
> Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to 
> reach the IPv4 Internet because it has no IPv4 sockets available to it and 
> even if it knew that NAT64 existed (which would take a modification to the 
> Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 
> address to use to reach the IPv4 host because there's no discovery mechanism. 
> If you want we can take this back to the BEHAVE list now.

To paraphrase what you're saying: stuff that embeds and passes around IPv4 
addresses will break.  I'm sorry to say this, but that's just reality.  
Embedded IP addresses has always been a Bad Idea (tm) in development and 
operations, and I don't think P2P protocols get a pass - building your own 
discovery and topology mechanisms don't insulate you from having to use the 
underlying network.

The best chance anybody has, is to build dual-stack support and start using DNS 
names rather than IP numbers.  Oh, and expect IPv4 to start breaking in the 
near future.  We're trying to make IPv4 work long enough to survive the 
transition, but it's not a good bet for new protocols.

Cheers,
-Benson

Re: Problems with removing NAT from a network

[Mikael Abrahamsson]

On Thu, 6 Jan 2011, Matthew Kaufman wrote:

If one end is behind a NAT64 and there is no mechanism for discovering 
the NAT64's IPv6 interface prefix and mapping algorithm (and at present 
there is not), there is no way to send IPv6 IP packets from the 
IPv6-only host to IPv4 literal addresses (that is to say, addresses 
learned via a mechanism other than DNS responses synthesized by the 
DNS64 part of the NAT64 "solution") on the IPv4 Internet through said 
NAT64.


There has been discussions on v6ops mailinglist about BIH (Bump In Host) 
for mobile applications, so that one could create a client on the machine 
behind NAT64 and make it work work with programs that use v4 literals (or 
have no v6 support at all).


It though seems there is considerable resistance within the IETF community 
against such solutions as (I've been told) history has shown there to be a 
lot of problems with this kind of double translation.


Therefore the IETF seems to lean towards tunneling of IPv4 over IPv6 to 
give such a host literal IPv4 connextivity (could be called 4RD) instead 
of doing translation.


For mobile applications, single stack on the access is to only realistic 
method in the next few years, therefore this needs to be solved somehow. 
3GPP doesn't like tunnels though (since they already do tunneling), so 
right now there isn't really broad agreement on how to solve this.


Personally I think we need some kind of transitioning mechanism to handle 
v4 only applications and v4 literals in the forseeable future, just like 
we needed trumped winsock in the 90ties, we're going to need full v4 
connectivity for Windows XP (applications + dns transport) over v6only 
access.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: IPv6 - real vs theoretical problems

[Jima]

On 1/7/2011 12:11 AM, Owen DeLong wrote:

That's a draft, and, it doesn't really eliminate the idea that /48s are 
generally
a good thing so much as it recognizes that there might be SOME circumstances
in which they are either not necessary or insufficient.

As a draft, it hasn't been through the full process and shouldn't be considered
to have the same weight as an RFC.

While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, 
may
never do so.


 Fully understood; I wasn't meaning to present it as irrefutable 
evidence that the /64 & /48 mindset is flawed, but as a timely 
counterpoint to people expounding the virtues of 3177 without cautiously 
acknowledging that its recommendations aren't necessarily for everyone. 
 I apologize if my intentions weren't terribly clear -- that may be a 
good cue for me to go to bed.


 Jima

Re: Problems with removing NAT from a network

[Matthew Kaufman]

On 1/6/2011 9:28 PM, Dan Wing wrote:

-Original Message-
From: Matthew Kaufman [mailto:matt...@matthew.at]
Not really. Imagine the case where you're on IPv6 and you can only
reach
IPv4 via a NAT64, and there's no progress made on the detection
problem.
And your family member is on a Skype-enabled TV plugged into an
IPv4-only ISP.

Now you can't get a direct media path between you, even though their
ISP
is giving them IPv4 and your ISP is *claiming* you can "still reach the
IPv4 Internet".

Skype can still make this work by relaying,

Skype could make it work with direct UDP packets in about 92% of
cases, per Google's published direct-to-direct statistic at
http://code.google.com/apis/talk/libjingle/important_concepts.html

If one end is behind a NAT64 and there is no mechanism for discovering 
the NAT64's IPv6 interface prefix and mapping algorithm (and at present 
there is not), there is no way to send IPv6 IP packets from the 
IPv6-only host to IPv4 literal addresses (that is to say, addresses 
learned via a mechanism other than DNS responses synthesized by the 
DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64.


That's the case we're discussing here.

It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, 
etc. Even the protocol described in the referenced document, Jingle (as 
it essentially uses ICE) fails. The candidate IPv4 addresses for the end 
that's on the IPv4 Internet (local and STUN-derived) that are delivered 
over Jingle's XMPP path cannot be used by the host that is on IPv6 + 
NAT64 to reach the IPv4 Internet because it has no IPv4 sockets 
available to it and even if it knew that NAT64 existed (which would take 
a modification to the Jingle-based apps) and opened an IPv6 socket it 
wouldn't know what IPv6 address to use to reach the IPv4 host because 
there's no discovery mechanism. If you want we can take this back to the 
BEHAVE list now.



Matthew Kaufman

Re: IPv6 - real vs theoretical problems

[Owen DeLong]

On Jan 6, 2011, at 8:58 PM, Jima wrote:

> On 1/6/2011 4:47 PM, Grant Phillips wrote:
>> I acknowledge and see the point made. There is a lot of dead space in the
>> IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more
>> to no.
>> 
>> Have you read this RFC? This is pretty satisfying in making me feel more
>> comfortable assigning out /48 and /64's. I can sleep at night now! :P
>> 
>> http://tools.ietf.org/html//rfc3177
> 
> I can't tell if you're trolling, or if you didn't get the memo from Monday.  
> I guess I'll lean toward the latter.
> 
> http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html
> 
> Jima

That's a draft, and, it doesn't really eliminate the idea that /48s are 
generally
a good thing so much as it recognizes that there might be SOME circumstances
in which they are either not necessary or insufficient.

As a draft, it hasn't been through the full process and shouldn't be considered
to have the same weight as an RFC.

While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, 
may
never do so.

Owen

Re: NIST IPv6 document

[Owen DeLong]

On Jan 6, 2011, at 7:13 PM, Jeff Wheeler wrote:

> On Thu, Jan 6, 2011 at 9:24 PM, Joe Greco  wrote:
>> With today's implementations of things?  Perhaps.  However, you
>> show yourself equally incapable of grasping the real problem by
>> looking at the broader picture, and recognizing that problematic
>> issues such as finding hosts on a network are very solvable
>> problems, and that we are at an early enough phase of IPv6 that
>> we can even expect some experiments will be tried.
>> 
>> Look beyond what _is_ today and see if you can figure out what
>> it _could_ be.  There's no need for what I suggest to DoS a router;
>> that's just accepting a naive implementation and saying "well this
>> can't be done because this one way of doing it breaks things."  It
>> is better to look for a way to fix the problem.
> 
> Actually, unlike most posters on this subject, I have a very good
> understanding of how everything works "under the hood."  For this
> reason, I also understand what is possible given the size of a /64
> subnet and the knowledge that we will never have adjacency tables
> approaching this size.
> 
> If you are someone who thinks, oh, those Cisco and Juniper developers
> will figure this out, they just haven't thought about it hard enough
> yet, I can understand why you believe that a simple fix like "no ip
> directed-broadcast" is on the horizon.  Unfortunately, it is not.  The
> only thing they can do is give more mitigation knobs to allow
> operators to choose our failure modes and thresholds.  To really fix
> it, you need a smaller subnet or a radical protocol change that will
> introduce a different set of problems.
> 
I think I have a pretty good understanding of what happens under the
hood, too.

The reality is that what you say is theoretically possible, but, not
terribly practical from an attacker perspective. It's pretty trivial to
block these attacks out from threats outside your network or at
least severely limit the number of attackable addresses within the
individual network. Smaller network segments are not necessary
to reduce the attackable profile of the network segment.

Yes, a determined host within your network segment can DOS the
network segment this way. Guess what... If you've got a determined
attacker on your network segment, you've already lost on multiple
other levels, so, this might even be a feature.

As such, while the issue you bring up can be a problem for a poorly
administered network, I think you overstate it's viability as an attack
vector in most real world instances.

Owen

Re: NIST IPv6 document

[Jima]

 Hey Lamar, long time no talk.

On 1/6/2011 10:16 AM, Lamar Owen wrote:

Standards are written by people, of course, and most paragraphs have reasons to 
be there; I would find it interesting to hear the rationale for a router 
filling a slot in its neighbor table for a host that doesn't exist.  For that 
matter, I'd like to see a pointer to which standard that says this so I can 
read the verbiage myself, as that may have enough explanation to satisfy my 
curiosity.


 This actually came up last week in freenode/#ipv6; someone was puzzled 
why there were FAIL entries showing up in their neighbor table, so I dug 
into the RFC I found for ND (2461).  Turns out, it specifically says 
entries for failed solicitations SHOULD be deleted.


http://tools.ietf.org/html/rfc2461#section-7.3.3

 It's the seventh paragraph into that section, including the indented 
Note.  ("Upon entering the PROBE state...")

 Pardon me if that's the wrong RFC.

 Jima

RE: Problems with removing NAT from a network

[Dan Wing]

> -Original Message-
> From: Matthew Kaufman [mailto:matt...@matthew.at]
> Sent: Thursday, January 06, 2011 6:55 PM
> To: Owen DeLong
> Cc: Nanog Operators' Group
> Subject: Re: Problems with removing NAT from a network
> 
> On 1/6/2011 5:48 PM, Owen DeLong wrote:
> > Doesn't all of this become moot if Skype just develops a dual-stack
> capable client
> > and servers?
> >
> Not really. Imagine the case where you're on IPv6 and you can only
> reach
> IPv4 via a NAT64, and there's no progress made on the detection
> problem.
> And your family member is on a Skype-enabled TV plugged into an
> IPv4-only ISP.
> 
> Now you can't get a direct media path between you, even though their
> ISP
> is giving them IPv4 and your ISP is *claiming* you can "still reach the
> IPv4 Internet".
> 
> Skype can still make this work by relaying,

Skype could make it work with direct UDP packets in about 92% of
cases, per Google's published direct-to-direct statistic at
http://code.google.com/apis/talk/libjingle/important_concepts.html

-d


> but in order to protect the
> relay machine's bandwidth it will rate-limit the traffic, and so your
> A/V experience will suffer. And that's assuming there's enough
> dual-stacked relays... if there aren't, it won't be possible to find a
> relay that they can reach over IPv4 and you can reach over IPv6 that
> has
> available bandwidth.
> 
> Matthew Kaufman

Re: IPv6 - real vs theoretical problems

[Jima]

On 1/6/2011 4:47 PM, Grant Phillips wrote:

I acknowledge and see the point made. There is a lot of dead space in the
IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more
to no.

Have you read this RFC? This is pretty satisfying in making me feel more
comfortable assigning out /48 and /64's. I can sleep at night now! :P

http://tools.ietf.org/html//rfc3177


 I can't tell if you're trolling, or if you didn't get the memo from 
Monday.  I guess I'll lean toward the latter.


http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html

 Jima

Re: NIST IPv6 document

[Jeff Wheeler]

On Thu, Jan 6, 2011 at 9:24 PM, Joe Greco  wrote:
> With today's implementations of things?  Perhaps.  However, you
> show yourself equally incapable of grasping the real problem by
> looking at the broader picture, and recognizing that problematic
> issues such as finding hosts on a network are very solvable
> problems, and that we are at an early enough phase of IPv6 that
> we can even expect some experiments will be tried.
>
> Look beyond what _is_ today and see if you can figure out what
> it _could_ be.  There's no need for what I suggest to DoS a router;
> that's just accepting a naive implementation and saying "well this
> can't be done because this one way of doing it breaks things."  It
> is better to look for a way to fix the problem.

Actually, unlike most posters on this subject, I have a very good
understanding of how everything works "under the hood."  For this
reason, I also understand what is possible given the size of a /64
subnet and the knowledge that we will never have adjacency tables
approaching this size.

If you are someone who thinks, oh, those Cisco and Juniper developers
will figure this out, they just haven't thought about it hard enough
yet, I can understand why you believe that a simple fix like "no ip
directed-broadcast" is on the horizon.  Unfortunately, it is not.  The
only thing they can do is give more mitigation knobs to allow
operators to choose our failure modes and thresholds.  To really fix
it, you need a smaller subnet or a radical protocol change that will
introduce a different set of problems.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: NIST IPv6 document

[Jeff Wheeler]

On Thu, Jan 6, 2011 at 9:31 PM, Owen DeLong  wrote:
>> You must understand that policing will not stop the NDCache from
>> becoming full almost instantly under an attack.  Since the largest
>> existing routers have about 100k entries at most, an attack can fill
>> that up in *one second.*
>>
> If the policing rate is set to ~100 requests per second, or, even
> 1000 requests per second, then, I'm not sure why you think this.

With a 100pps policer, it is trivial for an attack to make its NS
requests far more likely to make it through the policer than
legitimate NS requests that would result in discovering a valid
layer-2 mapping.  If you are hitting the policer, the subnet is
broken.  If you don't have a policer, the table is full and ... the
subnet is broken.  See how it's a problem that isn't solvable with a
simple policer?  Note that the Cisco "solution" is indeed a
configurable per-interface policer, which is better than nothing, but
does not fully solve the problem.  Policing isn't a new idea.  I'm not
sure it's a step in the right direction, or just prolonging an
inevitable change towards a real fix.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: Problems with removing NAT from a network

[Matthew Kaufman]

On 1/6/2011 6:34 PM, Joel Jaeggli wrote:

On 1/6/11 5:48 PM, Owen DeLong wrote:

Doesn't all of this become moot if Skype just develops a dual-stack capable 
client
and servers?

Really, only some fraction of the supernodes and the login servers need
to be dual stack.

Without revealing too much about the architecture, I can tell you that 
it would need to be a significant fraction of the supernodes (due to how 
node-supernode mapping works in these types of P2P systems), the relay 
nodes (not mentioned) *and* the login servers. Not all of which are 
deployed and controlled by Skype, of course, as recent press about the 
most recent outage has reiterated for those who didn't know.


Matthew Kaufman

Re: Problems with removing NAT from a network

[Matthew Kaufman]

On 1/6/2011 5:48 PM, Owen DeLong wrote:

Doesn't all of this become moot if Skype just develops a dual-stack capable 
client
and servers?

Not really. Imagine the case where you're on IPv6 and you can only reach 
IPv4 via a NAT64, and there's no progress made on the detection problem. 
And your family member is on a Skype-enabled TV plugged into an 
IPv4-only ISP.


Now you can't get a direct media path between you, even though their ISP 
is giving them IPv4 and your ISP is *claiming* you can "still reach the 
IPv4 Internet".


Skype can still make this work by relaying, but in order to protect the 
relay machine's bandwidth it will rate-limit the traffic, and so your 
A/V experience will suffer. And that's assuming there's enough 
dual-stacked relays... if there aren't, it won't be possible to find a 
relay that they can reach over IPv4 and you can reach over IPv6 that has 
available bandwidth.


Matthew Kaufman

Re: Problems with removing NAT from a network

[Joel Jaeggli]

On 1/6/11 5:48 PM, Owen DeLong wrote:
> Doesn't all of this become moot if Skype just develops a dual-stack capable 
> client
> and servers?

Really, only some fraction of the supernodes and the login servers need
to be dual stack.

> Owen
> 
> On Jan 6, 2011, at 1:32 PM, Matthew Kaufman wrote:
> 
>> On 1/6/2011 10:07 AM, Cameron Byrne wrote:
>>>
>>> Skype is not defined in an IETF RFC, so saying you need an RFC to move
>>> forward is bit confusing.
>> I don't see a disconnect at all. Skype also uses TCP and UDP, which are both 
>> subjects of RFCs.
>>
>> That said, it doesn't need to be an RFC... just *a reliable way* of 
>> discovering the appropriate NAT64 prefix.
>>>  There are several methods that just work
>>> today,
>> Of the methods proposed in the survey draft, only one - the one that doesn't 
>> require the DNS64 spec or operator to make any changes (making an  
>> lookup for something you know only has an A record) - works but *only if* 
>> the mapping scheme is such that it is possible to successfully derive a 
>> functional prefix and the scheme from the results of that query.
>>
>> So in other words, *if* the query results in an  where, by inspection, 
>> you can guess where you'd need to stuff the IPv4 address bits *and* the 
>> resulting address causes the "right" NAT64 (if there's >1) to be used, then 
>> you're set.
>>> I am all for standards, but a closed platforms generally find ways to
>>> progress without or in spite of standards.  Skype is a closed
>>> platform.
>> No question. And for all you know we might be working on other ways around 
>> this problem, but none of them as elegant as a defined specification for how 
>> to discover the presence of a NAT64 and the mapping.
>>>
 There's lots of other apps that don't work. Skype is just the squeaky wheel
 because it is so popular.

>>> Please make a list and let us know.  Otherwise, this is just hand
>>> waving like the IPv4 literals sites.
>> I'll start with "peer to peer connectivity using RTMFP in Flash Player" and 
>> "BitTorrent". Both Flash Player and BitTorrent are fairly popular on desktop 
>> platforms.
>>
>> I'm sure there's more.
>>
>>
>>> My advice to Skype is to come up with a solution to work for IPv6-only
>>> clients. That is my advice to all apps and all content.  IPv6-only
>>> clients are an obvious reality in an IPv4 exhausted world.
>> That's not the problem... the problem is reaching the existing base of IPv4 
>> clients from those IPv6-only clients without making Skype relay all the 
>> traffic via servers somewhere, as I'm sure you know.
>>
>>> You cannot seriously come to a network operators support mailing list
>>> and say that the network guys have to keep investing in network tweaks
>>> while you wait for a standards body to solve a problem for your closed
>>> non-standard applications.
>> I've been on this list since approximately the time it was formed, so I'm 
>> not coming here to ask for something. Just pointing out what will break.
>>
>>> I also assure you, many mobile operators are pursuing this NAT64 path
>>> for the same reason I am.
>> Randy Bush would encourage his competitors to do just as you've done, I'm 
>> sure.
>>
>> Matthew Kaufman
>>
> 
> 
> 

Re: Problems with removing NAT from a network

[Steven Bellovin]

On Jan 6, 2011, at 8:48 12PM, Owen DeLong wrote:

> Doesn't all of this become moot if Skype just develops a dual-stack capable 
> client
> and servers?

Skype is an interesting case because of its peer-to-peer nature.  Given the
state of v6 deployment and operational experience[1], and especially given the
fragility of tunneled IPv6 connections[2], there is potential for a lot of
broken links.  

--Steve Bellovin, http://www.cs.columbia.edu/~smb

[1] All concerned are mystified about why my office machines can't reach [major
site] via v6, even though traceroute6 from both ends shows the packets reaching
the same network.  A couple of weeks earlier, I couldn't get anywhere via IPv6
because someone had connected a NAT+v6 tunneler in bridge mode, and my machine
believe its RA messages.

[2] See http://www.google.com/intl/en/ipv6/faq.html#tunnel

Re: NIST IPv6 document

[Joe Greco]

> 
> On Thu, Jan 6, 2011 at 6:46 PM, Owen DeLong  wrote:
> > On Jan 5, 2011, at 9:17 PM, Joe Greco wrote:
> >> However, that's not the only potential use! =A0A client that initiates
> >> each new outbound connection from a different IP address is doing
> >> something Really Good.
> > If hosts start cycling their addresses that frequently, don't you run the
> > risk of that becoming a form of DOS on your router's ND tables?
> 
> Of course, Owen.  I replied to that specific point in Joe's post
> earlier, although I have written so much on this thread, I have tried
> to condense my replies, so anyone reading in thread mode may have
> missed it.
> 
> The fact that Joe even makes that suggestion signals how little
> understanding he has of the problem.  His idea would DoS his own
> router. 

With today's implementations of things?  Perhaps.  However, you
show yourself equally incapable of grasping the real problem by
looking at the broader picture, and recognizing that problematic
issues such as finding hosts on a network are very solvable 
problems, and that we are at an early enough phase of IPv6 that
we can even expect some experiments will be tried.

Look beyond what _is_ today and see if you can figure out what
it _could_ be.  There's no need for what I suggest to DoS a router;
that's just accepting a naive implementation and saying "well this
can't be done because this one way of doing it breaks things."  It
is better to look for a way to fix the problem.

... 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.

Re: NIST IPv6 document

[Joe Greco]

> 
> On Jan 5, 2011, at 9:17 PM, Joe Greco wrote:
> 
> >>> It has nothing to do with "security by obscurity".
> >>=20
> >> You may wish to re-read what Joe was saying - he was positing sparse =
> addres=3D
> >> sing as a positive good because it will supposedly make it more =
> difficult f=3D
> >> or attackers to locate endpoints in the first place, i.e., security =
> through=3D
> >> obscurity.  I think that's an invalid argument.
> >=20
> > That's not necessarily security through obscurity.  A client that just
> > picks a random(*) address in the /64 and sits on it forever could be
> > reasonably argued to be doing a form of security through obscurity.
> > However, that's not the only potential use!  A client that initiates
> > each new outbound connection from a different IP address is doing
> > something Really Good.
> >=20
> If hosts start cycling their addresses that frequently, don't you run =
> the risk of that becoming a form of DOS on your router's ND tables?

It could, but given the changes we've seen in the last twenty years, I
have no reason to expect that this won't become practical and commonplace
in IPv6.  I think it is a matter of finding the right enabling 
technologies, and as others have noted, what currently exists for IPv6
isn't necessarily the best-of-breed.

... 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.

Re: NIST IPv6 document

[Jeff Wheeler]

On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong  wrote:
> 1.      Block packets destined for your point-to-point links at your
>        borders. There's no legitimate reason someone should be

Most networks do not do this today.  Whether or not that is wise is
questionable, but I don't think those networks want NDP to be the
reason they choose to make this change.

> 2.      For networks that aren't intended to receive inbound requests
>        from the outside, limit such requests to the live hosts that
>        exist on those networks with a stateful firewall.

Again, this doesn't fix the problem of misconfigured hosts on the LAN.
 I can and shall say it over and over, as long as folks continue to
miss the potential for one compromised machine to disable the entire
LAN, and in many cases, the entire router.  It is bad that NDP table
overflow can be triggered externally, but even if you solve that
problem (which again does not require a stateful firewall, why do you
keep saying this?) you still haven't made sure one host machine can't
disable the LAN/router.

> 3.      Police the ND issue rate on the router. Yes, it means that
>        an ND attack could prevent some legitimate ND requests
>        from getting through, but, at least it prevents ND overflow and
>        the working hosts with existing ND entries continue to function.
>        In most cases, this will be virtually all of the active hosts on
>        the network.

You must understand that policing will not stop the NDCache from
becoming full almost instantly under an attack.  Since the largest
existing routers have about 100k entries at most, an attack can fill
that up in *one second.*

On some platforms, existing entries must be periodically refreshed by
actual ARP/NDP exchange.  If they are not refreshed, the entries go
away, and traffic stops flowing.  This is extremely bad because it can
break even hosts with constant traffic flows, such as a server or
infrastructure link to a neighboring router.  Depending on the attack
PPS and policer configuration, such hosts may remain broken for the
duration of the attack.

Implementations differ greatly in this regard.  All of them break
under an attack.  Every single current implementation breaks in some
fashion.  It's just a question of how bad.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: NIST IPv6 document

[Owen DeLong]

On Jan 6, 2011, at 3:32 PM, Dobbins, Roland wrote:

> 
> On Jan 7, 2011, at 1:20 AM, Owen DeLong wrote:
> 
>> You are mistaken... Host scanning followed by port sweeps is a very common 
>> threat and still widely practiced in IPv4.
> 
> I know it's common and widely-practiced.  My point is that if the host is 
> security properly, this doesn't matter; and that if it isn't secured 
> properly, it's going to be found via hinted scanning and exploited, anyways.
> 
True, but, that doesn't really matter. Sparse addressing still provides other 
useful benefits.

>> And there are ways to mitigate ND attacks as well.
> 
> As has been pointed out elsewhere in this thread, not to the degree of 
> control and certainty needed in production environments.
> 
We can agree to disagree here until I see a production environment get taken 
down by a scan.

So far, we've not had a problem with any of the IPv6 scans through our network. 
All have given up in <8 hours without
having caused any sort of ND table overflow issues.

>> Sparse addressing is a win for much more than just rendering scanning 
>> useless, but, making scanning useless is still a win.
> 
> 
> Since it doesn't make scanning useless (again, hinted scanning), that 'win' 
> is gone.  How else is it supposedly a win?
> 
Not having to worry about room to grow without renumbering is a good thing.
I've posted other advantages in an earlier message.

It does make sequential scanning useless and it does make even hinted scanning 
a bit more difficult or
less effective.

Think of the difference between playing battleship as it is traditionally 
played on a simple X, Y grid
vs. playing it on a playing field where the ships have 180 different possible 
orientations (1 per degree
instead of 0º and 90º only)

Once you get a hit, you need a maximum of 4 additional attempts to identify the 
orientation of the
ship and 50%+ of the time you can get it in ≤2 additional attempts. With a 360º 
board, this becomes
quite a bit more difficult.

Sparse addressing does this even against hinted scanning.

Owen

Re: IPv6 - real vs theoretical problems

[William Herrin]

On Thu, Jan 6, 2011 at 5:00 PM, Deepak Jain  wrote:
> Wouldn't a number of problems go away if we just, for now, follow the
> IPv4 lessons/practices like allocating the number of addresses a
> customer needs --- say /122s or /120s that current router
> architectures know how to handle -- to these boxes/interfaces
> today, while just reserving /64 or /56 spaces for each of them
> for whenever the magic day comes along where they can be
> used safely?

Hi Deepak,

No. IPv6 is only *almost* the same as IPv4. Drill these three
differences into your mind and you should do just fine:

/64 LAN netmask
nibble delegation boundary
how many LANs (not hosts!) in this stub network?

Without going into the technical details, IPv6 has been engineered
with the intention that any netmask will work but a /64 netmask works
distinctly better. Don't think of it as a 128 bit address. Think of it
as a 64 bit network address plus a 64 bit host address. Apply IPv4
lessons to the 64 bit network address. The 64 bit host address is for
the customer, the same way the 16-bit TCP port is for the customer.

IPv6 has been rigged so that address space naturally delegates on
nibble boundaries. It's one NS entry in the RDNS zone. It's an exact
string of characters in the hexadecimal written form. Should you
delegate on a different boundary, you invite all the common
difficulties human beings have evaluating a netmask and add in the
trouble dealing with base 16, rarely for any discernible gain.

In IPv4 you think about how many addresses do I need to accommodate X
hosts. This mental model does not match IPv6's technology model. If
LANs are always /64, how many LANs does this stub network require?


Example: Customer A has a gaming PC in a DMZ and two surfing PCs. How
many IPv6 addresses?

1 LAN (/64) for the DMZ
1 LAN (/64) for the PCs
1 LAN (/64) between the firewall and the router
round up to the nibble boundary: 16 LANs (/60)

Consider providing a /56 or a /48 instead of a /60 so that there's
lots of room for expansion, dynamic interior delegation or whatever.
But /60 is your absolute floor. Less will turn out to be like telling
the same customer to use 192.168.1.252/30: technical difficulties will
promptly ensue.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv6 - real vs theoretical problems

[Owen DeLong]

On Jan 6, 2011, at 2:00 PM, Deepak Jain wrote:

> 
> Please, before you flame out, recognize I know a bit of what I am talking 
> about. You can verify this by doing a search on NANOG archives. My point is 
> to actually engage in an operational discussion on this and not insult (or be 
> insulted).
> 
> While I understand the theoretical advantages of /64s and /56s and /48s for 
> all kinds of purposes, *TODAY* there are very few folks that are actually 
> using any of them. No typical customer knows what do to do (for the most 
> part) with their own /48, and other than autoconfiguration, there is no 
> particular advantage to a /64 block for a single server -- yet. The left side 
> of the prefix I think people and routers are reasonably comfortable with, 
> it's the "host" side that presents the most challenge.
> 
> My interest is principally in servers and high availability equipment 
> (routers, etc) and other things that live in POPs and datacenters, so 
> autoconfiguration doesn't even remotely appeal to me for anything. In a 
> datacenter, many of these concerns about having routers fall over exist (high 
> bandwidth links, high power equipment trying to do as many things as it can, 
> etc). 
> 
> Wouldn't a number of problems go away if we just, for now, follow the IPv4 
> lessons/practices like allocating the number of addresses a customer needs 
> --- say /122s or /120s that current router architectures know how to handle 
> -- to these boxes/interfaces today, while just reserving /64 or /56 spaces 
> for each of them for whenever the magic day comes along where they can be 
> used safely?
> 
No... A single perceived problem would go away and we would reacquire many many 
more problems that IPv6 is intended to leave behind.

So far, IPv6 scans have been few and far between. The ones we have seen have 
been short lived and haven't even scanned a single
network (Perhaps some time in the next 500+ years we will see one that does, 
but, I have my doubts).

I think that targeted or hinted scanning will be the more likely approach in 
the IPv6 world. We haven't yet seen what will happen in that
realm.

As to what we lose if we eliminate large sparse end networks, we lose the 
following advantages:

+   Ability to just add machines to a network without having to worry about 
resizing the network or
renumbering everything or worst of all adding yet another prefix to 
hold the new machines.

+   Sparse address density and privacy addressing capabilities

+   SLAAC

+   Simplified "network of things" capabilities

There are probably other things as well, but, those 4 are what I can think of 
off the top of my head.

Only the first one applies to server environments, but, it's a HUGE win for 
server environments, so, I think it's worth preserving for
that reason alone. However, if you're willing to abandon that for your server 
farm, then, nobody is stopping you, actually. IPv6
fully supports statically configured networks of any size down to /127. Knock 
yourself out.

> As far as I can tell, this "crippling" of the address space is completely 
> reversible, it's a reasonable step forward and the only "operational" loss is 
> you can't do all the address jumping and obfuscation people like to talk 
> about... which I'm not sure is a loss. 
> 
I'm not sure what you mean by "crippling" of the address space. It seems to be 
working just fine in a number of production
environments around the world, including both my work and home environments.

> In your enterprise, behind your firewall, whatever, where you want autoconfig 
> to work, and have some way of dealing with all of the dead space, more power 
> to you. But operationally, is *anything* gained today by giving every host a 
> /64 to screw around in that isn't accomplished by a /120 or so?
> 
I don't imagine anyone will give every host a /64. What is currently proposed 
is giving every network a /64. Most networks
contain at least two hosts to be minimally useful (router + end system), and 
the vast majority of those contain more than
one end system (3+ hosts).

Owen

Re: IPv6 - real vs theoretical problems

[Jeff Wheeler]

On Thu, Jan 6, 2011 at 8:04 PM, Jimmy Hess  wrote:
> It is advisable to look for much stronger reasons than "With
> IPv4 we did it"  or   With IPv4 we ran into such and such
> problem"   due to unique characteristics of IPv4 addressing
> or other IPv4 conventions that had to continue to exist for
> compatibility reasons, etc, etc.

I certainly agree that there are many advantages to the greater
address space offered by IPv6.  I don't mean to advocate that we do
things the same way as was necessary to conserve v4 address space, and
I'm sure we all realize that RIR policies necessarily contributed to
routing table growth in trade for extending the life of the available
address space.

I'm not blindly deploying /64 networks, either.  Doing so with the
current set of problems, and lack of knobs, is very foolish.  My
transit providers offer a mix of /126 and /124 demarc subnets so far,
and /124 is what I choose to standardize on for my BGP customers and
private peering, for simplicity and convenience.  As I mentioned
before, I currently allocate a /64 and configure a /124, so I am not
painting myself into a corner either way.

How many of us with an appreciable level of expertise remain concerned
that our approach may need significant adjustment?  How many think we
know what those potential adjustments may be, and have planned to make
them easy (or transparent) for ourselves and customers if they become
necessary?  This is what is IMO most important to a responsible IPv6
deployment.  To do otherwise is inviting unpredictable future pain.

I am comforted by the fact that Level3 is deploying customer demarc
subnets as /126 and is NOT allocating a /64 for each, but are instead
packing them densely in an IPv4 /30 fashion.  They recognize problems
with the /64 approach, choose not to follow the "standard" to the
letter, and implement their dual-stack network in a way they
presumably believe is safe and scalable.  Large networks like Level3
choosing to insist that equipment vendors support this configuration,
rather than have problems with densely packed subnets smaller than
/64, will mean that anyone who wants to sell a router to Level3 had
better make it work correctly this way, which is good for the small
guy like me who thinks he will eventually transition to that
configuration.  Right now, I am still hedging my bet.

Are there any large transit networks doing /64 on point-to-point
networks to BGP customers?  Who are they?  What steps have they taken
to eliminate problems, if any?

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: Problems with removing NAT from a network

[Owen DeLong]

Doesn't all of this become moot if Skype just develops a dual-stack capable 
client
and servers?

Owen

On Jan 6, 2011, at 1:32 PM, Matthew Kaufman wrote:

> On 1/6/2011 10:07 AM, Cameron Byrne wrote:
>> 
>> Skype is not defined in an IETF RFC, so saying you need an RFC to move
>> forward is bit confusing.
> I don't see a disconnect at all. Skype also uses TCP and UDP, which are both 
> subjects of RFCs.
> 
> That said, it doesn't need to be an RFC... just *a reliable way* of 
> discovering the appropriate NAT64 prefix.
>>  There are several methods that just work
>> today,
> Of the methods proposed in the survey draft, only one - the one that doesn't 
> require the DNS64 spec or operator to make any changes (making an  lookup 
> for something you know only has an A record) - works but *only if* the 
> mapping scheme is such that it is possible to successfully derive a 
> functional prefix and the scheme from the results of that query.
> 
> So in other words, *if* the query results in an  where, by inspection, 
> you can guess where you'd need to stuff the IPv4 address bits *and* the 
> resulting address causes the "right" NAT64 (if there's >1) to be used, then 
> you're set.
>> I am all for standards, but a closed platforms generally find ways to
>> progress without or in spite of standards.  Skype is a closed
>> platform.
> No question. And for all you know we might be working on other ways around 
> this problem, but none of them as elegant as a defined specification for how 
> to discover the presence of a NAT64 and the mapping.
>> 
>>> There's lots of other apps that don't work. Skype is just the squeaky wheel
>>> because it is so popular.
>>> 
>> Please make a list and let us know.  Otherwise, this is just hand
>> waving like the IPv4 literals sites.
> I'll start with "peer to peer connectivity using RTMFP in Flash Player" and 
> "BitTorrent". Both Flash Player and BitTorrent are fairly popular on desktop 
> platforms.
> 
> I'm sure there's more.
> 
> 
>> My advice to Skype is to come up with a solution to work for IPv6-only
>> clients. That is my advice to all apps and all content.  IPv6-only
>> clients are an obvious reality in an IPv4 exhausted world.
> That's not the problem... the problem is reaching the existing base of IPv4 
> clients from those IPv6-only clients without making Skype relay all the 
> traffic via servers somewhere, as I'm sure you know.
> 
>> You cannot seriously come to a network operators support mailing list
>> and say that the network guys have to keep investing in network tweaks
>> while you wait for a standards body to solve a problem for your closed
>> non-standard applications.
> I've been on this list since approximately the time it was formed, so I'm not 
> coming here to ask for something. Just pointing out what will break.
> 
>> I also assure you, many mobile operators are pursuing this NAT64 path
>> for the same reason I am.
> Randy Bush would encourage his competitors to do just as you've done, I'm 
> sure.
> 
> Matthew Kaufman
> 

Re: NIST IPv6 document

[Owen DeLong]

> 
> 
> On Thu, Jan 6, 2011 at 1:20 PM, Owen DeLong  wrote:
>> And there are ways to mitigate ND attacks as well.
> 
> No, Owen, there aren't.  The necessary router knobs do not exist.  The
> "Cisco approach" is currently to police NDP on a per-interface basis
> (either with per-int or global configuration knob) and break NDP on
> the interface once that policer is exceeded.  This is good (thanks,
> Cisco) because it limits damage to one subnet; but bad because it
> exemplifies the severity of the issue: the "Cisco solution" is known
> to be bad, but is less bad than letting the whole box break.  Cisco is
> not going to come up with a magic knob because there isn't any -- with
> the current design, you have to pick your failure modes and live with
> them.  That's not good and it is not a Cisco failing by any means, it
> is a design failing brought on by the standards bodies.
> 
Saying this over and over doesn't make it so...

1.  Block packets destined for your point-to-point links at your
borders. There's no legitimate reason someone should be
expecting your routers to respond to packets sent to the
router specifically.

2.  For networks that aren't intended to receive inbound requests
from the outside, limit such requests to the live hosts that
exist on those networks with a stateful firewall.

3.  Police the ND issue rate on the router. Yes, it means that
an ND attack could prevent some legitimate ND requests
from getting through, but, at least it prevents ND overflow and
the working hosts with existing ND entries continue to function.
In most cases, this will be virtually all of the active hosts on
the network.

All of these things can be done today with the knobs that exist.
The combination of them pretty much takes the wind out of any
ND table overflow attack. Yes, it involves some tradeoffs and
isn't a perfect solution. However, it is an effective mitigation.

Owen

Re: ARIN and the RPKI (was Re: AltDB?)

[Randy Bush]

>> had a lot of excellent software that did all sorts of impressive stuff
>> with the IRR, but I guess that all went into the bit bucket when UUnet
>> took over.
> we did require you to email nacr-list@ :) that didn't help?

and he processed on wednesday, not exactly optimal for ops.

if we are listing those who gave good blood for the irr, joe lawrence
and roy alcala, of mci and later level(3), would be at the top of my
list.

randy

Re: NIST IPv6 document

[Owen DeLong]

This would break dead-neighbor detection, but, I'm not sure that's necessarily
a problem for end hosts at the local router level.

It is touted as one of the IPv6 features, but, I'm not sure how valuable it is 
as
a feature.

Owen

On Jan 6, 2011, at 7:37 AM, Marcel Plug wrote:

> Perhaps we're reaching the point where we can say "We don't need an ND
> table for a /64 network".  If the ethernet MAC is embedded in the IPv6
> address, we don't need to discover it because we already know it.  If
> the IPv6 address has been manually configured on a host, perhaps that
> host should now accept traffic directed to the MAC that the lower 64
> bits of the IPv6 address would translate to.
> 
> Perhaps this idea has been discussed somewhere and discarded for its
> flaws, but if not, perhaps it should be :-).
> 
> Marcel
> 
> (First post by the way, go easy on me :-)
> 
> On Thu, Jan 6, 2011 at 10:19 AM, Jack Bates  wrote:
>> 
>> On 1/6/2011 12:26 AM, Joe Greco wrote:
>>> 
>>> A bunch of very smart people have worked on IPv6 for a very long
>>> time, and justification for /64's was hashed out at extended length
>>> over the period of years.
>> 
>> NDP should have been better designed. It still has the same problems we had
>> with ARP except the address pool has magnified it.
>> 
>> Routers should have 1) better methods for keeping ND tables low (and
>> maintaining only valid entries) or 2) better methods for learning valid
>> entries than unsolicited NDP requests.
>> 
>> This isn't to say the protocol itself is a waste, but it should have taken
>> in the concerns and developed the mitigation controls necessary as
>> recommendations to the implementers.
>> 
>> 
>> Jack
>> 
>> 

Re: IPv6 - real vs theoretical problems

[Jimmy Hess]

On Thu, Jan 6, 2011 at 4:00 PM, Deepak Jain  wrote:
> Wouldn't a number of problems go away if we just, for now, follow the IPv4 
> lessons/practices like allocating the number of addresses a customer needs ---
> say /122s or /120s that current router architectures know how to handle -- to 
> these boxes/interfaces today, while just reserving /64 or /56 spaces for
> each of them for whenever the magic day comes along where they can be used 
> safely?

Trying to run the IPv6 network using IPv4 addressing practices is
similar to upgrading your horse and buggy
to a sports car, and insisting on driving this car only on dirt roads,
 avoiding pavements at all costs,  due to the danger
of slipping,  if that was the lesson you learned with
horses and buggies.

You can probably do it,  and survive,  but that does not mean it will
be advantageous trouble free, advisable, or fun.

In this case, you will bring all the negatives (and more) that the
practice had with IPv4,  for questionable or no advantages.

It is advisable to look for much stronger reasons than "With
IPv4 we did it"  or   With IPv4 we ran into such and such
problem"   due to unique characteristics of IPv4 addressing
or other IPv4 conventions that had to continue to exist for
compatibility reasons, etc, etc.


--
-JH

NANOG 51 (Miami): ISP Security BOF

[Paul Scanlon]

Hi All, 

Happy New Year. 

NANOG 51 in Miami is rapidly approaching, January 30 - February 2, and we are 
looking for topics for the ISP Security BOF.  Eric Osterweil and I are going to 
be moderating this year with the assistance of Danny McPherson.  We would very 
much like to hear your feedback regarding topics of interest for the session.

If you have any security related topics that you would like to hear about, not 
hear about, or be willing to speak about, please let one of us know as soon as 
possible, feedback to the list obviously welcome.

Slides are welcome but not required. 

Much thanks, 

Eric & Paul 



 
Paul Scanlon
Arbor Networks
+1.303.477.0919 office
+1.303.810.7260 mobile
 

Re: NIST IPv6 document

[Jeff Wheeler]

On Thu, Jan 6, 2011 at 6:46 PM, Owen DeLong  wrote:
> On Jan 5, 2011, at 9:17 PM, Joe Greco wrote:
>> However, that's not the only potential use!  A client that initiates
>> each new outbound connection from a different IP address is doing
>> something Really Good.
> If hosts start cycling their addresses that frequently, don't you run the
> risk of that becoming a form of DOS on your router's ND tables?

Of course, Owen.  I replied to that specific point in Joe's post
earlier, although I have written so much on this thread, I have tried
to condense my replies, so anyone reading in thread mode may have
missed it.

The fact that Joe even makes that suggestion signals how little
understanding he has of the problem.  His idea would DoS his own
router.  There are many posts on this thread from folks who think of
themselves as expert, at least enough to try and tell me that I'm
wrong, when they lack basic understanding of how the forwarding
process works in operation.  That is what everyone should be afraid of
-- most of the "experts" aren't, and almost no one has practical
experience with a mission-critical IPv6 network, so conditions like
this remain unanalyzed.  It took a long time to discover a lot of
vulnerabilities as the Internet grew from academia to everyday
necessity.  We are all now making some obvious, unnecessary mistakes
with IPv6 deployments.

It is also crucial to understand that some platforms use the same
resources (in control plane or data plane) for ARP and NDP tables and
resolution, and this means that some dual-stack networks will see
their IPv4 networks melt down due to problems with their IPv6 network
design and implementation.  If you are dual-stack, this is probably
not a problem confined to v6 traffic flowing through your network; it
may also take out your mission-critical v4 services.  If you don't
know, then you need to admit you don't know and find out what the
failure mode of your routers is, before your network blows up in your
face.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: IPv6 - real vs theoretical problems

[Jeff Wheeler]

On Thu, Jan 6, 2011 at 5:00 PM, Deepak Jain  wrote:
> As far as I can tell, this "crippling" of the address space is completely 
> reversible, it's a reasonable step forward and the only "operational" loss is 
> you can't do all the address jumping and obfuscation people like to talk 
> about... which I'm not sure is a loss.

I largely agree with you, but my knowledge is similar to yours, and
does not extend to dealing with low-end CPE, dormitory LANs, hot
spots, or mobile networks.  I am by no means an authority in those
areas and I remain open to the possibility that there may be some
operational advantages to the IPv6 addressing concept for those users.
 The problem is there are very serious operational disadvantages for
you and I, but the standard tells us to do it anyway.  I would like
the hot spot or mobile guys to be able to choose /64 if they want to.
I need to choose otherwise, and customers expecting /64 as the
"standard" are going to be disappointed until the standard allows for
different choices.

I don't have an opinion on whether the address space is truly
"crippled."  If I did, I'm not sure it would be useful.  Classful
addressing ran out of gas in IPv4, so IPv6 has a huge number of bits
to hopefully avoid a repeat of that.  Okay, I can buy into that.
There are some major networks who aren't, though, and I think they
made a very conscious choice.  We won't know if it's a necessary
choice for a long time.

I will choose to devote my arguing-on-the-mailing-list time to topics
I think are more useful to discuss.  I do not think you will change
very many minds about IPv6 numbering schemes.  I hope I will change
some minds about the current safety of public /64 LANs and get more
folks talking to their vendors about it, which should give us some
kind of solution sooner, rather than later.  Choose your battles.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: NIST IPv6 document

[Owen DeLong]

On Jan 5, 2011, at 9:17 PM, Joe Greco wrote:

>>> It has nothing to do with "security by obscurity".
>> 
>> You may wish to re-read what Joe was saying - he was positing sparse addres=
>> sing as a positive good because it will supposedly make it more difficult f=
>> or attackers to locate endpoints in the first place, i.e., security through=
>> obscurity.  I think that's an invalid argument.
> 
> That's not necessarily security through obscurity.  A client that just
> picks a random(*) address in the /64 and sits on it forever could be
> reasonably argued to be doing a form of security through obscurity.
> However, that's not the only potential use!  A client that initiates
> each new outbound connection from a different IP address is doing
> something Really Good.
> 
If hosts start cycling their addresses that frequently, don't you run the
risk of that becoming a form of DOS on your router's ND tables?

Owen

Re: NIST IPv6 document

[Dobbins, Roland]

On Jan 7, 2011, at 1:20 AM, Owen DeLong wrote:

> You are mistaken... Host scanning followed by port sweeps is a very common 
> threat and still widely practiced in IPv4.

I know it's common and widely-practiced.  My point is that if the host is 
security properly, this doesn't matter; and that if it isn't secured properly, 
it's going to be found via hinted scanning and exploited, anyways.

> And there are ways to mitigate ND attacks as well.

As has been pointed out elsewhere in this thread, not to the degree of control 
and certainty needed in production environments.

> Sparse addressing is a win for much more than just rendering scanning 
> useless, but, making scanning useless is still a win.


Since it doesn't make scanning useless (again, hinted scanning), that 'win' is 
gone.  How else is it supposedly a win?



Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: NIST IPv6 document

[Dobbins, Roland]

On Jan 6, 2011, at 11:48 PM, Jack Bates wrote:

> It is not the intentional that we should fear, but the unintentional.

This is the single largest issue with IPv6 and the whole ND mess in a nutshell 
- unintentional DoS becomes much more likely.


Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: NIST IPv6 document

[Dobbins, Roland]

On Jan 6, 2011, at 11:28 PM,  wrote:

> Playing devil's advocate for a moment...

I don't see this as devil's advocacy, since I've said a) we're already hosed 
(i.e., what you said) and b), we're going to get even more hosed with IPv6.

;>


Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: NIST IPv6 document

[Dobbins, Roland]

On Jan 6, 2011, at 9:29 PM, Joe Greco wrote:

> Sorry, but I see this as not grasping a fundamental security concept.

I see it as avoiding a common security misconception.

> Making a host harder to find (or more specifically to address from remote) is 
> a worthwhile goal.

As I've stated repeatedly, I don't think that sparse addressing makes hosts 
harder to find, because hinted scanning will reveal them.

> Things like 4941 take that a lot further, and provide enough bits to make 
> both range scanning and scanning via learned addresses less useful 
> techniques. 

I believe RFC4941 to be positively evil, that the harm it will do in terms of 
complicating traceback and attribution far outweigh any supposed benefits 
(which are questionably, anyways, IMHO).

> This is basic security, whether or not you approve of it.  You're trying to 
> make it harder for bad guys.

My view is that it's basic security theater, which a) makes nothing harder for 
the bad guys, and b) has unpleasant side-effects which have the net effect of 
degrading one's overall security posture.



Roland Dobbins  // 

Most software today is very much like an Egyptian pyramid, with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.

  -- Alan Kay

Re: IPv6 - real vs theoretical problems

[Grant Phillips]

Hi Deepak,

I acknowledge and see the point made. There is a lot of dead space in the
IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more
to no.

Have you read this RFC? This is pretty satisfying in making me feel more
comfortable assigning out /48 and /64's. I can sleep at night now! :P

http://tools.ietf.org/html//rfc3177

Cheers,
Grant Phillips

On Fri, Jan 7, 2011 at 9:00 AM, Deepak Jain  wrote:

>
> Please, before you flame out, recognize I know a bit of what I am talking
> about. You can verify this by doing a search on NANOG archives. My point is
> to actually engage in an operational discussion on this and not insult (or
> be insulted).
>
> While I understand the theoretical advantages of /64s and /56s and /48s for
> all kinds of purposes, *TODAY* there are very few folks that are actually
> using any of them. No typical customer knows what do to do (for the most
> part) with their own /48, and other than autoconfiguration, there is no
> particular advantage to a /64 block for a single server -- yet. The left
> side of the prefix I think people and routers are reasonably comfortable
> with, it's the "host" side that presents the most challenge.
>
> My interest is principally in servers and high availability equipment
> (routers, etc) and other things that live in POPs and datacenters, so
> autoconfiguration doesn't even remotely appeal to me for anything. In a
> datacenter, many of these concerns about having routers fall over exist
> (high bandwidth links, high power equipment trying to do as many things as
> it can, etc).
>
> Wouldn't a number of problems go away if we just, for now, follow the IPv4
> lessons/practices like allocating the number of addresses a customer needs
> --- say /122s or /120s that current router architectures know how to handle
> -- to these boxes/interfaces today, while just reserving /64 or /56 spaces
> for each of them for whenever the magic day comes along where they can be
> used safely?
>
> As far as I can tell, this "crippling" of the address space is completely
> reversible, it's a reasonable step forward and the only "operational" loss
> is you can't do all the address jumping and obfuscation people like to talk
> about... which I'm not sure is a loss.
>
> In your enterprise, behind your firewall, whatever, where you want
> autoconfig to work, and have some way of dealing with all of the dead space,
> more power to you. But operationally, is *anything* gained today by giving
> every host a /64 to screw around in that isn't accomplished by a /120 or so?
>
> Thanks,
>
> DJ
>
>
>
>

Re: IPv6 - real vs theoretical problems

[Jack Bates]

On 1/6/2011 4:00 PM, Deepak Jain wrote:

In your enterprise, behind your firewall, whatever, where you want
autoconfig to work, and have some way of dealing with all of the dead
space, more power to you. But operationally, is*anything*  gained
today by giving every host a /64 to screw around in that isn't
accomplished by a /120 or so?


Today, I still like SLAAC. All my servers support specifying tokens for 
the host portion of the prefix. Pre-config, many utilize traditional 
SLAAC and end up in a range which is stateful firewall protected by the 
routers until such time as I can renumber them into the appropriate range.


Anyways, ARIN just approved my new allocation and I have to go renumber 
all those servers. At least assigning the new IPv6 addresses only 
requires a quick router edit. Application changes will take longer, of 
course, since we don't automatically generate DNS and other nifties.


The helpdesk, home, and customer trial networks should hopefully 
renumber with easy per my last renumbering trial. Link addressing, 
loopback changes, BGP, etc in the routers will still be a PITA.



Jack

IPv6 - real vs theoretical problems

[Deepak Jain]

Please, before you flame out, recognize I know a bit of what I am talking 
about. You can verify this by doing a search on NANOG archives. My point is to 
actually engage in an operational discussion on this and not insult (or be 
insulted).

While I understand the theoretical advantages of /64s and /56s and /48s for all 
kinds of purposes, *TODAY* there are very few folks that are actually using any 
of them. No typical customer knows what do to do (for the most part) with their 
own /48, and other than autoconfiguration, there is no particular advantage to 
a /64 block for a single server -- yet. The left side of the prefix I think 
people and routers are reasonably comfortable with, it's the "host" side that 
presents the most challenge.

My interest is principally in servers and high availability equipment (routers, 
etc) and other things that live in POPs and datacenters, so autoconfiguration 
doesn't even remotely appeal to me for anything. In a datacenter, many of these 
concerns about having routers fall over exist (high bandwidth links, high power 
equipment trying to do as many things as it can, etc). 

Wouldn't a number of problems go away if we just, for now, follow the IPv4 
lessons/practices like allocating the number of addresses a customer needs --- 
say /122s or /120s that current router architectures know how to handle -- to 
these boxes/interfaces today, while just reserving /64 or /56 spaces for each 
of them for whenever the magic day comes along where they can be used safely?

As far as I can tell, this "crippling" of the address space is completely 
reversible, it's a reasonable step forward and the only "operational" loss is 
you can't do all the address jumping and obfuscation people like to talk 
about... which I'm not sure is a loss. 

In your enterprise, behind your firewall, whatever, where you want autoconfig 
to work, and have some way of dealing with all of the dead space, more power to 
you. But operationally, is *anything* gained today by giving every host a /64 
to screw around in that isn't accomplished by a /120 or so?

Thanks,

DJ

 

Re: Problems with removing NAT from a network

[Matthew Kaufman]

On 1/6/2011 10:07 AM, Cameron Byrne wrote:


Skype is not defined in an IETF RFC, so saying you need an RFC to move
forward is bit confusing.
I don't see a disconnect at all. Skype also uses TCP and UDP, which are 
both subjects of RFCs.


That said, it doesn't need to be an RFC... just *a reliable way* of 
discovering the appropriate NAT64 prefix.

  There are several methods that just work
today,
Of the methods proposed in the survey draft, only one - the one that 
doesn't require the DNS64 spec or operator to make any changes (making 
an  lookup for something you know only has an A record) - works but 
*only if* the mapping scheme is such that it is possible to successfully 
derive a functional prefix and the scheme from the results of that query.


So in other words, *if* the query results in an  where, by 
inspection, you can guess where you'd need to stuff the IPv4 address 
bits *and* the resulting address causes the "right" NAT64 (if there's 
>1) to be used, then you're set.

I am all for standards, but a closed platforms generally find ways to
progress without or in spite of standards.  Skype is a closed
platform.
No question. And for all you know we might be working on other ways 
around this problem, but none of them as elegant as a defined 
specification for how to discover the presence of a NAT64 and the mapping.



There's lots of other apps that don't work. Skype is just the squeaky wheel
because it is so popular.


Please make a list and let us know.  Otherwise, this is just hand
waving like the IPv4 literals sites.
I'll start with "peer to peer connectivity using RTMFP in Flash Player" 
and "BitTorrent". Both Flash Player and BitTorrent are fairly popular on 
desktop platforms.


I'm sure there's more.



My advice to Skype is to come up with a solution to work for IPv6-only
clients. That is my advice to all apps and all content.  IPv6-only
clients are an obvious reality in an IPv4 exhausted world.
That's not the problem... the problem is reaching the existing base of 
IPv4 clients from those IPv6-only clients without making Skype relay all 
the traffic via servers somewhere, as I'm sure you know.



You cannot seriously come to a network operators support mailing list
and say that the network guys have to keep investing in network tweaks
while you wait for a standards body to solve a problem for your closed
non-standard applications.
I've been on this list since approximately the time it was formed, so 
I'm not coming here to ask for something. Just pointing out what will break.



I also assure you, many mobile operators are pursuing this NAT64 path
for the same reason I am.
Randy Bush would encourage his competitors to do just as you've done, 
I'm sure.


Matthew Kaufman

The FCC on IPv6

[Steven Bellovin]

http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-303870A1.pdf

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: NIST IPv6 document

[Jeff Wheeler]

On Thu, Jan 6, 2011 at 7:34 AM, Robert E. Seastrom  wrote:
> I continue to believe that the "allocate the /64, configure the /127
> as a workaround for the router vendors' unevolved designs" approach,

As a point of information, I notice that Level3 has deployed without
doing this, e.g. they have densely packed /126 subnets which are
conceptually identical to /30s for infrastructure and point-to-point.
I am still taking your conservative approach, as I see no operational
disadvantage to it; but opinions must differ.

On Thu, Jan 6, 2011 at 11:28 AM,   wrote:
> And the "ZOMG they can overflow the ARP/ND/whatever table" is a total red
> herring - you know damned well that if a script kiddie with a 10K node botnet
> wants to hose down your network, you're going to be looking at a DDoS, and it
> really doesn't matter whether it's SYN packets, or ND traffic, or forged ICMP
> echo-reply mobygrams.

I agree, botnets are large enough to DDoS most things.  However, with
the current state of ARP/ND table implementations in some major
equipment vendors' routers, combined with standards-compliant
configuration, it doesn't take a botnet.  I could DoS your subnet (or
whole router) without a botnet, say, using an IPv6 McDonald's Wi-Fi
hotspot.  That is very much a legitimate concern.  A few hundred
packets per second will be enough to cripple some platforms.

On Thu, Jan 6, 2011 at 1:20 PM, Owen DeLong  wrote:
> And there are ways to mitigate ND attacks as well.

No, Owen, there aren't.  The necessary router knobs do not exist.  The
"Cisco approach" is currently to police NDP on a per-interface basis
(either with per-int or global configuration knob) and break NDP on
the interface once that policer is exceeded.  This is good (thanks,
Cisco) because it limits damage to one subnet; but bad because it
exemplifies the severity of the issue: the "Cisco solution" is known
to be bad, but is less bad than letting the whole box break.  Cisco is
not going to come up with a magic knob because there isn't any -- with
the current design, you have to pick your failure modes and live with
them.  That's not good and it is not a Cisco failing by any means, it
is a design failing brought on by the standards bodies.


I would also like to reply in public to a couple of off-list
questions, because the questions are common ones, the answers are not
necessarily cut-and-dry (my opinion is only one approach; there are
others) and this is the kind of useful discussion needed to address
this matter.  I will leave out the names of the people asking since
they emailed me in private, but I'm sure they won't mind me pasting
their questions.

Anonymous Questioner:
>What do you think about using only link-local ip addresses on the 
>infrastructure links please?
I can't think of any potential drawbacks do you?

This can be done, but then you don't have a numbered next-hop for
routing protocols.  That's okay if you re-write it to something else.
Note that link-local subnets still have an NDP table, and if that
resource is exhausted due to attacks on the router, neighbors with
link-local addressing are not immune.

link-local scope offers numerous advantages which are mostly
out-weighed by more practical concerns, like, how hard it is going to
be to convince the average Windows sysadmin to configure his machine
to suit such a design, instead of just taking his business elsewhere.
Not a problem for enterprise/gov/academia so much, but a problem for
service providers.

On Thu, Jan 6, 2011 at 3:43 PM, Jack Bates  wrote:
> Given that the incomplete age is to protect the L2 network from excessive
> broadcast/multicast, I agree that aging them out fast would be a wiser

I agree that it would be nice to have such a knob.  I bet you and I
would make different choices about how to use it, which is the whole
point of having a knob instead of a fixed value.

> I'm still a proponent for removing as needed requests like this, though. It
> would have been better to send a global "everyone update me" request
> periodically, even if triggered by an unknown entry, yet limited to only
> broadcasting once every 10-30 seconds.

> Given that all requests for an unknown arp/ND entry results in all hosts on
> the network checking, it only makes sense for all hosts to respond. There

This isn't a new idea and it has its own set of problems, which are
well-understood.  IPv6 NS messages are more clever than ARP, though,
and are sent to a computed multicast address.  This means that the
number of hosts which receive the message is minimized.  See RFC2461
section 2.3 for the quick introduction.

NDP is better than ARP.  However, your statement that NDP has all (I'd
like to say some) of the same problems as ARP but the increased subnet
size has magnified them, is basically correct.  NDP does some things a
lot better than ARP, but not this.  It's important to realize that
when this stuff was designed, there were few hardware-based layer-3
routers for IPv4.  The biggest networks (Sprin

Re: NIST IPv6 document

[Jack Bates]

On 1/6/2011 2:47 PM, William Allen Simpson wrote:

Google tells me that draft-ietf-sip-discovery-03.txt is still on-line.
I've not found my -04, -05, or -06 on-line, so I've occasionally been
looking through old backups lately as time allows. Sadly, those systems
are long dead, and finding actual systems to read my old data makes the
recovery process rather slow.



"   When a host or router needs the location of a target host on the
   local media, it sends a media multicast solicitation for the location
   of the host, followed by a media multicast of the original data
   packet.  The target node issues an advertisement which indicates its
   current reachability.
"

Umm, so it sends a data packet to everyone instead of waiting and 
sending a unicast packet? Seems rather insecure if that packet wasn't 
encrypted, not to mention noisy. In addition, I'd hate to see what 
happens when more than one packet arrives prior to the target node's 
advertisement being received.


Contrary to my last email (where I didn't consider mobile devices and 
similar which do have memory restrictions), I agree with the as-needed 
basis, except for routers. A router should have all necessary 
information and not just as-needed. One could argue that routers can't 
process that much data, but given the trends I've seen in IOS and other 
vendors of refreshing arp every 10s or less, I'm pretty sure they can 
handle it.


To streamline the process and since we are using multicast, hosts can 
just tell the router multicast address who they are to quickly update 
all local router ND caches, and could just as easily expire an address 
from the cache. The usual options we use for securing ARP could still 
apply in this scenario.



Jack

Re: ARIN and the RPKI (was Re: AltDB?)

[Christopher Morrow]

On Thu, Jan 6, 2011 at 2:03 PM, Kevin Oberman  wrote:
>> Date: Thu, 06 Jan 2011 14:24:01 +0900
>> From: Randy Bush 
>>
>> > I think ACLs here means prefix-lists ... or I hope that's what Randy
>> > meant?
>>
>> sorry.  yes, irr based prefix lists.  and, sad to say, data which have
>> sucked for 15+ years.  i was the poster child for the irr, and it just
>> never took off.
>>
>> [ irr data are pretty bad except for some islands where there is culture
>>   of maintining them.  and, as it is a global internet, islands don't
>>   help much.  europe and japan are two islands with better than the
>>   average irr data quality.  and they have rpki rolling to varied
>>   degrees. ]
>
> The day of reasonable accuracy of the IRR ended when UUnet bought
> ANI. Since ANI actually used the IRR to generate there router configs

s/NI/NS/g

> and ANI was pretty big, people were really forced to register. Curtis

s/NI/NS/

> had a lot of excellent software that did all sorts of impressive stuff
> with the IRR, but I guess that all went into the bit bucket when UUnet
> took over.

we did require you to email nacr-list@ :) that didn't help?

All sed jokes aside, would having attestations that the route you see
is part of a block assigned by IANA to ARIN and from ARIN to UUNET and
from UUNET to JoesCrabShuckers make sense to you? (and to your router
policy provided the router policy engine and code worked)

The efficacy of the IRR isn't at question, the ability to assure with
some level of reasonableness that the thing you see (and eventually
it's path to get to you) is "valid" is what the RPKI system is
building toward.

-Chris

> Very, very sad!

(tears were shed)

> --
> R. Kevin Oberman, Network Engineer
> Energy Sciences Network (ESnet)
> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
> E-mail: ober...@es.net                  Phone: +1 510 486-8634
> Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
>

Re: NIST IPv6 document

[William Allen Simpson]

On 1/6/11 1:47 AM, Paul Ferguson wrote:

As someone who has been immersed in security for many years now, and having
previously been very intimately involved in the network ops community for
equally many years, I have to agree with Roland here. Just because a lot of
smart people have worked on IPv6 for many years does not mean that the
security issues have been equally well thought out.

...

This is not meant as a slight to anyone -- just a realization of looking at
security from a real-world perspective. It seems to always have to get
"bolted on" as an afterthought, instead of baked-in from the beginning.


I've not read everything in this thread yet.  So, this may have already
been mentioned.  But Security *was* baked-in from the beginning of IPv6.
IT WAS TAKEN OUT!

I was one of the original IPng PIPE->SIP->SIPP->IPv6 designers.  We knew
about *all* of these problems mentioned thus far in this thread.

IPsec was originally designed for SIP->SIPP->IPv6, and I back-ported it to
IPv4 after IPv6 was hijacked by committee.

As to Neighbor Discovery, the original specifications eliminated ARP, DHCP,
and OSPF, *and* routers knew all hosts on the local net, *and* both hosts
and routers automatically renumbered.  Everything that folks have asked for
thus far.

Google tells me that draft-ietf-sip-discovery-03.txt is still on-line.
I've not found my -04, -05, or -06 on-line, so I've occasionally been
looking through old backups lately as time allows.  Sadly, those systems
are long dead, and finding actual systems to read my old data makes the
recovery process rather slow.

Anyway, don't blame the original designers.  We knew what we were doing!
Blame the vendors (and their lackeys) that had vested interests in making
IPv6 into IPv4 with bigger addresses, and *removing* security.

Re: NIST IPv6 document

[Jack Bates]

On 1/6/2011 2:17 PM, TJ wrote:


Again, off the top of my head, maybe - when under duress - age out the
incomplete ND table entries faster.



Given that the incomplete age is to protect the L2 network from 
excessive broadcast/multicast, I agree that aging them out fast would be 
a wiser solution, if you must have it to begin with. It is better to 
increase traffic loads.


I'm still a proponent for removing as needed requests like this, though. 
It would have been better to send a global "everyone update me" request 
periodically, even if triggered by an unknown entry, yet limited to only 
broadcasting once every 10-30 seconds.


Given that all requests for an unknown arp/ND entry results in all hosts 
on the network checking, it only makes sense for all hosts to respond. 
There may be other concerns, but I'm actually not against all hosts 
responding via multicast to all other hosts, so that a full mesh can be 
established ahead of time. The idea of minimizing the table to an 
as-needed basis should not have continued with IPv6. Special provisions 
could be handled when dealing with proxy-ND, but I'm not sure that is 
needed either.



Jack

Re: NIST IPv6 document

[TJ]

On Wed, Jan 5, 2011 at 13:14, Jeff Wheeler  wrote:

> On Wed, Jan 5, 2011 at 1:02 PM, TJ  wrote:
> > Many would argue that the version of IP is irrelevant, if you are
> permitting
> > external hosts the ability to scan your internal network in an
> unrestricted
> > fashion (no stateful filtering or rate limiting) you have already lost,
> you
>
> How do you propose to rate-limit this scanning traffic?  More router
> knobs are needed.  This also does not solve problems with malicious
> hosts on the LAN.
>

Off the top of my head, maybe just slow down the generation of new NS
attempts when under attack (without impacting the NUD-based NS).



>
> A stateful firewall on every router interface has been suggested
> already on this thread.  It is unrealistic.
>
> > Even granting that, for the sake of argument - it seems like it would not
> be
> > hard for $vendor to have some sort of "emergency garbage collection"
> > routines within their NDP implementations ... ?
>
> How do you propose the router know what entries are "garbage" and
> which are needed?  Eliminating active, "good" entries to allow for
> more churn would make the problem much worse, not better.


Again, off the top of my head, maybe - when under duress - age out the
incomplete ND table entries faster.


/TJ

Re: ARIN resource certification service update

[Randy Bush]

hi john, sorry to disturb your cruise.

as you know, from the get go, the hierarchic nature of the pki has
worried the ops folk involved.  this is why documents such as
draft-ietf-sidr-rpki-origin-ops-00.txt say things such as

   RPKI-based origin validation has been designed so that, with prudent
   local routing policies, there is no liability that normal Internet
   routing is threatened by unprudent deployment of the global RPKI, see
   Section 5.

...

5.  Routing Policy

   Origin validation based on the RPKI merely marks a received
   announcement as having an origin which is Validated, Unknown, or
   Invalid.  How this is used in routing is up to the router operator's
   local policy.  See [I-D.pmohapat-sidr-pfx-validate].

   Reasonable application of local policy should be designed eliminate
   the threat of unroutability of prefixes due to ill-advised or
   incorrect certification policies.

   As origin validation will be rolled out over years coverage will be
   spotty for a long time.  Hence a normal operator's policy should not
   be overly strict, perhaps preferring valid announcements and giving
   very low preference, but still using, invalid announcements.

   Some may choose to use the large Local-Preference hammer.  Others
   might choose to let AS-Path rule and set their internal metric, which
   comes after AS-Path in the BGP decision process.

   Certainly, routing on unknown validity state will be prevalent for a
   long time.

   Until the community feels comfortable relying on RPKI data, routing
   on invalid origin validity, though at a low preference, may be
   prevalent for a long time.

   Announcements with valid origins SHOULD be preferred over those with
   unknown or invalid origins.

   Announcements with unvalidatable origins SHOULD be preferred over
   those with invalid origins.

   Announcements with invalid origins MAY be used, but SHOULD be less
   preferred than those with valid or unknown.

of course, in the US, this will not prevent litigation.  nothing will.
it's a mental disease.

randy

Re: NIST IPv6 document

[TJ]

On Wed, Jan 5, 2011 at 17:44, Dobbins, Roland  wrote:

>
> On Jan 6, 2011, at 1:02 AM, TJ wrote:
>
> >  if you are permitting external hosts the ability to scan your internal
> network in an unrestricted
> > fashion
>
> DCN aside, how precisely does one define 'internal network' in, say, the
> context of the production network of a broadband access SP, or
> hosting/colocation/VPS/IaaS SP?
>

In that scenario,  "internal" would be the SP's network itself - traffic
actually directed to their infrastructure.

Re: ARIN and the RPKI (was Re: AltDB?)

[Kevin Oberman]

> Date: Thu, 06 Jan 2011 14:24:01 +0900
> From: Randy Bush 
> 
> > I think ACLs here means prefix-lists ... or I hope that's what Randy
> > meant?
> 
> sorry.  yes, irr based prefix lists.  and, sad to say, data which have
> sucked for 15+ years.  i was the poster child for the irr, and it just
> never took off.
> 
> [ irr data are pretty bad except for some islands where there is culture
>   of maintining them.  and, as it is a global internet, islands don't
>   help much.  europe and japan are two islands with better than the
>   average irr data quality.  and they have rpki rolling to varied
>   degrees. ]

The day of reasonable accuracy of the IRR ended when UUnet bought
ANI. Since ANI actually used the IRR to generate there router configs
and ANI was pretty big, people were really forced to register. Curtis
had a lot of excellent software that did all sorts of impressive stuff
with the IRR, but I guess that all went into the bit bucket when UUnet
took over.

Very, very sad!
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

Re: Verizon DSL Transport Contact?

[Robert Bonomi]

Re: NIST IPv6 document

[Owen DeLong]

On Jan 5, 2011, at 7:18 PM, Dobbins, Roland wrote:

> 
> On Jan 6, 2011, at 10:08 AM, Joe Greco wrote:
> 
>> Packing everything densely is an obvious problem with IPv4; we learned early 
>> on that having a 48-bit (32 address, 16 port) space to scan made
>> port-scanning easy, attractive, productive, and commonplace.
> 
> I don't believe that host-/port-scanning is as serious a problem as you seem 
> to think it is, nor do I think that trying to somehow prevent host from being 
> host-/port-scanned has any material benefit in terms of security posture, 
> that's our fundamental disagreement.
> 
You are mistaken... Host scanning followed by port sweeps is a very common 
threat and still widely practiced in IPv4.

> If I've done what's necessary to secure my hosts/applications, 
> host-/port-scanning isn't going to find anything to exploit 
> (overly-aggressive scanning can be a DoS vector, but there are ways to 
> ameliorate that, too).
> 
And there are ways to mitigate ND attacks as well.

> If I haven't done what's necessary to secure my hosts/applications, one way 
> or another, they *will* end up being exploited - and the faux 
> security-by-obscurity offered by sparse addressing won't matter a bit.
> 
Sparse addressing is a win for much more than just rendering scanning useless, 
but, making scanning useless is still a win.

Owen

Re: Problems with removing NAT from a network

[Cameron Byrne]

On Thu, Jan 6, 2011 at 9:18 AM, Matthew Kaufman  wrote:
> On 1/5/2011 9:39 PM, Cameron Byrne wrote:
>>
>> I understand my users pretty well, they only go to a few web pages ...
>> its the nature of the net.  I assure you, i am not taking any undue
>> risk with regards to web.  Try our friendly user trial and give me
>> your feedback, thats why i am running it.
>
> I'm not particularly surprised that a mobile client platform has a different
> access pattern than desktop users... not a whole lot of mobile BitTorrent
> clients yet, for instance.
>>
>> Ah Skype.  According to your web page you work at Skype.  Skype is a
>> well known IPv6 spoiler application.  In fact, in the IETF and many
>> other circles, Skype is the only app that we can't seem to get to work
>> with IPv6.  Are you here to help with that or to tell us that we need
>> to keep IPv4 around indefinitely?
>
> Indeed, I work at Skype now and Adobe (developing RTMFP) before that.
>
> At this point (because not everyone has IPv6) this class of applications
> (along with BitTorrent and ICE-using VoIP apps) needs to be able to use your
> NAT64 to talk to peers that are IPv4-only. To do that, they need to be able
> to discover your NAT64 even though they're not doing DNS lookups to find the
> IPv4 addresses of peers.
>
> This will take 1) a way to do this and 2) upgrades of the apps to take
> advantage of it. It is impossible to do #2 until #1 is solved.
>
> There's been discussion in BEHAVE about this topic...
> draft-korhonen-behave-nat64-learn-analysis for instance. I even proposed a
> solution that wasn't raised in that or previous documents here:
> http://www.ietf.org/mail-archive/web/behave/current/msg09050.html (which I
> suppose, since it hasn't been mentioned elsewhere, should be written up as a
> draft if/when I have some free time)
>

Skype is not defined in an IETF RFC, so saying you need an RFC to move
forward is bit confusing.  There are several methods that just work
today,

I am all for standards, but a closed platforms generally find ways to
progress without or in spite of standards.  Skype is a closed
platform.

>>  Skype should not be the IPv6 spoiler app when
>> NEARLY EVERYTHING ELSE WORKS.  Read the thread i mentioned, real
>> users, real developers, real network that is IPv6-only.  Notice that
>> things generally work, those folks have hacked their way to perhaps
>> even making Skype work.
>
> There's lots of other apps that don't work. Skype is just the squeaky wheel
> because it is so popular.
>

Please make a list and let us know.  Otherwise, this is just hand
waving like the IPv4 literals sites.  I have had people on various
mailing list tell me all things they think won't work, but in my own
experience and in the experience of my beta users, who are publicly
documenting their efforts on the support boards, things work well.
Yes, some things don't work due the fact that it is a beta and
something don't work due to the fact that it is IPv6-only, but they
are not show stoppers for the business.

As a user, i have been using IPv6-only on Symbian for 9 months without
an issue.  The service works as i would expect it to with IPv4, no
user perceived differences.  Skype is a squeaky wheel, but most  (99%)
things users do works fine.  As mentioned, in mobile, 95+% of the
traffic is web and email.  And, most "apps", are also just web and
email.

My advice to Skype is to come up with a solution to work for IPv6-only
clients. That is my advice to all apps and all content.  IPv6-only
clients are an obvious reality in an IPv4 exhausted world.

You cannot seriously come to a network operators support mailing list
and say that the network guys have to keep investing in network tweaks
while you wait for a standards body to solve a problem for your closed
non-standard applications.

I won't go into my diatribe about why dual-stack is not an obvious
choice in mobile, you can check the video of it at the google IPv6
conference in 2010.  If you have further questions, i am glad to help
you understand and entertain your ideas off list.  The main point is
the dual-stack and substantially more expensive and the IPv4 part of
dual-stack is run out of addressesprivate, public, bogon.

http://www.youtube.com/watch?v=1GlRgaFriYU#t=15m38s

>
>>
>> Seriously, 95+% of my traffic is web and email, and STUN and ICE don't
>> matter much to grandma as long as m.v6.facebook.com loads.
>
> See my above comment about how I'm not surprised, given the specific client
> population.
>>
>> As long as dual-stack is around, the app vendors don't have to move
>> and network guys have to dream up hacks to support these legacy apps
>> (CGN ).
>
> Dual-stack + NAT44 has a lot fewer unsolved corner cases *and* doesn't
> require apps to be upgraded to do discovery of the NAT64 prefix(es) (which,
> for some legacy apps that are no longer under development will never
> happen).
>

Dual-stack cost the mobile network operator 2x in the packet core,
check the Youtube  vid

Re: Problems with removing NAT from a network

[Matthew Kaufman]

On 1/5/2011 9:39 PM, Cameron Byrne wrote:


I understand my users pretty well, they only go to a few web pages ...
its the nature of the net.  I assure you, i am not taking any undue
risk with regards to web.  Try our friendly user trial and give me
your feedback, thats why i am running it.
I'm not particularly surprised that a mobile client platform has a 
different access pattern than desktop users... not a whole lot of mobile 
BitTorrent clients yet, for instance.


Ah Skype.  According to your web page you work at Skype.  Skype is a
well known IPv6 spoiler application.  In fact, in the IETF and many
other circles, Skype is the only app that we can't seem to get to work
with IPv6.  Are you here to help with that or to tell us that we need
to keep IPv4 around indefinitely?

Indeed, I work at Skype now and Adobe (developing RTMFP) before that.

At this point (because not everyone has IPv6) this class of applications 
(along with BitTorrent and ICE-using VoIP apps) needs to be able to use 
your NAT64 to talk to peers that are IPv4-only. To do that, they need to 
be able to discover your NAT64 even though they're not doing DNS lookups 
to find the IPv4 addresses of peers.


This will take 1) a way to do this and 2) upgrades of the apps to take 
advantage of it. It is impossible to do #2 until #1 is solved.


There's been discussion in BEHAVE about this topic... 
draft-korhonen-behave-nat64-learn-analysis for instance. I even proposed 
a solution that wasn't raised in that or previous documents here: 
http://www.ietf.org/mail-archive/web/behave/current/msg09050.html (which 
I suppose, since it hasn't been mentioned elsewhere, should be written 
up as a draft if/when I have some free time)



  Skype should not be the IPv6 spoiler app when
NEARLY EVERYTHING ELSE WORKS.  Read the thread i mentioned, real
users, real developers, real network that is IPv6-only.  Notice that
things generally work, those folks have hacked their way to perhaps
even making Skype work.
There's lots of other apps that don't work. Skype is just the squeaky 
wheel because it is so popular.





Seriously, 95+% of my traffic is web and email, and STUN and ICE don't
matter much to grandma as long as m.v6.facebook.com loads.
See my above comment about how I'm not surprised, given the specific 
client population.


As long as dual-stack is around, the app vendors don't have to move
and network guys have to dream up hacks to support these legacy apps
(CGN ).
Dual-stack + NAT44 has a lot fewer unsolved corner cases *and* doesn't 
require apps to be upgraded to do discovery of the NAT64 prefix(es) 
(which, for some legacy apps that are no longer under development will 
never happen).


NAT64/DNS64 is an interesting experiment that works for >95% of the web. 
But it isn't really a solution unless "the web" is all you care about.


Matthew Kaufman

Re: NIST IPv6 document

[Jack Bates]

On 1/6/2011 10:44 AM, Joe Greco wrote:

On the flip side, however, I would point out that attackers have had vastly
more resources made available to them in part *because* IPv4 has been so
easily scanned and abused.  To be sure, a lot of viruses have spread via
e-mail spam and drive-by downloads, and sparse addressing will not prevent
script kiddies from banging away on ssh brute force attacks against
www.yoursite.com.  But there's been a lot of spread through stupidity as
well.



A randomly setup ssh server without DNS will find itself brute force 
attacked. Darknets are setup specifically for detection of scans. One 
side effect of v6, is determining how best to deploy darknets, as we 
can't just take one or two blocks to do it anymore. We'll need to 
interweave the darknets with the production blocks. I wish it was 
possible via DHCPv6-PD to assign a block minus a sub-block (hey, don't 
use this /64 in the /48 I gave you). It could be that darknets will have 
to go and flow analysis is all we'll be left with.



Jack

Re: NIST IPv6 document

[Jack Bates]

On 1/6/2011 10:28 AM, valdis.kletni...@vt.edu wrote:


And the "ZOMG they can overflow the ARP/ND/whatever table" is a total red
herring - you know damned well that if a script kiddie with a 10K node botnet
wants to hose down your network, you're going to be looking at a DDoS, and it
really doesn't matter whether it's SYN packets, or ND traffic, or forged ICMP
echo-reply mobygrams.



My personal concern is not the intentional DDoS, but the idiotic side 
effects of unintentional idiocy. Nachi was nicer than Blaster to the 
host, but it unintentionally DDoS'd many networks that couldn't handle 
the load.


How many morons will scan a /64 out of curiosity? Even if they get bored 
after 1-2 hours, the effects of such a scan on the ND table could be 
catastrophic in the protocol's default behavior.


How many virus writers will utilize a hinted scan technique, which could 
still end up scanning thousands of v6 addresses per /64 and following 
consecutive /64s which likely are handled by the same router?


It is not the intentional that we should fear, but the unintentional.


Jack

Re: NIST IPv6 document

[Joe Greco]

> On Jan 6, 2011, at 1:51 PM, Joe Greco wrote:
> > There are numerous parallels between physical and electronic security.
> > Let's just concede that for a moment.
> 
> I can't, and here's why:
> 
> 1.In the physical world, attackers run a substantial risk of being 
> caught,=
>  and of tangible, severe penalties if that eventuality comes to pass; in th=
> e online world, the risk of being caught is nil.

That's not true, and we see examples of it happening periodically.

> 2.In the physical world, attackers have a limited number and variety of 
> re=
> sources they can bring to bear; in the online world, the attackers have nea=
> r-infinite resources, for all practical purposes.

No, they don't.  They have a different set of resources.  They may be able
to fill your transit connections, but they probably cannot cause your line 
cards to start on fire, or your switches to come unscrewed from the rack,
things that real-world attackers can do.  In the physical world, attackers
have a near-infinite selection of attacks.  If I really want into your house,
for example, I can get there.  It might be by breaking through a door, or by
smashing a window, or (my favorite) by taking my Sawzall and a demolition bit
and putting a hole through your wall.  I can convince your kids that I'm a
policeman and there's a bad man in the house.  I can sleep with your wife and
gain access that way.  We see parallels in the online world, different, but
vulnerable as well.

> 3.In the physical world, the attackers generally don't posses the ability 
> =
> nor the desire to bring the whole neighborhood crashing down around the ear=
> s of the defenders; in the online world, they almost always have the abilit=
> y, and often the desire, to do just that.

So?  That's a matter of what the goal of the attack is.  In the physical world,
we do indeed have some attackers who possess the ability and desire to bring
whole neighborhoods crashing down; we lost some great real estate about ten
years ago in lower Manhattan due to such nutjobs, and suicide bombers are a
fact of life in some areas of the world.  Electronic attacks are more likely 
to result in electronic "crashing down" for a variety of reasons, one of which 
is that overwhelming things electronically is fairly easy and effective, but
the flip side to that is that the resulting damage is often just a short-term
outage (PayPal, Mastercard, etc., all seem to be back online after recent
attacks).

The fact that there are some differences between physical and electronic 
security doesn't mean that there aren't also many parallels.  It's probably
hard to permanently destroy electronic infrastructure.  Certain attacks, such
as on the facility (kill the cooling, rapidly toggle the power, etc) might be
effective in that sense.  It's easier to destroy stuff during a physical 
attack.  So that's different, fine.  However, the point of security is still
to try to convince a bad guy to go elsewhere, to find an easier target.  
When he has it out for you, though, it's basically a matter of whether or
not he's willing to do what is necessary.  That concept works for both the
real world and for the online world.

> > Making it harder to scan a network *can* and *does* deter certain classes=
>  of attacks.=20
> 
> But as I've tried to make clear, a) I don't believe that sparse addressing =
> does in fact make it harder to scan the network, due to hinted scanning via=
>  DNS/routing/whois/ND/multicast,

You don't have to believe it.  It certainly doesn't make it harder in all
cases, either.  No amount of randomization will make "www.foobar.com" less
readily identifiable with an  pointing at it.  But there are other use
cases.  Consider, for example, /56 allocations to end users on a service
provider's network.  There'll be no DNS/routing/whois vectors there; there
might be ND/multicast vectors of some sort.  The point is, though, that the
guy with a /56 at the end of a cablemodem will be effectively unscannable
if he's using randomly-selected 4941 IP addresses.  And getting all righteous
about firewall configurations and how he should have a transparent proxying
firewall is fine, I agree, but the *real* world is that when his buddy tells
him that he's having problems running WoW because of the firewall and he can
do ${FOO} to turn it off, he's going to do that, because users are results-
oriented in a way that makes all of us groan.

So what I am looking for now is for you to explain to me how an end-user 
with a /56 (or even a /64!) on a cablemodem is not "harder to scan".

> b) I believe that pushing the attackers to=
> wards hinted scanning will have severe second-order deleterious effects on =
> DNS/network infrastructure/whois, resulting in an overall loss in terms of =
> security posture, 

I don't buy that.  I believe that things like DNS and whois are natural
candidates for additional layers of application level protection, and that
application level protection scales more 

Re: NIST IPv6 document

[Valdis . Kletnieks]

On Thu, 06 Jan 2011 07:50:17 GMT, "Dobbins, Roland" said:
> In my view, an IPv6 Internet is considerably less secure, and inherently less
> securable, than the present horribly insecure and barely securable IPv4
> Internet;

Playing devil's advocate for a moment...

Even if an IPv6 network is 10 times as insecure as a similarly configured IPv4
network, they are both as dust motes in a tornado given the incredibly insecure
state of most endpoints on the network.  Last I looked, there's a lot less
scanning of subnets looking for probably-firewalled-by-default-anyhow systems
because it's just so much easier to to whack the systems in a drive-by attack
when the system visits a compromised web page...

And the "ZOMG they can overflow the ARP/ND/whatever table" is a total red
herring - you know damned well that if a script kiddie with a 10K node botnet
wants to hose down your network, you're going to be looking at a DDoS, and it
really doesn't matter whether it's SYN packets, or ND traffic, or forged ICMP
echo-reply mobygrams.



pgpuNxYHVMipn.pgp
Description: PGP signature

Re: NIST IPv6 document

[Lamar Owen]

On Thursday, January 06, 2011 10:51:27 am Jack Bates wrote:
> There have been many implementations, mostly for 
> security reasons, but also helping with this problem by implementing a 
> "router MUST NOT send unsolicited arp requests". It's important that 
> routers learn their table in another fashion.

Yeah, that's more succinct than what I said, but I think you're saying the same 
thing.

ARIN resource certification service update

[John Curran]

On Jan 5, 2011, at 5:32 PM, Randy Bush wrote:

>> 1) If ARIN doesn't provide the level of authentication you desire, as
>> an ARIN member you should send a note to ppml each day until it's
>> available
> 
> this is not address policy.  this is ops.  surely one does not have to
> dirty one's self with the ppml list to get an ops fix done in arin.  it
> is not address policy.
> 
> i have a rumor that arin is delaying and possibly not doing rpki that
> seems to have been announced on the ppml list (to which i do not
> subscribe).  as it has impact on routing, not address policy, across
> north america and, in fact the globe, one would think it would be
> announced and discussed a bit more openly and widely.

Randy - 

   Excellent point; my apologies for not realizing this sooner and
   posting some information directly for consideration by the NANOG 
   community.

   Attached is a message from the arin-discuss mailing list which 
   has some more context; please feel free to discuss this on the 
   arin-discuss mailing list or here on NANOG (as appropriate)

Thanks!
/John

Begin forwarded message:

> From: John Curran 
> Date: January 6, 2011 11:08:39 AM EST
> To: "George, Wes E [NTK]" 
> Cc: "arin-disc...@arin.net" 
> Subject: Re: [arin-discuss] Important Update Regarding Resource Certification
> 
> On Jan 6, 2011, at 9:32 AM, George, Wes E [NTK] wrote:
> 
>> There have been some threads about this on NANOG in the last few days. Can
>> we get a bit clearer explanation of what the specific security concerns are
>> and why they are delaying things? It may also make sense for someone from
>> ARIN to post to NANOG with an explanation as well. If there are security
>> concerns, it is something that the community should be aware of in case
>> other RIRs or the SIDR WG need to be considering those issues as well.
>> 
>> Thanks, 
>> Wes George
> 
> George - 
> 
>   The security concerns are not specificly related to the RPKI
>   protocol, but inherent implications of any service that might 
>   be heavily relied upon for real-time network operations, i.e.
>   I don't think it's a SIDR WG matter, but simply part of the
>   due diligence associated with the service as noted below.
> 
>   While the RIRs presently provide services which are used to 
>   support operations (such as WHOIS and Reverse DNS services),
>   failure of RIR resource certification services could have 
>   some very significant consequences, particularly in the case
>   of incorrect data as opposed to simply unavailable data.  
>   There are some potential liability implications of operating 
>   such a service that ARIN is presently reviewing in depth.  I 
>   need to also note that these issues exist even in the case of 
>   a perfectly secure and operational service, in that an error
>   by an ISP using ARIN's services (e.g. having entered the wrong 
>   AS number into a ROA for a major customer) could result in 
>   ARIN needing to readily "prove" the integrity of its resource 
>   certification system as well as fidelity of performance against 
>   the operators request.
> 
>   This has led ARIN to consider some aspects of its resource 
>   certification design, specifically to mitigate potential risks
>   in the areas of non-repudiation and multi-party controls. Even
>   so, the ultimate decision in these matters lies with the ARIN 
>   Board, as there is always going to be residual risk associated
>   with any operations-related service provided by ARIN (note also
>   that we have also discussed these issues with the other RIRs, 
>   but as they don't operate in ARIN's highly-litigous region, it   
>   is not necessarily a similar priority for their consideration)
> 
>   To the extent that ARIN offering resource certification services 
>   is important to your plans, it would good to express such needs
>   on the arin-discuss mailing list. This helps us gauge the demand
>   which obviously is another important factor to be considered in
>   making the final determination on offering these services.
> 
>   We intend to have more detailed information out later this month
>   once the plans for finalized, but I hope the above information
>   provides some insight into the process at this point.  I will 
>   post this to the NANOG list for the community's information.
> 
> Thanks!
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> p.s.  I'm presently on a Caribbean cruise ship on a bona fide 
>  family vacation, so please recognize that replies may 
>  be deferred to off hours so that my laptop isn't thrown 
>  overboard... ;-)

Re: NIST IPv6 document

[Lamar Owen]

On Thursday, January 06, 2011 10:27:54 am you wrote:
> On Thu, 6 Jan 2011, Lamar Owen wrote:
> > Ok, perhaps I'm dense, but why is the router going to try to find a host 
> > that it already doesn't know based on an unsolicited outside packet? 

> Because the standard says it should do that.

Since when have standards been blindly followed by vendors?  If I were an IPv6 
router vendor, I'd code up a 'drop the packet if it's destined for an address 
in a directly attached subnet but that doesn't already have a neighbor table 
entry ' knob and sell it as a high-priced security add-on to my already bloated 
product line  

Actually, thinking like a coder, it would be removing the code that punts to 
neighbor discovery on receipt of an outside-the-destination-subnet packet 
destined to an address that's not in the neighbor table (and is an address 
within one of the router's directly attached subnets), and wouldn't require any 
additional CPU (or hardware punt to neighbor discovery) to implement.  Could 
even be sold as a forwarding performance improvement (for incoming to the 
subnet packets only, obviously).

And then allow an 'icmp-host-unreachable' to either be returned or not, 
according to the policy of the subnet in question.

Standards are written by people, of course, and most paragraphs have reasons to 
be there; I would find it interesting to hear the rationale for a router 
filling a slot in its neighbor table for a host that doesn't exist.  For that 
matter, I'd like to see a pointer to which standard that says this so I can 
read the verbiage myself, as that may have enough explanation to satisfy my 
curiosity.

> > If the packet is a response to a request from the host, then the router 
> > should have seen the outgoing packet (or, in the case of HSRP-teamed 
> > routers, all the routers in the standby group should be keeping track of 
> > all hosts, etc) and it should already be in the neighbor table.
> 
> Are you trying to abolish the end to end principle of the Internet by 
> implementing stateful firewalls in all routers?

Not at all; end to end is fine, but if there is no end to send a packet to, 
that packet should be dropped and not blindly trusted (since it will be abused 
for sure) by the router serving the destination subnet, which is the only 
router that is in a position to know if the endpoint exists or not.  Dropping 
in this case means 'don't punt to discovery for this packet' and isn't 
blocking, it's just not taking the extra effort to look up something it already 
doesn't know.  Not what I consider a stateful firewall.

This reminds me somewhat of some IPv4 routers doing Proxy ARP by default.

> > Like I said, perhaps I'm dense and ignorant and just simply 
> > misunderstanding the issue, but I still find it hard to believe that a 
> > router would blindly trust an outside address to know about an inside 
> > address that is not already in the router's neighbor table.
> 
> That's how it's always worked, both for v4 and v6.

Sounds like I need to study it in more depth, but I'm still having a hard time 
seeing why such behavior is a good idea.  Time to break out the wireshark 
laptop and do some SPANning and to see if I can find the reference in the 
RFC's somewhere.

Thanks for the info.

Re: NIST IPv6 document

[Jack Bates]

On 1/6/2011 9:52 AM, Mikael Abrahamsson wrote:

In the DHCP case this is easy, yes.

I perfer to have only LL on the link towards the customer operated CPE,
thus I don't really need to keep lots of ND state per customer.


I use RBE and unnumbered vlans in most areas, which keeps some state, 
but effectively prohibits the problem, as well as other problems. I have 
vendors curse me for wanting the router to handle the security instead 
of their DSLAMs, but then their DSLAMs often broke IPv6 with their so 
called security.



Jack

Re: NIST IPv6 document

[Miquel van Smoorenburg]

In article  you 
write:
>On Thu, Jan 6, 2011 at 4:32 AM, Joel Jaeggli  wrote:
>> Which at a minimum is why you want to police the number of nd messages
>> that the device sends and unreachable entries do not simply fill up the
>> nd cache, such that new mappings in fact can be learned because there
>
>Your solution is to break the router (or subnet) with a policer,
>instead of breaking it with a full table.  That is not better; both
>result in a broken subnet or router.  If NDP requires an NDCache with
>"incomplete" entries to learn new adjacencies, then preventing it from
>filling up will ... prevent it from learning new adjacencies.  Do you
>see how this is not a solution?

If all nodes implemented RFC4620 (IPv6 Node Information Queries),
then you could ratelimit ND queries and, when ratelimiting,
just regularly (say every few seconds) refresh the neighbor list
with a multicast NI Node Addresses Query .

In fact a router can still do this, it's just the nodes that do not
implement RFC4620 that suffer the most, and perhaps that will serve
as an incentive to get RFC4620 implemented on those nodes.

Mike.

Re: NIST IPv6 document

[Mikael Abrahamsson]

On Thu, 6 Jan 2011, Jack Bates wrote:

Not stateful firewalls. He's referring to neighbor learning based on 
incoming traffic to the router from the trusted side. ie, I received a 
packet from the server, so I will add his MAC to my neighbor table. 
There are many methods for learning MAC addresses, though. DHCP/MAC 
security with static ARP and other viable options have properly killed 
this problem in v4 by routers not looking for unknown neighbors.


When people start to talk about "trusted side" etc, I immediately think 
firewalls and not plain routing. I don't trust anyone, neither my 
customers, nor Internet.


I guess it might make sense to have the host register address usage (in 
the SLAAC case) with the router, and the router having a mechanism to 
broadcast/multicast to everybody that "I lost my state mac/ip table, 
please re-register" so they can do it again.


It's how it works, but not how it should work. In the last years, v4 has 
seen some nice implementations that specifically are designed 
(especially for eyeball networks who have vast pools of space) to keep 
routers from sending unsolicited arp requests and maintaining only a 
valid pool of mappings.


In the DHCP case this is easy, yes.

I perfer to have only LL on the link towards the customer operated CPE, 
thus I don't really need to keep lots of ND state per customer.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: NIST IPv6 document

[Jack Bates]

On 1/6/2011 9:37 AM, Marcel Plug wrote:

Perhaps we're reaching the point where we can say "We don't need an ND
table for a /64 network".  If the ethernet MAC is embedded in the IPv6
address, we don't need to discover it because we already know it.  If
the IPv6 address has been manually configured on a host, perhaps that
host should now accept traffic directed to the MAC that the lower 64
bits of the IPv6 address would translate to.

Perhaps this idea has been discussed somewhere and discarded for its
flaws, but if not, perhaps it should be :-).



The table itself is fine. I fully support it. The method for generating 
such a table within a router (separate from standard hosts who only 
generate tables for who they need to talk to, and unless you allowed 
forged packets in from remote, shouldn't have an issue) is what is in 
questions.


See my other posts. There have been many implementations, mostly for 
security reasons, but also helping with this problem by implementing a 
"router MUST NOT send unsolicited arp requests". It's important that 
routers learn their table in another fashion.



Jack

Re: NIST IPv6 document

[Jack Bates]

On 1/6/2011 9:27 AM, Mikael Abrahamsson wrote:

On Thu, 6 Jan 2011, Lamar Owen wrote:


Ok, perhaps I'm dense, but why is the router going to try to find a
host that it already doesn't know based on an unsolicited outside
packet? Why is the router trusting the outside's idea of what
addresses are active, and why isn't the router dropping packets on the
floor destined to hosts on one of its interfaces' local subnets that
it doesn't already know about?


Because the standard says it should do that.



The standard was broken with arp, and continues to be broken with NDP. 
Routers should not handle things the same as normal hosts.



If the packet is a response to a request from the host, then the
router should have seen the outgoing packet (or, in the case of
HSRP-teamed routers, all the routers in the standby group should be
keeping track of all hosts, etc) and it should already be in the
neighbor table.


Are you trying to abolish the end to end principle of the Internet by
implementing stateful firewalls in all routers?



Not stateful firewalls. He's referring to neighbor learning based on 
incoming traffic to the router from the trusted side. ie, I received a 
packet from the server, so I will add his MAC to my neighbor table. 
There are many methods for learning MAC addresses, though. DHCP/MAC 
security with static ARP and other viable options have properly killed 
this problem in v4 by routers not looking for unknown neighbors.



Like I said, perhaps I'm dense and ignorant and just simply
misunderstanding the issue, but I still find it hard to believe that a
router would blindly trust an outside address to know about an inside
address that is not already in the router's neighbor table.


That's how it's always worked, both for v4 and v6.



It's how it works, but not how it should work. In the last years, v4 has 
seen some nice implementations that specifically are designed 
(especially for eyeball networks who have vast pools of space) to keep 
routers from sending unsolicited arp requests and maintaining only a 
valid pool of mappings.


That is how the protocols should have been designed in the first place. 
Host to Host communications are one thing. Router to host communications 
should be designed with the idea that the host needs to tell the router 
who it is, not the router asking. This keeps packets from unknown hosts 
from causing these table issues. There are also (some of the above 
designed to do) security measures dealing with local abuse and 
hijacking, but that is separate issue. This is about resource 
exhaustion, and policing/ACL isn't the proper fix. Having hosts (in a 
secure or insecure manner) notify the router of their mapping is the 
appropriate fix. Protocol wise, insecure is fine, wrapped with an extra 
layer of security (as security can have multiple implementations).





Jack

Re: NIST IPv6 document

[Marcel Plug]

Perhaps we're reaching the point where we can say "We don't need an ND
table for a /64 network".  If the ethernet MAC is embedded in the IPv6
address, we don't need to discover it because we already know it.  If
the IPv6 address has been manually configured on a host, perhaps that
host should now accept traffic directed to the MAC that the lower 64
bits of the IPv6 address would translate to.

Perhaps this idea has been discussed somewhere and discarded for its
flaws, but if not, perhaps it should be :-).

Marcel

(First post by the way, go easy on me :-)

On Thu, Jan 6, 2011 at 10:19 AM, Jack Bates  wrote:
>
> On 1/6/2011 12:26 AM, Joe Greco wrote:
>>
>> A bunch of very smart people have worked on IPv6 for a very long
>> time, and justification for /64's was hashed out at extended length
>> over the period of years.
>
> NDP should have been better designed. It still has the same problems we had
> with ARP except the address pool has magnified it.
>
> Routers should have 1) better methods for keeping ND tables low (and
> maintaining only valid entries) or 2) better methods for learning valid
> entries than unsolicited NDP requests.
>
> This isn't to say the protocol itself is a waste, but it should have taken
> in the concerns and developed the mitigation controls necessary as
> recommendations to the implementers.
>
>
> Jack
>
>

Re: NIST IPv6 document

[Mikael Abrahamsson]

On Thu, 6 Jan 2011, Lamar Owen wrote:

Ok, perhaps I'm dense, but why is the router going to try to find a host 
that it already doesn't know based on an unsolicited outside packet? 
Why is the router trusting the outside's idea of what addresses are 
active, and why isn't the router dropping packets on the floor destined 
to hosts on one of its interfaces' local subnets that it doesn't already 
know about?


Because the standard says it should do that.

If the packet is a response to a request from the host, then the router 
should have seen the outgoing packet (or, in the case of HSRP-teamed 
routers, all the routers in the standby group should be keeping track of 
all hosts, etc) and it should already be in the neighbor table.


Are you trying to abolish the end to end principle of the Internet by 
implementing stateful firewalls in all routers?


Like I said, perhaps I'm dense and ignorant and just simply 
misunderstanding the issue, but I still find it hard to believe that a 
router would blindly trust an outside address to know about an inside 
address that is not already in the router's neighbor table.


That's how it's always worked, both for v4 and v6.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: NIST IPv6 document

[Tim Chown]

On 6 Jan 2011, at 15:10, Lamar Owen wrote:
> 
> Ok, perhaps I'm dense, but why is the router going to try to find a host that 
> it already doesn't know based on an unsolicited outside packet?  Why is the 
> router trusting the outside's idea of what addresses are active, and why 
> isn't the router dropping packets on the floor destined to hosts on one of 
> its interfaces' local subnets that it doesn't already know about?
> 
> If the packet is a response to a request from the host, then the router 
> should have seen the outgoing packet (or, in the case of HSRP-teamed routers, 
> all the routers in the standby group should be keeping track of all hosts, 
> etc) and it should already be in the neighbor table.

There's some interesting discussion around this point in RFC6018, which 
discusses the use of greynet monitoring in sparsely populated IPv6 subnets.
This approach may be one method to help detect and or mitigate such attacks.

Tim

Re: NIST IPv6 document

[Bill Bogstad]

On Thu, Jan 6, 2011 at 5:54 AM, Jeff Wheeler  wrote:
> On Thu, Jan 6, 2011 at 5:20 AM, Owen DeLong  wrote:
>>> You must also realize that the stateful firewall has the same problems
>> Uh, not exactly...
>
> Of course it does.  The stateful firewall must either 1) be vulnerable
> to the same form of NDP attack; or 2) have a list of allocated v6
> addresses on the LAN.  The reason is simple; a "stateful firewall" is
> no more able to store a 2**64 table than is a "router."  Calling it
> something different doesn't change the math.  If you choose to solve
> the problem by disabling NDP or allowing NS only for a list of "valid"
> addresses on the subnet, this can be done by a stateless router just
> like on a stateful firewall.
>
>> Uh, no it doesn't. It just needs a list of the hosts which are permitted
>> to receive inbound connections from the outside. That's the whole
>
> This solution falls apart as soon as there is a compromised host on
> the LAN, in which case the firewall (or router) NDP table can again be
> filled completely by that compromised/malicious host.  In addition,
> the "stateful firewall," by virtue of having connection state, does
> not solve the inbound NDP attack issue.  The list of hosts which can
> result in an NDP NS is whats causes this, and such a list may be
> present in a stateless router; but in both cases, it needs to be
> configured.

Err, almost everything falls apart once you allow a
compromised/malicious host on the local LAN.   If you have
circumstances where this may happen on anything like a regular basis,
you really need all kinds of control/monitoring of traffic that go far
beyond any local NDP overflow issues.

Bill Bogstad

Re: NIST IPv6 document

[Jack Bates]

On 1/6/2011 12:26 AM, Joe Greco wrote:

A bunch of very smart people have worked on IPv6 for a very long
time, and justification for /64's was hashed out at extended length
over the period of years.


NDP should have been better designed. It still has the same problems we 
had with ARP except the address pool has magnified it.


Routers should have 1) better methods for keeping ND tables low (and 
maintaining only valid entries) or 2) better methods for learning valid 
entries than unsolicited NDP requests.


This isn't to say the protocol itself is a waste, but it should have 
taken in the concerns and developed the mitigation controls necessary as 
recommendations to the implementers.



Jack

Re: NIST IPv6 document

[Lamar Owen]

On Wednesday, January 05, 2011 10:42:25 pm George Bonser wrote:
> I don't think you are understanding the problem.  The problem comes from
> addressing hosts that don't even exist.  This causes the router to
> attempt to find that host.  The v6 equivalent of ARP.  At some point
> that table becomes full of entries for hosts that don't exist so there
> isn't room for hosts that do exist.

Ok, perhaps I'm dense, but why is the router going to try to find a host that 
it already doesn't know based on an unsolicited outside packet?  Why is the 
router trusting the outside's idea of what addresses are active, and why isn't 
the router dropping packets on the floor destined to hosts on one of its 
interfaces' local subnets that it doesn't already know about?

If the packet is a response to a request from the host, then the router should 
have seen the outgoing packet (or, in the case of HSRP-teamed routers, all the 
routers in the standby group should be keeping track of all hosts, etc) and it 
should already be in the neighbor table.

Sounds a bit too much like ATM SVC addressing and the old LANE business for my 
liking.

Like I said, perhaps I'm dense and ignorant and just simply misunderstanding 
the issue, but I still find it hard to believe that a router would blindly 
trust an outside address to know about an inside address that is not already in 
the router's neighbor table.

In the case of a server (the only case I can see for such an unsolicited 
packet), I would think that it would be in the router's neighbor table already, 
or at least the server's OS should take pains to make sure it's in the neighbor 
table already!

Re: NIST IPv6 document

[Jack Bates]

On 1/5/2011 11:31 PM, Owen DeLong wrote:

Why shouldn't I use /64 for links if I want to? I can see why you can say you 
want /126s, and that's fine, as long as
you are willing to deal with the fall-out, your network, your problem, but, why 
tell me that my RFC-compliant network
is somehow wrong?



You can. My problem with that is primarily that using an ACL for the 
predictable addresses gets messy. Filtering based on assignments>::<1-2> isn't possible in most routers, and an acl to filter 
every /64 used for a link address is one heck of a long list.



SLAAC cannot function with longer than /64 because SLAAC depends on prefix + 
EUI-64 = address.


It depends on supporting it. EUI-64 address is not required for the 
globally routed prefixes, and many servers static the token as ::0xxx.



Jack

Re: Where to go for connectivity in VA / DC

[Kevin Loch]

bas wrote:

Hi,

We've recently opened a POP in northern Virginia.
The DC does not have a lot of connectivity options to choose from.

So we've ordered dark fiber to Equinix Ashburn DC2, we will light it
up with our own DWDM, and pick up connectivity there.

We do however need a second point to pick up connectivity for
redundancy purposes. (that runway from IAD is pretty scary)
Initially we had thought to pick up that connectivity at Coresite K-street.
However many of the carriers we use are not available at K-street.


8100 Boone Blvd.

- Kevin

Re: NIST IPv6 document

[Joe Greco]

> On Jan 6, 2011, at 2:03 PM, Matthew Petach wrote:
> > I think what people are trying to say is that it doesn't matter whether o=
> r not your host is easily findable or not, if I can trivially take out your
> > upstream router.

A good reason to see if there's a way to solve that (which there
is, I'm sure).

> That's part of it - the other part is that the host will be found, irrespec=
> tive of attempts to 'hide' it.

Sorry, but I see this as not grasping a fundamental security
concept.

You're not trying for DHS/TSA-style all-threats-always-prevented
threat elimination.  How many times do we have to learn that this
isn't a practical goal?  You want to make things more difficult for
an attacker while providing usability for authorized users.

Making a host harder to find (or more specifically to address from
remote) is a worthwhile goal.  Learn from history.  Ten years ago,
we *knew* DNS was "weak" due to the ultimate reliance on the 
transaction ID.  There weren't enough bits there to protect a DNS
server against certain types of attacks but that were deemed to
be impractical at the time; time passes, cpu's got faster, upstream
connections got faster, and suddenly some guy "discovers" that he 
can get a DNS server to do bad things if he floods it.  So now our
best current practices now have us using more bits, in the form of
random source ports, to help out there.  Even that's not a 
comprehensive fix - definitely won't be in another 20 years, when
bandwidth, cpu, and pps rates have all seen a factor of 1 
increase again - but it's helpful for the time being.

Things like 4941 take that a lot further, and provide enough bits to
make both range scanning and scanning via learned addresses less
useful techniques.  The fact that you might be able to find a host
somehow anyways doesn't lessen the value of making it harder for an
attacker to find that host to begin with.  This is basic security,
whether or not you approve of it.  You're trying to make it harder
for bad guys.

There are lots of security techniques that I don't like, too, or may
disapprove of for one reason or another.  NAT anyone?  :-) 

... 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.

Re: NIST IPv6 document

[Joe Greco]

> On Wed, Jan 5, 2011 at 10:51 PM, Joe Greco  wrote:
> >> On Jan 6, 2011, at 12:54 PM, Joe Greco wrote:
> ...
> > To say that "the endpoint *will be found*" is a truism, in the same
> > way that a bank *will* be robbed. =A0You're not trying to guarantee that
> > it will never happen. =A0You're trying to *deter* the bad guys. =A0You wa=
> nt
> > the bad guy to go across the street to the less-well-defended bank
> > across the street. =A0You can't be sure that they'll do that. =A0Someone
> > who has it out for you and your bank will rob your bank (or end up
> > in jail or dead or whatever). =A0But you can scare off the guy who's
> > just looking to score a few thousand in easy cash.
> >
> > Making it harder to scan a network *can* and *does* deter certain
> > classes of attacks. =A0That it doesn't prevent every attack isn't a
> > compelling proof that it doesn't prevent some, and I have to call what
> > you said a poor argument for that reason.
> 
> Hi Joe,
> 
> I think what people are trying to say is that it doesn't matter whether
> or not your host is easily findable or not, if I can trivially take out you=
> r
> upstream router.  With your upstream router out of commission, the
> findability of your host on the subnet really doesn't matter.  Once the
> router is gone, so is your host, no matter how well hidden on the
> subnet it was.
> 
> So, the push here is to prevent the trivial ability to take out the
> upstream routers, so that the host-level issues will still matter, and
> be worth discussing.
> 
> Hope this helps clarify the reason for the overarching concern
> about the /64 subnet size.

I completely understand that issue.  However, I feel that this is not
a hopeless quagmire.  We've frequently run into major problems in IP
engineering in the past, and have coped with them with varying degrees
of success (smurf and CIDR pop to mind).

We've also shown that the underlying protocols and technology are
open to tinkering where necessary; consider 802.3az.

I basically agree that there may be some issues with the current IPv6 
NDP (etc) system.  We actually have issues with the current IPv4 ARP
system, too (think spoofing etc).  However, I think we might be looking
at this the wrong way.  Instead of vendor knobs to change the IPv6 
protocol, which may interfere with both ethernet *and* v6, it seems to
me that maybe the problem can be solved just for the ethernet portions
of the problem.  For example, while there might be a /64's worth of 
address space on an interface, I'm *pretty* sure that the design goal
isn't actually to support all that.  Further, a router's need to talk
to that network will be isolated to that interface.  I wouldn't be too
shocked to see the NDP protocol morph a little to allow routers to
more easily maintain a neighbor list in local (per-ifc) silicon, 
rather than in expensive router TCAM, since the best use of TCAM isn't 
ARP^WNDP anyways.  The fact of the matter is that silicon is cheap and 
getting cheaper.  We will see ethernet switches allowing the learning 
of MAC info for NDP purposes, just as we currently have ethernet 
switches policing MAC's for IPv4 sanity purposes.  Routers will 
probably need to do some policing of NDP rates, but also we may see
better silicon to help with ethernet.

There may be ways to fix the *ethernet* /64 issues in IPv6.  We could
be talking constructively about that.  Instead, I'm seeing what seems
to me to be dislike of /64's in general.  I don't really care to get
into arguments about that, that ship sailed long ago, and those who 
missed the boat fighting it at the time aren't going to get any joy
here.

... 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.

Where to go for connectivity in VA / DC

[bas]

Hi,

We've recently opened a POP in northern Virginia.
The DC does not have a lot of connectivity options to choose from.

So we've ordered dark fiber to Equinix Ashburn DC2, we will light it
up with our own DWDM, and pick up connectivity there.

We do however need a second point to pick up connectivity for
redundancy purposes. (that runway from IAD is pretty scary)
Initially we had thought to pick up that connectivity at Coresite K-street.
However many of the carriers we use are not available at K-street.

What would you guys advise us to go to for lots of connectivity options.

Thanks,

Bas

Re: The tale of a single MAC

[Jethro R Binks]

On Sun, 2 Jan 2011, Lynda wrote:

> Google does NOT know all. I was there. I have had to deal with a 
> building full of such wickedness. I administered DNS (in my copious 
> spare time) for two subdomains, and managed the network in the building 
> (a not inconsiderable /22, and also in my spare time), and started 
> getting frantic calls from people who were getting knocked off the 
> network because their machine had the same MAC address as another.
> 
> I had trouble believing it at first, but after dealing with five of them 
> (all Gateways, and yes, all with the same MAC address), I directed the 
> local sysadmins to disable the nic that came with them, and to replace 
> it with a spare. I understand that there were 30,000 of them, all with 
> the same address. My guess is that you'll never find it on Google, since 
> it happened around 1993-4 or so.

You will now.

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.

Re: The tale of a single MAC

[Jethro R Binks]

On Sun, 2 Jan 2011, Steven Bellovin wrote:

> > This was actually the intended way to use "MAC" addresses, to used as
> > host addresses rather than as individual interface addresses, according
> > to the following paper -
> > 
> > "48-bit Absolute Internet and Ethernet Host Numbers"
> > Yogan K. Dalal and Robert S. Printis, July 1981
> > http://ethernethistory.typepad.com/papers/HostNumbers.pdf
> 
> Yup.
> > 
> > That paper also discusses why 48 bits were chosen as the size, despite
> > "Ethernet systems" being limited to 1024 hosts. 
> > 
> > I think things evolved into MAC per NIC because when add-in NICs
> > were invented there wasn't any appropriate non-volatile storage on the
> > host to store the address. 
> > 
> On really old Sun gear, the MAC address was stored on a separate ROM 
> chip; if the motherboard was replaced, you'd just move the ROM chip to 
> the new board.

And I'm sure many will remember that Suns of a certain vintage with 
multiple ethernet interfaces would use that same "host" MAC address on all 
those interfaces, unless you weaved some magic in the eeprom to use the 
(presumably) burned-in MAC address of the interface itself.  I have long 
forgotten precisely what the incantation was now ...

Jethro.

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.

Re: NIST IPv6 document

[Julien Goodwin]

On 06/01/11 16:01, John Levine wrote:
>> Still, the idea that "nobody will scan a /64" reminds me of the days
>> when 640K ought to be enough for anybody, ...
> 
> We really need to wrap our heads around the orders of magnitude
> involved here.  If you could scan an address every nanosecond, which I
> think is a reasonable upper bound what with the speed of light and
> all, it would still take 500 years to scan a /64.  Enumerating all the
> addresses will never be practical.  But there's plenty of damage one
> can do with a much less than thorough enumeration.

I'm probably ruining an interview question from $COMPANYTHATDIDN'THIREME
but think just of a 64-bit counter, *if* you had the ability to iterate
through 32-bits every second[1] it still takes ~136 years to go all the
way through 64 bits.

I don't know about you, but that doesn't worry me. At that point it's a
straight bandwidth DoS.

What makes much more sense is mapping the first /112 or so of a subnet,
the last /112 or so, that will catch most static hosts and routers, then
if you really want just iterate through the 2^46 valid assigned
MAC's[2], much less if you make some assumptions about which OUI's are
likely to exist on a subnet[3].

Julien

1: ie, think of a 4.3ish Ghz CPU that can do "i++ and jump to 0" in a
single instruction

2: One bit lost for broadcast, one bit for local/global addresses

3: Skipping all unassigned is obvious, but there's a huge amount that
will match systems you'll never care about, 2^36 is probably not far off.

Re: NIST IPv6 document

[Mark Smith]

On Wed, 5 Jan 2011 18:57:50 +0100
Phil Regnauld  wrote:

> Jeff Wheeler (jsw) writes:
> > are badly needed.  The largest current routing devices have room for
> > about 100,000 ARP/NDP entries, which can be used up in a fraction of a
> > second with a gigabit of malicious traffic flow.  What happens after
> > that is the problem, and we need to tell our vendors what knobs we
> > want so we can "choose our own failure mode" and limit damage to one
> > interface/LAN.
> 
>   Well there are *some* knobs:
> 
>   
> http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-addrg_bsc_con.html#wp1369018
> 
>   Not very smart, as it just controls how fast you run out of entries.
> 
>   I haven't read all entries in this thread yet, but I wonder if
>   http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 has been
>   mentioned ?
> 

The problem fundamentally is the outstanding state while the NS/NA
transaction takes place. IPX had big subnets (i.e. /32s out of 80 bit
addresses), but as it didn't use a layer 3 to layer 2 address resolution
protocol (layer 2 addresses were the layer 3 node addresses), requiring
transaction state, it didn't (or wouldn't have) had this issue.

I think the answer is to go stateless for the NS/NA transaction, either
blindly trusting the received NAs (initially compatible with current
NS/NA mechanisms), which reduces the set of nodes that can exploit
neighbor cache tables to those onlink, and then eventually moving
towards a nonce based verification of received NAs, which in effect
carries the NS/NA transaction state within the packet, rather than
storing it within the NS'ing node's memory. Going stateless means
losing ICMPv6 destination unreachables for non-existent neighbors
however (a) vendors aren't implementing those on P2P links already
because they switch off ND address resolution, (b) the /127 P2P proposal
switches them off because it proposes switching off ND address
resolution, and (c) firewalls commonly drop them inbound from the
Internet anyway. 

Other possible options -

http://www.ietf.org/mail-archive/web/ipv6/current/msg12400.html

>   Seems also that this topic has been brought up here a year ago give
>   or take a couple of weeks:
> 
>   http://www.mail-archive.com/nanog@nanog.org/msg18841.html
> 
> 
>   Cheers,
>   Phil
> 

Re: NIST IPv6 document

[Robert E. Seastrom]

Owen DeLong  writes:

> Personally, I think /64 works just fine.

I continue to believe that the "allocate the /64, configure the /127
as a workaround for the router vendors' unevolved designs" approach,
which Igor and I discovered we were in violent agreement on when on a
panel a few NANOGs ago, is the right one.

With only between 2^34 and 2^35 neocortical neurons in the average
human brain (*), perhaps we ought to be engineering for conserving
human brain cells rather than IPv6 addresses.  That means encoding
metadata in the IPv6 address in an easily visible fashion (such as pop
aggregation on nybble boundaries) and having a scheme where all
subnets are the same size (and just happen to hold an arbitrary number
of hosts).

-r


(*) a figure that is as irrelevant to the current conversation as
Roland's grandstanding about rejecting arguments about the vastness of
the IPv6 space out of hand).

New AS Number Blocks allocated to the RIPE NCC

[Ingrid Wijte]

Dear Colleagues,

The RIPE NCC received the following AS Number Blocks from the IANA in January 
2011.

56320-57343 
57344-58367
197632-198655

You may want to update your records accordingly.

Best regards,

Ingrid Wijte
Registration Services Assistant Manager
RIPE NCC

Re: NIST IPv6 document

[Jeff Wheeler]

On Thu, Jan 6, 2011 at 4:32 AM, Joel Jaeggli  wrote:
> Which at a minimum is why you want to police the number of nd messages
> that the device sends and unreachable entries do not simply fill up the
> nd cache, such that new mappings in fact can be learned because there

Your solution is to break the router (or subnet) with a policer,
instead of breaking it with a full table.  That is not better; both
result in a broken subnet or router.  If NDP requires an NDCache with
"incomplete" entries to learn new adjacencies, then preventing it from
filling up will ... prevent it from learning new adjacencies.  Do you
see how this is not a solution?

> are free entries. you need to do this on a per subnet basis rather than
> globally. as in ipv4 policing, global limits will kill the boxes ability
> to learn new entries everywhere.

Yes, per-subnet/interface limits are absolutely needed, to prevent the
entire box from being killed when one subnet/interface becomes
impaired.  That won't stop attackers from breaking your network, both
because one subnet that presumably has production services on it is
broken, and because, presumably, the attacker can identify other
subnets on the router.  Even if not, the problem remains that ... some
subnets/interfaces are broken.

On Thu, Jan 6, 2011 at 5:20 AM, Owen DeLong  wrote:
>> You must also realize that the stateful firewall has the same problems
> Uh, not exactly...

Of course it does.  The stateful firewall must either 1) be vulnerable
to the same form of NDP attack; or 2) have a list of allocated v6
addresses on the LAN.  The reason is simple; a "stateful firewall" is
no more able to store a 2**64 table than is a "router."  Calling it
something different doesn't change the math.  If you choose to solve
the problem by disabling NDP or allowing NS only for a list of "valid"
addresses on the subnet, this can be done by a stateless router just
like on a stateful firewall.

> Uh, no it doesn't. It just needs a list of the hosts which are permitted
> to receive inbound connections from the outside. That's the whole

This solution falls apart as soon as there is a compromised host on
the LAN, in which case the firewall (or router) NDP table can again be
filled completely by that compromised/malicious host.  In addition,
the "stateful firewall," by virtue of having connection state, does
not solve the inbound NDP attack issue.  The list of hosts which can
result in an NDP NS is whats causes this, and such a list may be
present in a stateless router; but in both cases, it needs to be
configured.

"Stateful firewall" is unfortunately not magic dust that you can
sprinkle on any network problem.

> Except that routers don't (usually) have the ability to do dynamic outbound
> filtration which means that you have the scaling problem you've described
> of having to list every host on the net. If the router does have this ability,
> then, the router is, by definition, a stateful firewall.

As I state above, this capability does not "fix" the problem because
the "stateful firewall" can just as easily be subject to DoS.  You
must have a list of valid v6 hosts on the subnet for your solution to
work.

> There are risks with sparse subnets that have been inadequately addressed
> for some of their failure modes at this time. I wouldn't go so far as saying 
> they
> are a plan to fail. In most cases, most networks shouldn't be susceptible
> to an externally initiated ND attack in the first place because those should
> mostly be blocked at your border except for hosts that provide services
> to the larger internet.

As you have pointed out, without state information, you can't block
this external attack.  Even if you have a "stateful firewall," that
firewall must itself have a solution for the internally-originated NDP
attack.  While the problems are slightly different and the
internally-originated attack is less likely, both must be solved to
ensure a reliable v6 network.  The "stateful firewall" only solves
half the problem and remains entirely vulnerable to the other half.

On Thu, Jan 6, 2011 at 5:29 AM, Owen DeLong  wrote:
> But, Jeff, if the router has a bunch of /24s attached to it and you scan
> them all, the problem is much larger than 250 arp entries.

That depends on how many is "a bunch" and how large is the ARP table
on the device.  A pizza box layer-3 switch, as I have mentioned,
easily holds several thousand entries, modern units upwards of 10,000.
 That's enough room for several v4 /24 networks.  No device has enough
for one v6 /64 network.  In addition, most of the IPs on your typical
/24 networks will be in use routinely (in a hosting environment,
anyway) which means that a scan really doesn't generate many new
WHO-HAS and incomplete entries, because most layer-2 mappings are
already known.  Those that aren't fit within the cheap router's
resource limitations somewhat easily.

On Thu, Jan 6, 2011 at 5:41 AM, Phil Regnauld  wrote:
>        Additionnally I believe the size of ty

Re: NIST IPv6 document

[Phil Regnauld]

Owen DeLong (owen) writes:
> 
> But, Jeff, if the router has a bunch of /24s attached to it and you scan
> them all, the problem is much larger than 250 arp entries.
> 
> I think that's what Phil was getting at.

And so did Joel.  If you've got a crapload of VLANs attached to a box,
and you're routing these for customers (say, virtual firewall 
instances),
you'll see this easily.

I do understand the argument that sweeping a /64 will mean more L3->L2
lookups for directly connected subnets than in v4, but the problem 
domain
remains the same, and I think it's been already explained here that 
there
are various strategies to mitigate this.

Additionnally I believe the size of typical recommended IPv6 space will
probably discourage idle scanning, though this may change as the 
resources
available increase, as Joe G. pointed out.  If it does not, we'll have 
to
address it if the existing mitigation techniques aren't sufficient.

Phil

Re: NIST IPv6 document

[Owen DeLong]

On Jan 5, 2011, at 9:44 AM, Jeff Wheeler wrote:

> On Wed, Jan 5, 2011 at 12:26 PM, Phil Regnauld  wrote:
>> Jeff Wheeler (jsw) writes:
>>> Not good, but also does not affect any other interfaces on the router.
>>You're assuming that all routing devices have per-interface ARP 
>> tables.
> 
> No, Phil, I am assuming that the routing device has a larger ARP table
> than 250 entries.  To be more correct, I am assuming that the routing
> device has a large enough ARP table that any one subnet could go from
> 0 ARP entries to 100% ARP entries without using up all the remaining
> ARP resources on the box.  This is usually true.  Further, routing
> devices usually have enough ARP table space that every subnet attached
> to them could be 100% full of active ARP entries without using up all
> the ARP resources.  This is also often true.

But, Jeff, if the router has a bunch of /24s attached to it and you scan
them all, the problem is much larger than 250 arp entries.

I think that's what Phil was getting at.

Owen

Re: NIST IPv6 document

[Owen DeLong]

> 
> On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum  
> wrote:
>> A (relatively) easy way to avoid this problem is to either use a stateful 
>> firewall that only allows internally initiated sessions, or a filter that 
>> lists only addresses that are known to be in use.
> 
> It would certainly be nice to have a stateful firewall on every single
> LAN connection.  Were there high-speed, stateful firewalls in 1994?
> Perhaps the IPng folks had this solution in mind, but left it out of
> the standards process.  No doubt they all own stock in SonicWall and
> are eagerly awaiting the day when "Anonymous" takes down a major ISP
> every day with a simple attack that has been known to exist, but not
> addressed, for many years.
> 
> You must also realize that the stateful firewall has the same problems

Uh, not exactly...

> as the router.  It must include a list of allocated IPv6 addresses on
> each subnet in order to be able to ignore other traffic.  While this

Uh, no it doesn't. It just needs a list of the hosts which are permitted
to receive inbound connections from the outside. That's the whole
point of the stateful in stateful firewall... It can dynamically allow
outbound sessions and only needs to be open for hosts that are
supposed to receive external session initiations.

Since that list is relatively small and you probably need to maintain
it anyway, I'm not really seeing a problem here.

> can certainly be accomplished, it would be much easier to simply list
> those addresses in the router, which would avoid the expense of any
> product typically called a "stateful firewall."  In either case, you
> are now maintaining a list of valid addresses for every subnet on the
> router, and disabling NDP for any other addresses.  I agree with you,
> this knob should be offered by vendors in addition to my list of
> possible vendor solutions.
> 
Except that routers don't (usually) have the ability to do dynamic outbound
filtration which means that you have the scaling problem you've described
of having to list every host on the net. If the router does have this ability,
then, the router is, by definition, a stateful firewall.

> On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum  
> wrote:
>> Sparse subnets in IPv6 are a feature, not a bug. They're not going to go 
>> away.
> 
> I do not conceptually disagree with sparse subnets.  With the
> equipment limitations of today, they are a plan to fail.  Let's hope
> that all vendors catch up to this before malicious people/groups.
> 
There are risks with sparse subnets that have been inadequately addressed
for some of their failure modes at this time. I wouldn't go so far as saying 
they
are a plan to fail. In most cases, most networks shouldn't be susceptible
to an externally initiated ND attack in the first place because those should
mostly be blocked at your border except for hosts that provide services
to the larger internet.

Owen

Re: NIST IPv6 document

[Joel Jaeggli]

On 1/6/11 12:24 AM, Jeff Wheeler wrote:
> On Thu, Jan 6, 2011 at 2:42 AM, Joel Jaeggli  wrote:
>> icmp6 rate limiting both reciept and origination is not rocket science.
>> The attack that's being described wasn't exactly dreamed up last week,
>> is as observed not unique to ipv6, and can be mitigated.
> 
> That does not solve the problem.  Your response, like most on this
> thread, clearly indicates that you do not understand the underlying
> issue, or how traffic is actually forwarded.  Neither IPv6 or IPv4
> packets are simply forwarded onto the Ethernet, which is why the
> ARP/NDP table resource is required; a mapping from layer-3 to layer-2
> address is needed.

You seem hell bent on telling me what I do and don't know. I know how
they're created.

> If the table resource for these entries is
> exhausted, no new mappings can be learned,

Which at a minimum is why you want to police the number of nd messages
that the device sends and unreachable entries do not simply fill up the
nd cache, such that new mappings in fact can be learned because there
are free entries. you need to do this on a per subnet basis rather than
globally. as in ipv4 policing, global limits will kill the boxes ability
to learn new entries everywhere.

> and bad things happen.
> Either hosts on the specif interface, or the entire box, can no longer
> exchange traffic through the router.  If an artificial rate-limit on
> discovery traffic is reached, discovery of mappings will also be
> impeded, meaning the denial-of-service condition exists and persists
> until the attack ceases.  This may also affect either just that
> interface, or all interfaces on the router, depending on its failure
> mode.
> 
> Rate-limiting discovery traffic still breaks the attached LANs.  How
> badly it breaks them is implementation-specific.  It does avoid using
> up all the router's CPU, but that doesn't help the hosts which can't
> exchange traffic.  Again, depending on the router implementation, the
> fraction of hosts which cannot exchange traffic may reach 100%, and in
> effect, the router might as well be down.
> 
>> You can still have this problem when you assign a bunch of /112s how
>> many neighbor unreachable entries per interface can your fib hold?
> 
> You are correct, but the device can hold a significant number of
> entries compared to the size of a /112 subnet,

a /112 is 16 bits.

 just like it can hold a
> significant number of v4 ARP entries compared to a v4 /22 subnet. 

I've got this lovely ex8208 here, a quick glance as the specs says 100k
arp entries per linecard. that requires some sensible configuration from
the outset otherwise shooting yourself in the foot with ipv4 is
possible. I've done it both deliberately and on accident and I have
better rules now.

> The
> difference is, ARP/NDP mappings for one /64 subnet can fill all the
> TCAM resources of any router that will ever exist.

the arp mappings for an ipv4 /15 will fill up the device today.

>  This is why more
> knobs are needed, and until we have that, the /64 approach is
> fundamentally broken.

as with anything sent to into the control plane it needs to be policed
there are sensible ways to do that today, they can improve.

> Again, until this problem is better-understood, it will not be solved.
>  Right now, there are many vulnerable networks; and in some platforms
> running a dual-stack configuration, filling up the v6 NDP table will
> also impact v4 ARP.  This means the problem is not confined to a cute
> beta-test that your customers are just starting to ask about; it will
> also take out your production v4 network.  If you are running a
> dual-stack network with /64 LANs, you had better start planning.  It's
> not just a problem on the horizon, it's a problem right now for many
> early-adopters.
> 

Re: Spamming and ssh attack from a customers

[Mark Andrews]

In message , Tarig Ahmed writes:
> hi all
> 
> I am receiving emails from many servers saying that: this ip (from a  
> customer) is trying to attacking one of our servers.
> 
> Is it appropriate to filter ssh, telnet, and smtp from my customers,  
> or just forward the message to my customer contact persons?

I suspect that your customer is compromised and you should put them
in a walled garden until they fix the problem.  Look at traffic
flows first however.

> Thanks in advance..
> 
> Tarig Yassin Ahmed
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Qwest access problems

[Wes Bachman]

Anyone seeing problems with Qwest access circuits this evening?  Our
AT&T GigE circuit with Qwest LEC has bounced twice.  Oddly when I went
to check it out from home, my Qwest DSL was down at the exact same time,
and appeared to come back up at around the same time.  I'm in eastern
Iowa.  I haven't heard anything from Qwest or AT&T so far, and received
no notice of any planned maintenance?

-Wes Bachman
Leepfrog Technologies, Inc.

Re: Problems with removing NAT from a network

[Mark Andrews]

In message , Came
ron Byrne writes:
> On Wed, Jan 5, 2011 at 9:55 PM, Mark Andrews  wrote:
> >
> > In message  l.com>, Came
> > ron Byrne writes:
> >> As long as dual-stack is around, the app vendors don't have to move
> >> and network guys have to dream up hacks to support these legacy apps
> >> (CGN ).
> >
> > NAT64 is CGN expecially when it is being implemented by the cellular
> > carriers.
> >
> 
> Agreed.  And, the NAT44 that 99% of my customer use to today is also a CGN.
> 
> It's status quo, all v4 flows require state in my network, NAT44 or NAT64.
> 
> But, NAT64 has an exit strategy.  With every new  that comes out,
> that is one less destination requiring state in my network.

I will give you that it is easy to see with NAT64 when the target
space has moved.  It also forces you to upgrade all client applications
to support IPv6 from the start.

Anyway its horses for courses.

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

FW: Spamming and ssh attack from a customers

[Tarig Yassin]

> Depends on your acceptable use policy and terms of service.
>  If they won't or aren't able to respond effectively, I would say that 
> (depdning on the who and what of your 
> customer), shutting down the port may be a viable next step.
> 
Hi mike
 
In our case, the AUP gives us the right to do so, and some customers are not 
able. 
Is possible to deligate this issue to them (Through RIRs  databeses, emails 
will be sent to them directly not through us)? without new ASN and BGP 
requirements?
 
thanks

-- 
Tarig Y. Adam
 SUIN
www.suin.edu.sd




 
> Date: Thu, 6 Jan 2011 00:26:24 -0800
> From: mike-na...@tiedyenetworks.com
> To: nanog@nanog.org
> Subject: Re: Spamming and ssh attack from a customers
> 
> On 01/06/2011 12:21 AM, Tarig Ahmed wrote:
> > hi all
> >
> > I am receiving emails from many servers saying that: this ip (from a
> > customer) is trying to attacking one of our servers.
> >
> > Is it appropriate to filter ssh, telnet, and smtp from my customers, or
> > just forward the message to my customer contact persons?
> >
> 
> Depends on your acceptable use policy and terms of service. I would say 
> trying to micromanage the ip protos being used for these attacks is just 
> creating work for you - if they are the source, and you have credible 
> reports, then the customer should be notified and they should commit to 
> resolving the problem. If they won't or aren't able to respond 
> effectively, I would say that (depdning on the who and what of your 
> customer), shutting down the port may be a viable next step.
> 
> Mike-
> 
> 
  

Re: Spamming and ssh attack from a customers

[Mike]

On 01/06/2011 12:21 AM, Tarig Ahmed wrote:

hi all

I am receiving emails from many servers saying that: this ip (from a
customer) is trying to attacking one of our servers.

Is it appropriate to filter ssh, telnet, and smtp from my customers, or
just forward the message to my customer contact persons?



Depends on your acceptable use policy and terms of service. I would say 
trying to micromanage the ip protos being used for these attacks is just 
creating work for you - if they are the source, and you have credible 
reports, then the customer should be notified and they should commit to 
resolving the problem. If they won't or aren't able to respond 
effectively, I would say that (depdning on the who and what of your 
customer), shutting down the port may be a viable next step.


Mike-

Re: NIST IPv6 document

[Jeff Wheeler]

On Thu, Jan 6, 2011 at 2:42 AM, Joel Jaeggli  wrote:
> icmp6 rate limiting both reciept and origination is not rocket science.
> The attack that's being described wasn't exactly dreamed up last week,
> is as observed not unique to ipv6, and can be mitigated.

That does not solve the problem.  Your response, like most on this
thread, clearly indicates that you do not understand the underlying
issue, or how traffic is actually forwarded.  Neither IPv6 or IPv4
packets are simply forwarded onto the Ethernet, which is why the
ARP/NDP table resource is required; a mapping from layer-3 to layer-2
address is needed.  If the table resource for these entries is
exhausted, no new mappings can be learned, and bad things happen.
Either hosts on the specif interface, or the entire box, can no longer
exchange traffic through the router.  If an artificial rate-limit on
discovery traffic is reached, discovery of mappings will also be
impeded, meaning the denial-of-service condition exists and persists
until the attack ceases.  This may also affect either just that
interface, or all interfaces on the router, depending on its failure
mode.

Rate-limiting discovery traffic still breaks the attached LANs.  How
badly it breaks them is implementation-specific.  It does avoid using
up all the router's CPU, but that doesn't help the hosts which can't
exchange traffic.  Again, depending on the router implementation, the
fraction of hosts which cannot exchange traffic may reach 100%, and in
effect, the router might as well be down.

> You can still have this problem when you assign a bunch of /112s how
> many neighbor unreachable entries per interface can your fib hold?

You are correct, but the device can hold a significant number of
entries compared to the size of a /112 subnet, just like it can hold a
significant number of v4 ARP entries compared to a v4 /22 subnet.  The
difference is, ARP/NDP mappings for one /64 subnet can fill all the
TCAM resources of any router that will ever exist.  This is why more
knobs are needed, and until we have that, the /64 approach is
fundamentally broken.

Again, until this problem is better-understood, it will not be solved.
 Right now, there are many vulnerable networks; and in some platforms
running a dual-stack configuration, filling up the v6 NDP table will
also impact v4 ARP.  This means the problem is not confined to a cute
beta-test that your customers are just starting to ask about; it will
also take out your production v4 network.  If you are running a
dual-stack network with /64 LANs, you had better start planning.  It's
not just a problem on the horizon, it's a problem right now for many
early-adopters.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Spamming and ssh attack from a customers

[Tarig Ahmed]

hi all

I am receiving emails from many servers saying that: this ip (from a  
customer) is trying to attacking one of our servers.


Is it appropriate to filter ssh, telnet, and smtp from my customers,  
or just forward the message to my customer contact persons?


Thanks in advance..

Tarig Yassin Ahmed

Re: Clearwire/Clear for branch office connectivity?

[Joe Hamelin]

Since I'm not with Clearwire anymore (end of contract) I can say that
there are people in the core networking that do follow and respond the
this list.

I can say that their backbone is solid and the people there really do
care about the network.

If you have serious a backbone issue with Clearwire a message on this
list will result in a response..

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474