Subject: Re: [savi] 答复: ***SPAM*** 6.181 (5) 转发: DAD as a binding distribution protocol: why not

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 05 May 2009 10:49:29 +0200

Guang Yao escribió:
> Marcelo,
>
> I think this problem has two aspects:
>
> 1 Is it reasonable to set up binding without DAD?
>
> Even there is a BDP, so long as SAVI is not fully deployed, DAD is still
> needed to detect whether an address has been used by another node.
>   
According to RFC4429, the probability of a colision if nodes select the
iid randomly (whcih is what DAD is aiming to prevent) is:
(different values for different number of nodes in the subnte, ranging
from 500 to 500000)
Pb(2^62, 500) <= 5.4e-14
Pb(2^62, 5000) <= 5.4e-12
Pb(2^62, 50000) <= 5.4e-10
Pb(2^62, 500000) <= 5.4e-08

> This means, SAVI device should never set up a binding without DAD. In
> another word, if a binding is set up without DAD, it is suspect the bound
> address is reasonable.
>
>   
i think with the above probabilities, it is fairly safe to use an
address even if the DAD packet was lost (that is essentially the
principle behing optimistic DAD)

> 2 DAD may be unreliable, but not so unreliable.
>
>   
DAD is unreliable by definition i.e. there is no ack back. You cannot
get more unreliable than that

> The DoD
DoD?

>  situation you mentioned is a specified situation and a configuration
> can be made to handle it.
>
>   
not sure what you mean by this

> DAD can be lost, but it has little possibility. And the retransmission time
> of DAD is configurable as described in [RFC4862], [RFC4861].
>
>   

right, but the default value is 1, so you need to configure all the
hosts in the network to change that value, which is not desirable and
you cannot rely upon

> Even fearing the possible DAD loss, it is still unreasonable to set up a
> binding only on data packets and BDP.
>
>   
why?

> Maybe the DAD loss problem can be handled through this way 
>
> A. In PEACEF state, the SAVI device performs DAD for each new address
> without previous DAD.
>
>   
the problem with the savi device issuing a DAD is that introduces a
synch point. I mean, if the savi issues a DAD and it receives two
replies, what does the savi does at that point?
> B. In WAR state, the SAVI device drops all packets without previous DAD.
>
> C. If the SAVI device is triggered to perform DAD for more than X times in a
> recent period, change the state from PEACE to AWR.
>
> D. If no filtering happens in a period, change the state from WAR to PEACE.
>
> This function can be enabled if the administrator find the link state is not
> good enough.
>
>
>
> If by default connecting the host to the network, it may kill other hosts in
> the network

how comes this is the case?

Regards, marcelo

>  and why we still need SAVI?
>
>
> Regards,
> Guang
>
> -----邮件原件-----
> 发件人: marcelo bagnulo braun [mailto:[email-masked]] 
> 发送时间: 2009年4月30日 21:14
> 收件人: Guang Yao
> 抄送: 'SAVI Mailing List'
> 主题: Re: [savi] ***SPAM*** 6.181 (5) 转发: DAD as a binding distribution
> protocol: why not
>
> Guang,
>
> The problem is that the DAD procedure is inherently unreliable, so the
> NASOL msg can be lost and never get the SAVI device, These reasons
> include from simply errors in the packets, DAD being lost (for instance
> in dial on demand technologies, which are likely to discard the first
> packet, which is as you say the DAD packet)
>
> So, i fully agree with you that when there is a DAD packet, the SAVI
> device should use to create a binding. the problem is what if the DAD
> packet gets lost. By default disconnecting the host from the network,
> seems an overkill to me.
>
> Regards, marcelo
>
>
>
> Guang Yao escribió:
>   
>> Christian,
>>
>> I want to argue that, control packet snooping(DAD snooping) is both
>> sufficient and necessary to set up binding for SLAAC address.
>>
>> ->:
>>
>> Obviously.
>>
>> <-:
>>
>> RFC 4862
>>
>> /*
>>
>> 5.4. Duplicate Address Detection
>>
>> Duplicate Address Detection _/MUST/_ be performed on all unicast
>>
>> addresses prior to assigning them to an interface, regardless of
>>
>> whether they are obtained through stateless autoconfiguration,
>>
>> DHCPv6, or manual configuration, with the following exceptions:
>>
>> - An interface whose DupAddrDetectTransmits variable is set to zero
>>
>> does not perform Duplicate Address Detection.
>>
>> - Duplicate Address Detection MUST NOT be performed on anycast
>>
>> addresses (note that anycast addresses cannot syntactically be
>>
>> distinguished from unicast addresses).
>>
>> - Each individual unicast address SHOULD be tested for uniqueness.
>>
>> Note that there are implementations deployed that only perform
>>
>> Duplicate Address Detection for the link-local address and skip
>>
>> the test for the global address that uses the same interface
>>
>> identifier as that of the link-local address. Whereas this
>>
>> document does not invalidate such implementations, this kind of
>>
>> "optimization" is NOT RECOMMENDED, and new implementations MUST
>>
>> NOT do that optimization. This optimization came from the
>>
>> assumption that all of an interface's addresses are generated from
>>
>> the same identifier. However, the assumption does actually not
>>
>> stand; new types of addresses have been introduced where the
>>
>> interface identifiers are not necessarily the same for all unicast
>>
>> addresses on a single interface [RFC4941] [RFC3972]. Requiring
>>
>> that Duplicate Address Detection be performed for all unicast
>>
>> addresses will make the algorithm robust for the current and
>>
>> future special interface identifiers.
>>
>> */
>>
>> Note that this is a MUST.
>>
>> Although a host may not conform to this specification, DAD is still
>> needed. Before DAD, an address is suspicious to be used, in another
>> word, it may be spoofing.
>>
>> Even there is a BDP to sync all the devices, there may be addresses
>> not known by BDP, for example, hosts attached to legacy device, and
>> their packets go through no SAVI device.
>>
>> Thus, without DAD, the SAVI device cannot get known whether this
>> address has been used by other nodes. Only after a successful DAD, the
>> SAVI device has confident to set up a binding for that address; or
>> else, it may cause fallacious binding.
>>
>> And we can think that, when will a host send packets before DAD?
>>
>> It seems a DoS attacking scenario.
>>
>> Even it is not attacking, why does it have to act like this?
>>
>> Regards,
>>
>> Guang
>>
>> -----邮件原件-----
>> 发件人: [email-masked] [mailto:[email-masked]] 代表
>> Christian Vogt
>> 发送时间: 2009年4月23日 12:40
>> 收件人: Jun Bi
>> 抄送: Guang Yao; 'SAVI Mailing List'; 'Greg Daley'; 'Suresh Krishnan'
>> 主题: Re: [savi] DAD as a binding distribution protocol: why not
>>
>> On Apr 15, 2009, Jun Bi wrote:
>>
>>     
>>> Certainly, the major problem of SAVI-FCFS is not only the first packet
>>>       
>>> lost. Even the first packet is not lost, FCFS still need a BDP, and it
>>>       
>>> might be complex when we have multiple SAVI-swtiches (the real-time
>>>       
>>> sync
>>>       
>>> requirements), we even didn't see a prototype of BDP yet. But SAVI-CPS
>>>       
>>> doesn't need the BDP, just need some enhancement.
>>>       
>> Jun and all -
>>
>> When comparing FCFS and SAVI-CPS, we should be careful not to mix
>>
>> DHCP-based and SLAAC-based address configuration.
>>
>> It is true that SAVI-CPS, or control-packet-only snooping in general,
>>
>> may not need a BDP in the case of DHCP-assigned addresses. Thanks to
>>
>> the acknowledged address assignment exchange, the lack of an address
>>
>> binding in a SAVI device then implies with high reliability that packets
>>
>> locally originating from this address should be dropped.
>>
>> But in the case of addresses auto-configured via SLAAC, snooping only
>>
>> control packets doesn't have the same effect. Since there is no
>>
>> acknowledged address assignment exchange, the lack of an address binding
>>
>> in a SAVI device does NOT imply that packets locally originating from
>>
>> this address should be dropped. I.e., the best a SAVI device can do in
>>
>> this case is let such packets through. And the scenario that Marcelo
>>
>> had illustrated earlier shows that this may lead to a vulnerability.
>>
>> Hence, control-packet-only snooping in SLAAC could in some cases
>>
>> benefit from a BDP, independent of whether you use FCFS or SAVI-CPS.
>>
>> So the issue with SLAAC-based address configuration is the same whether
>>
>> we use FCFS or SAVI-CPS -- independent of whether we believe that this
>>
>> issue justifies the development of a BDP.
>>
>> - Christian
>>
>> _______________________________________________
>>
>> savi mailing list
>>
>> [email-masked]
>>
>> https://www.ietf.org/mailman/listinfo/savi
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> savi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/savi
>>   
>>     
>
>
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 06 May 2009 13:15:49 +0200

Guang Yao escribió:
> / *Guang:*/
> So, are you declare that DAD is never needed?
>   

DAD is a safety net for extremely rare cases, as the probability above
clearly show. In particular, it helps with hosts that are malfunctioning
for instance. But in normal operation, the colision probability is
really low, which is the basis for optimistic DAD
> / *Guang:*/
> If it is a probability problem, I could declare that DAD never get lost.
>
>   
not really
there are some L2 that have a non negligible loss probability.
In addition, dial on demand type of links, tend to loose the first
packet, which is exactly the dad packet

Regards, marcelo

>> DAD can be lost, but it has little possibility. And the retransmission
>>     
> time
>   
>> C. If the SAVI device is triggered to perform DAD for more than X times in
>>     
> a
>   
>> D. If no filtering happens in a period, change the state from WAR to
>>     
> PEACE.
>   
>> This function can be enabled if the administrator find the link state is
>>     
> not
>   
>> good enough.
>>
>>
>>
>> If by default connecting the host to the network, it may kill other hosts
>>     
> in
>   
>> the network
>>     
>

---

From: Christian Vogt <[email-masked]>
Date: Wed, 20 May 2009 13:52:25 -0700

On Apr 28, 2009, Guang Yao wrote:

> address
> has been used by other nodes. Only after a successful DAD, the SAVI
> device has confident to set up a binding for that address; or else, it
> may cause fallacious binding.

Guang -

As with the first data packet, also the DAD packets are not guaranteed  
to
reach the SAVI device.  There are two reasons for this:  First, DAD
packets may get lost, as Marcelo has mentioned.  This is in particular  
so
if the DAD packets have to make an extra hop via a legacy switch.  
Second,
because the DAD packets may deliberately not be forwarded to the SAVI
device.  DAD packets are not broadcast; they are either unicast or  
limited
to a certain multicast group, so they may not reach the SAVI device.

Since DAD packets are not guaranteed to reach the SAVI device just as
data packets, CPS may run into problems that are very similar to the  
FCFS-
specific problems you have identified.

- Christian