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
Eric
|  Levy-Abegnoli
|  Enviado el: lunes, 02 de noviembre de 2009 11:42
|  Para: Christian Vogt
|  CC: SAVI Mailing List; Alberto García
|  Asunto: Re: [savi] A few comments on draft-vogt-savi-framework
|  
|  Christian,
|  Christian Vogt a écrit :
|  
|  	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.
|  
|  
|  As we are centralizing the co-existence decisions in a
"man-in-the-middle" savi-
|  device, we can't just consider that the capability of the savi-device
(SeND, not
|  SeND) are it's sole problem. Which "looks" the case if the co-existence
scenarios
|  are described in the savi-SeND protocol specification.

I don't understand this. What's the problem with a situation in which the
manager of the network configures SAVI devices...
- in SLAAC-only mode if it knows no SEND hosts are there
- in SEND-only mode if it knows all hosts are SEND
- in SLAAC-SEND-compatible mode if it knows the network has SEND and no SEND
hosts.
I assume that deploying SAVI is going to require some management (we have
assumed that when stating that there are roles such as Trusted and
Validating). For SEND even more configuration is required in the SAVI
devices (i.e. trust anchors). 
SEND hosts also need to be configured with trust anchors for processing
correctly secured RADV. (well, the manager may not know if two hosts
configure CGAs just for communication among themselves, but, is this the
general case? )
So, the manager will provide the appropriate SAVI operation mode. 

In addition, the compatible mode should work fine for both types of hosts. A
manager with SAVI devices capable of this, and with any suspicion that a
SEND host may appear, may set up the SAVI devices to be in this mode. 

Do you think this deployment model for SAVI is reasonable?

|  A savi device not SEND-capable breaks RFC3971. 
Yes, so when a SEND host exists, SAVI must be SEND enabled.

|  Like a bridge that would mess
|  with L3 messages. And it has no way to know. 

This is where I kindly disagree.
Regards,
Alberto

|  Can we **really** specify that?
|  There might be thousands of non-SeND capable nodes on the link, and just
one
|  signle pair of SeND nodes, and this SAVI-switch in the middle is
completely
|  messing with their "standard" behavior.  Note that there **are** such
|  deployments out there. And the deployments scenarios are exactly that
(few
|  SeND critical nodes, many non-SeND).
|  So I think the description of this scenario, and associated warnings
should show
|  up either in all documents, or in a higher level doc( framework, or
other).
|  Eric
|  
|  
|  	Does this make sense?
|  
|  	- 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
|  
|  
|