Re: [savi] A few comments on draft-vogt-savi-framework

[Alberto García <alberto at it.uc3m.es>]

Hi

|  -----Mensaje original-----
|  De: savi-bounces at ietf.org [mailto:savi-bounces at ietf.org] En nombre de
marcelo
|  bagnulo braun
|  Enviado el: viernes, 30 de octubre de 2009 8:51
|  Para: Christian Vogt
|  CC: SAVI Mailing List; Alberto García
|  Asunto: Re: [savi] A few comments on draft-vogt-savi-framework
|  
|  Christian Vogt escribió:
|  > Alberto -
|  >
|  > As a member of the working group, not as its chair:  You are right
|  > that co-existence scenarios need to be handled.  But I'm not sure that
|  > coexistence requires /special/ behavior.  As long as the behavior
|  > desired for coexistence scenarios does not preclude the behavior
|  > desired for non-coexistence scenarios, I think coexistence should be
|  > covered by the /regular/ behavior of the various SAVI protocol
|  > specifications.  That is, in the particular case of SLAAC/SEND co-
|  > existence, I think we should strive for a SAVI SEND protocol that can
|  > handle non-SEND-capable SAVI devices.
|  >
|  > Does this make sense?
|  >
|  yes, but the question is what do we do with the slaac send in the
|  presence of send capable hosts.
|  
|  If we want to support them, then all slaac savi devices need to
|  implement the send savi, which seems an overkill for a the send protocol
|  which deployment is non existent afaict
|  If we allow sllac savi only devices, then plugging a send host would not
|  work well (in particular, the send node can be filtered by the savi
|  device in some cases, making the deployment of send even harder later
|  on. So this is a tough call imho

I agree that requiring SEND implementations in all SAVI devices maybe
overkill. However, I don't see many functional problems with SEND hosts
interacting in a SLAAC-only environment (i.e. apart of not being able to
prioritize SEND bindings over SLAAC, which is natural if switches don't
recognize SEND). 
The case in which SEND hosts could have some trouble is in the DAD
procedure, since they behave different than SLAAC hosts if there is an
address collision in the second try with a non-SEND device. SEND hosts would
configure the address, but the SLAAC SAVI device would filter all packets
from the SEND host.
While this is true, we have to consider that for this to occur, the SLAAC
host with the address colliding with the SEND device must have (according to
FCFS SAVI spec) the address configured BEFORE the SEND host issues its DAD
NSOL (or SAVI would filter its DAD NADV). 
If a SEND host tries a first address, and fails,  where do the second
address is coming from? If the new address was not known for the rest of the
network (eg. because it has just generated dynamically after the failure of
the first), then this event would be a real (unlikely) collision, and not an
attack.
Do you think this is a functional issue? I would say no, but...

So maybe a SLAAC-only mode for SAVI could provide support for SEND hosts,
although, of course, the result would be better if SAVI devices are aware of
SEND.

Regards,
Alberto

|  
|  Regards, marcelo
|  
|  
|  > - Christian
|  >
|  >
|  >
|  > On Oct 29, 2009, at 3:04, Alberto García wrote:
|  >
|  >
|  >> My opinion is that priorization is not enough.
|  >> I think we need to define "operation modes" (SEND-only, SLAAC-only,
|  >> SEND-SLAAC-compatible...) and describe the state machine for each one.
|  >>
|  >> To support the idea of why we need a new state machine for SEND-SLAAC
|  >> compatibility, i.e. for a domain in which both SEND hosts and non-
|  >> SEND hosts
|  >> coexist, just consider what a node should do (extending naturally the
|  >> current FCFS and SEND proposals) if a SAVI device is in NO_BIND
|  >> state, and a
|  >> data packet (not DAD NSOL) is received, from a Validating port VP.
|  >> In this
|  >> case, the SEND SAVI device should send
|  >> 	- 2 (unsecured) NSOL messages through Trusted ports (according to
|  >> FCFS SAVI)
|  >> 	- and a secured NUD NSOL message through the Validating Port
|  >> (according to SEND SAVI
|  >> 	And The state is moved to TENTATIVE.
|  >>
|  >> In the TENTATIVE state, the SAVI device should maybe wait long
|  >> enough (a
|  >> RetransTimer, which is the waiting time for NUD operation) for a
|  >> secured NUD
|  >> NADV even if an unsecured DAD NSOL is received from a trusted port
|  >> in the
|  >> meanwhile, to assure that SEND validated addresses have priority over
|  >> non-SEND addresses. [Note that this may occur if a SEND host has one
|  >> collision when performing DAD for an address, and it is not
|  >> withdrawing the
|  >> second address if an unsecured DAD NSOL is received for it, as RFC
|  >> 3971
|  >> says].
|  >> Different states should be defined (VALID_SEND, VALID_NON_SEND), with
|  >> different behavior when the valid_timeout expires.
|  >>
|  >>
|  >> So I don't think this is just "ships in the night", but different
|  >> modes
|  >> should be defined to integrate all the possible combinations of
|  >> address
|  >> configuration mechanisms. Maybe one of these modes should be the
|  >> default
|  >> one, but the administrator could set the SAVI devices to the
|  >> appropriate
|  >> mode (well, they also have to define which ports are trusted or
|  >> not...).
|  >>
|  >> Does this make sense?
|  >> Regards,
|  >> Alberto
|  >>
|  >
|  >
|  >
|  >
|  >
|  
|  _______________________________________________
|  savi mailing list
|  savi at ietf.org
|  https://www.ietf.org/mailman/listinfo/savi