Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt

From: Erik Nordmark <[email-masked]>
Date: Thu, 01 Nov 2012 14:28:35 -0700

On 10/11/12 11:23 PM, Carsten Bormann wrote:
> Two quick comments:
>
> -- this still uses 10 seconds as a scaler for the ARO registration lifetime. 6LoWPAN-ND used to use 10, but now uses 60 seconds.

Oops - we'll fix.

> -- I'm not too wild about the E-bit.  Maybe we should extract the 6CIO from draft-bormann-6lowpan-ghc and use this?

I don't understand the relationship.
The E-bit is there to specify that the router supports AROs. That way 
the hosts can tell whether it makes sense to try ARO.
How does this relate to compression context?

> The two areas in which I think this proposal can benefit from some more discussion:
>
> Clearly, mitigating the external ND table DoS is one of the major pain points addressed by this.  Thinking point: Is there any way to structure the transition from legacy ND to efficient ND in such a way that it becomes easier to reap this benefit?

If not all the hosts on the link do explicit registration, then the 
routers need to be able to send multicast NS messages to find those that 
didn't register.
As noted in RFC 6583, draft-gashinsky-6man-v6nd-enhance-02.txt, and 
draft-ietf-6man-impatient-nud-05.txt, things can be improved if the 
routers don't discard NCEs too quickly, and potentially interpret 
unsolicited NS messages as a registration attempt.

The last part is a bit problematic in general, but if a router has 
sufficient memory it can definitely track which hosts it has ever heard 
from on the link and thereby significantly reduce the rate at which is 
needs to send multicast NS to look for previously unknown hosts.

> For DC applications, the assumption of uniqueness of the EUI-64 probably requires some more thinking.  VMs get copied all the time, and it is way too easy to copy this kind of config info in the process.

I don't think the EUI-64 is different than the IEEE-48 MAC address. In 
fact the for Ethernet the EUI-64 is derived from the MAC address.

And if cloning a VM results in keeping the same MAC address then things 
will not work well even for IPv4.

Regards,
    Erik

> Grüße, Carsten
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 Nov 2012 22:54:34 +0100

On Nov 1, 2012, at 22:28, Erik Nordmark <[email-masked]> wrote:

> The E-bit is there to specify that the router supports AROs. That way the hosts can tell whether it makes sense to try ARO.

Not at all.  I'm not talking about 6CO, but about 6CIO from draft-bormann-6lowpan-ghc.
This is a capability indication option.
(Yes, the abbreviation could be less confusing.)

Grüße, Carsten

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 1 Nov 2012 23:51:19 +0000

Hi Carsten,

Please see below in-line with ===> prefix.
-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Thursday, November 01, 2012 2:55 PM
To: Erik Nordmark
Cc: Samita Chakrabarti; 6man Mailing List
Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt

===> E-bit is to distinguish between classic-ND and efficient-ND operation. If you are concerned about flag bit shortage in RFC 4861 RA format, then the solution exists. It is RFC 5175 (IPv6 Router Adv Flags option).

As mentioned in bormann-6lowpan-ghc that 6CIO (6lowpan Capability Indication) is used  for capabilty advertisements for 6lowpan nodes. It could be useful for advertising for different other capabilities in 6lowpan environment where different types of 6lowpan nodes might be active in a network ( HC capable, Low-memory vs buffering capable, specific app-support capable etc. ) while I cannot see a need for additional 8 bytes of 6CIO in order for simple enahncement of IPv6 RA mechanism with registration when 1 existing bit can suffice.

Thanks,
-Samita

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 2 Nov 2012 06:50:48 +0100

On Nov 2, 2012, at 00:51, Samita Chakrabarti <[email-masked]> wrote:

> If you are concerned about flag bit shortage in RFC 4861 RA format, then the solution exists. It is RFC 5175 (IPv6 Router Adv Flags option).

Ah, right.  This information is carried in RA only, so that can indeed be used.  
(6CIO is mostly used in RS, that's why I had to invent a new one for that.)

So, let's happily use up those flag bits.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 2 Nov 2012 07:23:19 +0100

> If not all the hosts on the link do explicit registration, then the routers need to be able to send multicast NS messages to find those that didn't register.
> As noted in RFC 6583, draft-gashinsky-6man-v6nd-enhance-02.txt, and draft-ietf-6man-impatient-nud-05.txt, things can be improved if the routers don't discard NCEs too quickly, and potentially interpret unsolicited NS messages as a registration attempt.
> 
> The last part is a bit problematic in general, but if a router has sufficient memory it can definitely track which hosts it has ever heard from on the link and thereby significantly reduce the rate at which is needs to send multicast NS to look for previously unknown hosts.

But most of this only helps with the addresses for which hosts actually exist.

In the transition, routers still need to implement rate-limiting on their multicast NS.  
(With Efficient-ND, hosts defer to routers for finding other hosts.)  Maybe we should mention that.

Using any heuristic (tracking hosts based on unsolicited NS, MLD, whatever) to track existing hosts (more specifically: existing host addresses) is good.  Routers can limit their NS rate-limiting behavior to those hosts for which they have heard nothing.  So this is a valid strategy to point out.  (Specific heuristics are orthogonal to this draft, though.)

But the attack is about hosts that don't exist, so inducing multicast NS rate limiting is still an effective DoS on the router finding hosts/addresses not yet discovered (there are many more non-existing hosts than additional addresses).  Improving the discovery heuristic thus mitigates the DoS.

(Note that attacks on the discovery heuristic are possible, but these would be inside attacks.  
The bad thing about the ND table attack is that any Internet host can carry it out.)

Not being subject to not being found due to multicast NS rate-limiting, of course, is a deployment incentive on the host side...

> I don't think the EUI-64 is different than the IEEE-48 MAC address. In fact the for Ethernet the EUI-64 is derived from the MAC address.
> 
> And if cloning a VM results in keeping the same MAC address then things will not work well even for IPv4.

Sure.  People do have problems with this on IPv4, too.  But can (should?) we do better?
If yes, that would be another deployment incentive for Efficient-ND.

In summary, none of these are problems with the draft -- I'm just pointing out that if we can do something beyond what we have, these are ways to increase the deployment incentive.

Grüße, Carsten

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 01 Nov 2012 14:18:07 -0700

Mark,

We started working on a registration mechanisms (initially scoped for 
6lowpan) back at IETF 72 in Dublin. The result of that is 
draft-ietf-6lowpan-nd (which is undergoing final edits at the rfc-editor 
as we speak).

However, since that was targeting a homogenous 6lowpan where all hosts 
and routers do the 6lowpan-nd optimizations.
Thus 6man-efficient-nd is exploring how to handle incremental 
introduction of the Address Registration Option to existing IPv6 links, 
resulting in mixed-mode operation.

In terms of the ND DoS concerns you might also want to look at RFC 6583, 
draft-gashinsky-6man-v6nd-enhance-02.txt, and 
draft-ietf-6man-impatient-nud-05.txt.

Regards,
    Erik

  is also
On 10/12/12 4:41 PM, Mark ZZZ Smith wrote:
> Hi,
>
>
> ----- Original Message -----
>> From: Carsten Bormann <[email-masked]>
>> To: Samita Chakrabarti <[email-masked]>
>> Cc: 6man Mailing List <[email-masked]>
>> Sent: Friday, 12 October 2012 5:23 PM
>> T wo quick comments:
> <snip>
>> Clearly, mitigating the external ND table DoS is one of the major pain points
>> addressed by this.  Thinking point: Is there any way to structure the transition
>> from legacy ND to efficient ND in such a way that it becomes easier to reap this
>> benefit?
>>
>
> I've been thinking about a registration protocol recently, which would have
> leveraged the MLDv2 election process at router interface connection  to
> discover existing nodes' link local addresses, Inverse Neighbor Discovery
> to query the nodes' for their other addresses (other LLs, ULAs, GUAs),
> DAD to detect new nodes/addresses, and NUD to detect when nodes/addresses
> disappear. The drawback as you indirectly point out is that it requires
> all nodes to support the registration protocol before it can be enabled
> and the DoS mitigated. So I worked on the following draft first, which
> I think mitigates the DoS for routers, and only requires changes to
> routers' neighbor discovery operation:
>
> "Mitigating IPv6 Router Neighbor Cache DoS Using Stateless Neighbor Discovery"
>
> http://tools.ietf.org/search/draft-smith-6man-mitigate-nd-cache-dos-slnd-00
>
> I've got a new update nearly finished, which I'll post later today.
>
> I definitely think a registration protocol is necessary. While working on
> the above draft, I realised that on-link sources can also cause the off-link
> neighbor cache DoS, by using spoofed non-existent source addresses from
> within the local subnet, and sending that traffic to a remote host that
> sends replies back (e.g. lots of spoofed source addressed outgoing TCP SYNs, reply
> TCP SYN/ACKs would cause the neighbor cache DoS attack on the router). A
> registration protocol would allow individual address-based rather than just prefix level
> BCP38 protection, because routers now know exactly what devices exist
> on-link, and can therefore drop traffic with spoofed local subnet source addresses.
>
> Regards,
> Mark.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 01 Nov 2012 14:23:00 -0700

[I don't know if this made it to the list]

-------- Original Message --------
Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt
Date: Thu, 01 Nov 2012 14:18:07 -0700
From: Erik Nordmark <[email-masked]>
To: Mark ZZZ Smith <[email-masked]>
CC: Carsten Bormann <[email-masked]>,        Samita Chakrabarti 
<[email-masked]>,        6man Mailing List <[email-masked]>

Mark,

Regards,
    Erik

  is also

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 02 Nov 2012 14:56:54 -0700

> (With Efficient-ND, hosts defer to routers for finding other hosts.)  Maybe we should mention that.

We can definitely mention that.

> Not being subject to not being found due to multicast NS rate-limiting, of course, is a deployment incentive on the host side...

Agreed.

> If yes, that would be another deployment incentive for Efficient-ND.

I don't think we can do better. When you clone a VM you still want the 
new VM to have a distinct identity compared to the origin of the clone.
Either that identity is external to the VM (such as a MAC address that 
is controlled by the hypervisor), or internal to the VM (such as a 
configured DHCP client-id in some config file).
In the case of an internal identity you'd need to be able to set a new 
one as part of a clone.

This isn't  unique to IP-related config.
In many cases when you clone a VM you'd like it to have a different 
hostname and probably a unique ssh key.

> In summary, none of these are problems with the draft -- I'm just pointing out that if we can do something beyond what we have, these are ways to increase the deployment incentive.

Understood.

Thanks,
     Erik