Folks -

I would like to solicit more feedback on the benefit-cost analysis
(below) for protecting unused addresses. How valuable do people consider
protection of unused addresses, how much cost do they think is OK?  Is
there something that the analysis overlooks?  We already got several
very useful comments from a few people.  What do the others think?

To recap:  We need to decide between the following three options of
dealing with unused addresses:

- Not protect unused addresses, i.e., forward packets without a binding.
   Logging is still possible, though.

- Protect unused addresses, and coordinate SAVI devices on the same link
   by manually disabling SAVI protection on ports connecting to other
   SAVI devices.

- Protect unused addresses, and coordinate SAVI devices on the same link
   with a dedicated binding synchronization protocol.

Please send your feedback by Sunday, July 5.  We will vote after that.

- Christian



On Jun 24, 2009, Christian Vogt wrote:

> On Jun 23, 2009, Fred Baker wrote on thread "Your opinion on a  
> different
> tradeoff for SAVI":
>
>> SAVI without protecting unused addresses is pointless.
>
>
> Fred and all -
>
> Protection of unused addresses would, of course, be a useful feature.
> But before making this mandatory, we should do a benefit-cost  
> analysis.
> Here is one, along with a proposal of how to move forward:
>
> The benefit of protecting unused addresses is that it prevents an
> attacker from hiding its identity or location.  An attacker who  
> wants to
> do this can use any source address as long as it is not its own  
> address.
> Protecting unused addresses is especially useful in networks where  
> DHCP
> is the only permitted method for address configuration, since those
> networks are in control of which addresses are used.  On the other  
> hand,
> in networks where Stateless Address Autoconfiguration is permitted, it
> is up to the (potentially malicious) hosts which addresses are used.
> Protecting unused addresses then has little benefit:  All it  
> achieves is
> requiring an attacker to formally turn an unused address into a used
> address by sending a DAD solicitation.
>
> The cost of protecting unused addresses is a need to coordinate  
> multiple
> SAVI devices on the same link.  If this coordination does not exist,  
> or
> is insufficient, legitimate packets may get dropped, because one SAVI
> device may consider unused an address that is in fact in use at  
> another
> SAVI device.  Coordination between SAVI devices, in turn, can be
> accomplished in one of two ways:
>
> - By partitioning the scope of SAVI protection into one area per SAVI
>  device.  This requires manual configuration of SAVI devices, since
>  switch ports that connect to other SAVI devices must be labeled as
>  such. Link partitioning is the approach of the CPS solution.
>
> - By synchronizing binding state across SAVI devices so that each SAVI
>  device can validate addresses from anywhere else on the link.  This
>  requires an extra binding distribution protocol, plus extra memory
>  for binding state copied from other SAVI devices.  Synchronization
>  was proposed as an add-on to the original FCFS solution.
>
> Either form of coordination implies an undesired cost for protecting
> unused addresses.  Given this cost, and given that the main benefit is
> in networks where DHCP is the only permitted address configuration
> method, a potential way to move forward may be to make the protection
> of unused addresses optional and limited to those DHCP-only networks.
> More specifically, we could add an optional "DHCP-only mode" to SAVI,
> in which SAVI devices would permit only those addresses that have been
> explicitly assigned via DHCP.  In DHCP-only mode, SAVI devices would:
>
> - Create bindings only based on DHCP address assignments, but not  
> based
>  on DAD solicitations.
>
> - Drop packets with unused source addresses.
>
> As a method for inter-SAVI-device coordination, I suggest partitioning
> the scope of SAVI protection.  Thus, network administrators who enable
> DHCP-only mode may also have to manually designate switch ports that
> connect to other SAVI devices.  This extra manual configuration should
> be acceptable given that the DHCP-only mode already needs to be turned
> on manually.  At the same time, link partitioning avoids the extra
> complexity and manufacturing cost that synchronization would entail.
>
> What do folks think?  Would this be a reasonable approach?
>
> - Christian