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

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 30 Apr 2009 15:14:09 +0200

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
>