[v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

[Brian E Carpenter <[e-mail]>]

Hello Fred,

On 03/11/2015 20:10, Templin, Fred L wrote:
> Hi Brian,
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[e-mail]]
>> Sent: Monday, November 02, 2015 6:55 PM
>> To: Templin, Fred L; Lorenzo Colitti
>> Cc: [e-mail]
>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
>>
>> Hi Fred,
>> On 03/11/2015 14:59, Templin, Fred L wrote:
>>> Hi Brian,
>>>
>>>> -----Original Message-----
>>>> From: Brian E Carpenter [mailto:[e-mail]]
>>>> Sent: Monday, November 02, 2015 5:46 PM
>>>> To: Templin, Fred L; Lorenzo Colitti
>>>> Cc: [e-mail]
>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
>>>>
>>>> On 03/11/2015 14:31, Templin, Fred L wrote:
>>>>> Bumping up one level – is it clear to everyone that it is OK to assign addresses
>>>>> taken from a DHCPv6 delegated prefix to the interface over which the prefix
>>>>> was received?
>>>>
>>>> If it was legitimately received, I can't see why it wouldn't be OK.
>>>
>>> OK. When the DHCPv6 server grants a prefix delegation to the client,
>>> the server is asserting that that prefix is unique and is now the sole
>>> property of the client. So, when you say legitimately received I
>>> agree and that is actually a core requirement of DHCPv6 PD.
>>> Otherwise, if the DHCPv6 server gave out duplicate prefixes, the
>>> routing system would become hopelessly corrupted and address
>>> duplication would be the least of our worries.
>>>
>>>>> And, that DAD is not required for those addresses?
>>>>
>>>> How is that safe? What is to stop a host running SLAAC once it
>>>> sees that prefix in an RA, and hitting the same IID by chance?
>>>> At least you need to specify that the A bit must not be set.
>>>
>>> I am talking about DAD on interface "A" being the interface over
>>> which the client receives the prefix delegation. No other node on
>>> interface "A" may use the delegated prefix, and no router on
>>> interface "A" may advertise the prefix in an RA. The prefix is the
>>> sole property of the client that received the PD, so the client is
>>> free to assign addresses without needing DAD.
>>
>> That usage of "may" might confuse some people, so let's pretend
>> you used a "MUST NOT" construct instead. I could still construct
>> a host stack that would ignore the issue: its logic would be
>> "I sent an RS and got no RA/PIO with A=1; but I see traffic from
>> prefix 2bad:dead:beef::/64, so I'll do SLAAC and DAD in that prefix."
> 
> The malicious (or otherwise broken) host 'A' could configure any number
> of addresses it likes, but it would do so in a vacuum because ingress
> filtering will prevent a packet with a source address from a prefix
> belonging to host B from being accepted. So, node B has no reason
> to fear address duplication by node A.

I'm not sure how an ingress filter somewhere upstream would know that
the packet came from the "wrong" host. But I don't think that's enough;
a duplicate address on the LAN is already a problem in itself.

> Also, what if node B in fact did do DAD and A heard it? What is to stop
> A from configuring a duplicate address and trying to use it just to mess
> up the legitimate operation of node B?

Nothing. That, I think, is why the RFCs make DAD mandatory.

> 
> What you are describing is a broken implementation that could only
> be employed by a malicious host, and not something that honors
> the standards. 

I don't think it's malicious; it's just trying to get IPv6 connectivity
in the face of what it sees as a broken router that isn't responding
to RS. But that isn't really my point - my point is that whatever we
do, it's impossible to assert that a duplicate address will never arise.

> Doing DAD is not going to guard against malicious
> hosts.

No, but it might allow you to detect the resulting anomaly.

   Brian

> 
> Thanks - Fred
> [e-mail] 
> 
>>>> Come to that, a manual address might collide.
>>>
>>> The client itself is the only node that is permitted to assign addresses
>>> from the delegated prefix to an interface, so there is no risk of
>>> collision unless the client itself is somehow corrupt.
>>
>> Or another client on the same LAN gets too clever.
>>
>>    Brian
>>
>>>
>>> Thanks - Fred
>>> [e-mail]
>>>
>>>>     Brian
>>>>
>>>>>
>>>>> Thanks - Fred
>>>>>
>>>>> From: v6ops [mailto:[e-mail]] On Behalf Of Templin, Fred L
>>>>> Sent: Monday, November 02, 2015 5:24 PM
>>>>> To: Lorenzo Colitti
>>>>> Cc: [e-mail]
>>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
>>>>>
>>>>> Hi Lorenzo,
>>>>>
>>>>> Responses below in “green”:
>>>>>
>>>>> From: Lorenzo Colitti [mailto:[e-mail]]
>>>>> Sent: Monday, November 02, 2015 5:04 PM
>>>>> To: Templin, Fred L
>>>>> Cc: Fred Baker (fred); [e-mail]<mailto:[e-mail]>
>>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
>>>>>
>>>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L <[e-mail]<mailto:[e-mail]>> wrote:
>>>>> I have one text addition suggestion and one question. On P. 7, in Table 1,
>>>>> suggest adding a new final row as follows:
>>>>>
>>>>>   requires DAD               Yes                  Yes                   No                 N/A
>>>>>
>>>>> Meaning that multi-addresses configured by SLAAC or DHCPv6 IA_NA/IA_TA
>>>>> must use DAD to check for duplicates on the link they were obtained. In a
>>>>> multi-addressing environment where millions of addresses are required,
>>>>> this could amount to a substantial amount of DAD multicast traffic. On the
>>>>> other hand, DAD is not needed for DHCPv6 PD because the network has
>>>>> unambiguously delegated the prefix for the node's exclusive use.
>>>>>
>>>>> I don't think "Requires DAD: No" is correct. Even if the device gets a /64 prefix entirely for its own use, it still needs to do DAD with
>>>> any other devices on that /64 (e.g., tethered devices, VMs, etc.).
>>>>>
>>>>> I'm not opposed to adding a line to the table, though I don't think it provides much value - if we put our mind to it, I'm sure we
>> could
>>>> come up with lots of things we could add to the table that aren't there at the moment. My main concern is that if we add
>> something to
>>>> the table it needs to be correct.
>>>>>
>>>>> What I mean is “Requires DAD on the interface over which the prefix was received”,
>>>>> but that was too long to fit in the table. Let’s call the interface “A”. If the node gets
>>>>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface “A”, then it needs
>>>>> to do DAD on interface “A” for each such address. If the node gets a DHCPv6 PD
>>>>> over interface “A”, however, it does not need to do DAD over interface “A” at all.
>>>>>
>>>>> If the node assigns the delegated prefix to interface “B”, then you are right that
>>>>> that DAD will be required among all tethered devices, VMs, etc. on interface “B”.
>>>>> But, there will still be no need for DAD on interface “A”. Does that clarify?
>>>>>
>>>>> I have a question also on table 1. Under ""Unlimited" endpoints", why does
>>>>> it say "no" for DHCPv6 PD? I think it should say "yes" instead, since a prefix
>>>>> obtained by DHCPv6 PD can be used to configure an unlimited number of
>>>>> addresses on the link over which the prefix was received.
>>>>>
>>>>> The table is written from the perspective of the network assigning addresses to devices that connect to it. Therefore, it says "no"
>>>> because if you use DHCPv6 PD you can't assign address space to an unlimited number of endpoints - you are limited to however
>> many
>>>> /64s you have available.
>>>>>
>>>>> If you use IA_NA or SLAAC, any network with a /64 subnet has, at least in theory, an "unlimited" number of addresses to assign to
>>>> clients. Of course, that's only true in theory. In practice, there's going to be a limit due to scaling reasons.
>>>>>
>>>>> I don’t understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA can be used
>>>>> to assign an unlimited number of addresses to interface “A”. But, so can DHCPv6
>>>>> PD. When the node receives the delegated prefix (e.g., a /64), it can assign as
>>>>> many unique IPv6 addresses as it likes to interface “A”. And again, it need not
>>>>> do DAD for any of them.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> v6ops mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>
>>>
>