Subject: [savi] Suggested Consensus Questions on Protecting Unused Addresses - Take Two

From: Christian Vogt <[email-masked]>
Date: Wed, 8 Jul 2009 18:59:41 -0700

Folks -

Thank you for your comments on the consensus questions regarding the
protection of unused addresses.  I would like to make two suggestions to
reflect your comments:  First, a revision of the consensus questions.
Second, a working assumption to help focussing our discussion.

Regarding the consensus questions:  Your comments indicate that the
notion of "unused addresses" is insufficient for two reasons:  First,
the meaning of "unused" in the sense of "available for configuration" is
difficult to determine from the perspective of a SAVI device.  Second,
in case SLAAC is a permitted address configuration method, the boundary
between an address being unused and used is thin, since only the trans-
mission of a DAD Neighbor Solicitation message distinguishes the two.

These comments make perfect sense.  The goal of revising the consensus
questions is hence to avoid the term "unused address" altogether, and to
ask in a manner less conceptual, and more oriented towards a SAVI
device's operation.  The revised consensus questions are as follows:

(A) In networks where SLAAC is permitted for address configuration, how
     should a SAVI device treat packets with a source address for which
     neither a successful DAD procedure nor a DHCP assignment was seen?

     (A1) Discard the packet
     (A2) Forward and optionally log the packet

(B) In networks where only DHCP is permitted for address configuration,
     how should a SAVI device treat packets with a source address for
     which no DHCP assignment was seen?

     (B1) Discard the packet
     (B2) Forward and optionally log the packet

In these questions, a SAVI device sees a "successful DAD procedure" for
an address if it sees a DAD Neighbor Solicitation message, but no
responding DAD Neighbor Advertisement message, for this address.

Our existing SAVI solution proposals relate to these consensus questions
as follows:  The FCFS and CPS solutions both use the combination of (A1)
plus (B1), with different means to reduce the probability of dropping
legitimate packets.  The middle-ground solution we are considering now  
--
originally suggested in [1] by Marcelo, and slightly augmented in [2] by
me with an alternative mode for DHCP-only networks -- uses the
combination of (A2) plus (B1).  I would like folks to consider in
particular this combination of (A2) plus (B1) because it constitutes a
reasonable compromise between two competing solutions.

The proposed working assumption is that SAVI will operate exclusively in
wired networks, with switch ports constituting the binding anchors.  The
goal of this working assumption is to relieve the discussion from
considerations about scenarios where SAVI can only have limited benefit.
Unprotected wireless networks are an example of those scenarios, where
forgeable MAC addresses are the only possible binding anchors.  We will
re-evaluate at a later stage how well SAVI applies to other scenarios.

Are above consensus questions and working assumption OK?  Please provide
your feedback. We extend the deadline for feedback until Sunday, July  
11.

- Christian

[1] http://www.ietf.org/mail-archive/web/savi/current/msg00654.html
[2] http://www.ietf.org/mail-archive/web/savi/current/msg00715.html

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Thu, 09 Jul 2009 08:49:10 +0200

>     neither a successful DAD procedure nor a DHCP assignment was seen?

i don't think this is acceptable

>     (A2) Forward and optionally log the packet

I think this is ok, but we may want to do something else, like for 
instance, creating a binding. At this point, i am uncertain whether we 
should that or not, but i wouldn't discard it yet.

>     which no DHCP assignment was seen?

In order to answer this question i would like to understand what is the 
impact of the SAVI state being lost in case of a reboot for example.

I mean, in this case we don't have to worry about loosing the dhcp 
packets,  cause the dhcp will retransmit until gets an address 
assigned, but we still have to understand the impact of the savi device 
loosing state. So, are we going to try to recover the state, are we 
going to assume that the state is stored in permanent memory and never 
gets lost or are we going to assume that if it gets lost, the host will 
have to renew their dhcp assigment.. or other option that i am missing?

> legitimate packets.  The middle-ground solution we are considering now  --
> your feedback. We extend the deadline for feedback until Sunday, July  11.
>
> - Christian
>
>
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

-- 
----
MARCELO BAGNULO BRAUN
WebCartero
Universidad Carlos III de Madrid

---

From: Christian Vogt <[email-masked]>
Date: Thu, 9 Jul 2009 13:23:52 -0700

On Jul 8, 2009, MARCELO BAGNULO BRAUN wrote:

> assigned,
> but we still have to understand the impact of the savi device loosing
> state. So, are we going to try to recover the state, are we going to
> assume that the state is stored in permanent memory and never gets  
> lost
> or are we going to assume that if it gets lost, the host will have to
> renew their dhcp assigment.. or other option that i am missing?

Yes, we would have to require either non-volatile binding state, or
renewal of DHCP leases by hosts.

A question to the working group regarding the latter:  What is the
behavior of existing DHCP client implementations in the case of state
loss in a SAVI device? Would it automatically renew its DHCP leases?

Remember that, through manual configuration, one can ensure that only
SAVI devices directly attached to a host can drop packets from that
host.  So if such a SAVI device loses state due to a reboot, the
attached host will notice this because its link goes down and back up.
Would DHCP client implementations then renew their DHCP leases?

- Christian

---

From: Dong Zhang <[email-masked]>
Date: Sat, 11 Jul 2009 11:56:33 +0800

Hi,
>should that or not, but i wouldn't discard it yet.
(A2) is ok. And I also agree creating a binding for this case. 
But this kind binding should have something different with the regular bindings. 
For example, setting a status mark in this special kind binding to indicate 
the binding is suspicious temporarily. Once makeing sure the binding is true, 
then change the suspicious into the regular status. About the way how to 
figure out the binding is true, I have not thought it up. 

------------------				 
Dong Zhang
2009-07-11