Re: [savi] Binding establishment based on data or control packets?

[marcelo bagnulo braun <marcelo at it.uc3m.es>]

Christian Vogt escribió:
> Marcelo -
>
> > What about legitimate NA for source addresses _not_ corresponding to an
> > existing SAVI binding? I mean, SAVI bindings are soft state, hence it
> > can and will be discarded at some point. So, it seem perfectly possible
> > to me that a node sends a legitimate NA and that the binding if once
> > existed, has been discarded. Dropping legitimate NA packets seems to be
> > problematic, i think
>
> Yes, you are right; this is a problem.  In fact, there are more variants
> of the case where the legitimate address owner's SAVI device does not
> have a binding for the address in question:  It can also happen if the
> address in question was manually configured into the legitimate address
> owner, and the legitimate address owner has never used the address and
> hence never created a binding in its SAVI device.  (This is a situation
> that Guang had described earlier.)  Obviously, these cases need to be
> handled.
Ok, we have two issues here:
how to handle manually configured issues
how to make the binding distribution protocol work

Now, for the issue about manually configured addresses, for IPv6, there 
is no problem
I re read rfc2462 and it states:

5.4.  Duplicate Address Detection

  Duplicate Address Detection is performed on unicast addresses prior
  to assigning them to an interface whose DupAddrDetectTransmits
  variable is greater than zero. Duplicate Address Detection MUST take
  place on all unicast addresses, regardless of whether they are
  obtained through stateful, stateless or manual configuration, with
  the exception of the following cases:

   - Duplicate Address Detection MUST NOT be performed on anycast
       addresses.

     - Each individual unicast address SHOULD be tested for uniqueness.
       However, when stateless address autoconfiguration is used,
       address uniqueness is determined solely by the interface
       identifier, assuming that subnet prefixes are assigned correctly
       (i.e., if all of an interface's addresses are generated from the
       same identifier, either all addresses or none of them will be
       duplicates). Thus, for a set of addresses formed from the same
       interface identifier, it is sufficient to check that the link-
       local address generated from the identifier is unique on the
       link. In such cases, the link-local address MUST be tested for
       uniqueness, and if no duplicate address is detected, an
       implementation MAY choose to skip Duplicate Address Detection
       for additional addresses derived from the same interface
       identifier.


So, manual configured addresses are not an issue, cause the perform the 
DAD procedure, so the savi device learn about them through it.

Interestingly, we may need to do something with the global addresses if 
the DAD have been performed for the link local. But i guess the SAVI 
device could create binding for the associated global addresses upon the 
DAD for the link local address (note that if the address is used from a 
different lower layer anchor, the savi device will check the exisitng 
binding, which i  guess is what we want)

So, i think there is no problem here

The problem is how to build the binding distribution protocol wihtout 
introducing new vulnerabilities.
And at this point, i don't see any obvious answer beyond having some 
configuration in the savi devices (e.g. a shared key) which is certainly 
not the most attractive approach

Regards, marcelo


> Suggestions?  Do we need to adopt manual configuration of SAVI bindings
> for manually configured addresses?
>
> - Christian