Subject: [savi] Framework Document Suggestion

From: Christian Vogt <[email-masked]>
Date: Thu, 22 Oct 2009 16:01:59 -0700

SAVI folks -

As part of our recent consensus-based decision for separate documents on
DHCP-assigned IP source addresses and on SLAAC-assigned IP source
addresses, we agreed to create a framework document that describes the
relationship between, and common principles of, the various IP address
validation types.  Here is a suggestion of how such a framework document
may look like:

http://tools.ietf.org/id/draft-vogt-savi-framework

Your feedback on this document is highly appreciated.  Please read and
comment.

- Christian

---

From: Dong Zhang <[email-masked]>
Date: Fri, 23 Oct 2009 10:45:14 +0800

Hi Christian,

I remember that the framework document would inlcude the relationship between
DHCP-assigned IP source addresses and SLAAC-assigned IP source addresses 
according to the discussion in ml, but it seems that the description about the 
relationship is not quit clear in draft-vogt-savi-framework. Therefore, I 
suppose the framework document should has an introduction for the components of 
savi protocol instances and include in what case which savi protocol instance 
is used better.

Nowthat there is the possibility of co-existence of multiple protocol instances, 
the interoperability needs to be considered. Is it possible to set priority for 
the savi protocol instances according to some qualifications? If so, it 
facilitates choosing the savi protocol instance which is more reliable and 
effective.

Additionally, in section "IP Address Assignment Methods", I think it could 
comprises these types: static address, dhcp address, SLAAC address, CGA address 
and manual address.

Thank you.
B.R.

------------------				 
Dong Zhang
2009-10-23

---

From: Christian Vogt <[email-masked]>
Date: Fri, 23 Oct 2009 11:59:38 -0700

Dong -

Your recollection is correct; the Framework document should and will
include the properties of, and the relationship between, the various IP
address assignment methods.  Section 3.1 in the current Framework
document version is a placeholder for this.  Text for this section is
still to be added, as noted in the document.  And yes, this text shall
cover not only SLAAC and DHCP, but also SEND and manual IP address
configuration.

- Christian

On Oct 22, 2009, Dong Zhang wrote:

> Hi Christian,
>
> I remember that the framework document would inlcude the relationship
> between DHCP-assigned IP source addresses and SLAAC-assigned IP source
> addresses  according to the discussion in ml, but it seems that the
> description about the  relationship is not quit clear in
> draft-vogt-savi-framework. Therefore, I  suppose the framework  
> document
> should has an introduction for the components of  savi protocol
> instances and include in what case which savi protocol instance  is  
> used
> better.
>
> Nowthat there is the possibility of co-existence of multiple protocol
> instances,  the interoperability needs to be considered. Is it  
> possible
> to set priority for  the savi protocol instances according to some
> qualifications? If so, it  facilitates choosing the savi protocol
> instance which is more reliable and  effective.
>
> Additionally, in section "IP Address Assignment Methods", I think it
> could  comprises these types: static address, dhcp address, SLAAC
> address, CGA address  and manual address.
>
>
> Thank you. B.R.

---

From: Dong Zhang <[email-masked]>
Date: Thu, 29 Oct 2009 10:35:48 +0800

Hi Christian,

>cover not only SLAAC and DHCP, but also SEND and manual IP address
My concern is that as a vendor, it may implement the savi approaches, 
including fcfs approach, cps approach and SEND approach. So how to coordinate
them needs to be considered. I mean all the approaches work together or choose
one to work. I guess it could be the latter. If so, the condition for choosing 
each approach should be illustrated unambiguously.
However, I assumed that there is still an exception, which means several 
address assignment methods exist in one case. How do the savi approaches deal 
with this case?

Thanks.
------------------				 
Dong Zhang

---

From: Christian Vogt <[email-masked]>
Date: Wed, 28 Oct 2009 23:56:52 -0400

On Oct 28, 2009, Dong Zhang wrote:

> including fcfs approach, cps approach and SEND approach. So how to
> coordinate them needs to be considered. I mean all the approaches work
> together or choose one to work. I guess it could be the latter. If so,
> the condition for choosing  each approach should be illustrated
> unambiguously.

Yes, I agree.

> However, I assumed that there is still an exception, which means
> several  address assignment methods exist in one case. How do the savi
> approaches deal  with this case?

For this case, we need a prioritization of which address assignment
methods take precedence over which other address assignment methods.
And you are right that the definition of this prioritization will
require care.

Does this make sense?  Does it address your question and comment?

- Christian

---

From: Dong Zhang <[email-masked]>
Date: Thu, 29 Oct 2009 13:00:35 +0800

>Does this make sense?  Does it address your question and comment?
Yes, it makes sense.
Thanks.
>- Christian

------------------				 
Dong Zhang
2009-10-29

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 Oct 2009 07:50:20 +0100

> And you are right that the definition of this prioritization will
yes, moreover, we need to figure if it is enough with a prioritazation 
or we need to change the mechanisms in order to interact properly. As i 
stated earlier (and eric noted before me), we certainly need to update 
send savi to properly interact with the slaac savi (at least, haven't 
doen the analysis for dhcp savi yet)

Regards, marcelo

> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>
>

---

From: Alberto García <[email-masked]>
Date: Thu, 29 Oct 2009 11:04:09 +0100

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
marcelo
|  bagnulo braun
|  Enviado el: jueves, 29 de octubre de 2009 7:50
|  Para: Christian Vogt
|  CC: SAVI Mailing List
|  Asunto: Re: [savi] A few comments on draft-vogt-savi-framework
|  
|  Christian Vogt escribió:
|  > On Oct 28, 2009, Dong Zhang wrote:
|  >
|  >
|  >> My concern is that as a vendor, it may implement the savi approaches,
|  >> including fcfs approach, cps approach and SEND approach. So how to
|  >> coordinate them needs to be considered. I mean all the approaches work
|  >> together or choose one to work. I guess it could be the latter. If so,
|  >> the condition for choosing  each approach should be illustrated
|  >> unambiguously.
|  >>
|  >
|  > Yes, I agree.
|  >
|  >
|  >> However, I assumed that there is still an exception, which means
|  >> several  address assignment methods exist in one case. How do the savi
|  >> approaches deal  with this case?
|  >>
|  >
|  > For this case, we need a prioritization of which address assignment
|  > methods take precedence over which other address assignment methods.
|  > And you are right that the definition of this prioritization will
|  > require care.
|  >
|  >
|  yes, moreover, we need to figure if it is enough with a prioritazation
|  or we need to change the mechanisms in order to interact properly. As i
|  stated earlier (and eric noted before me), we certainly need to update
|  send savi to properly interact with the slaac savi (at least, haven't
|  doen the analysis for dhcp savi yet)
|  
|  Regards, marcelo

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

|  
|  
|  
|  > Does this make sense?  Does it address your question and comment?
|  >
|  > - Christian
|  >
|  >
|  > _______________________________________________
|  > savi mailing list
|  > [email-masked]
|  > https://www.ietf.org/mailman/listinfo/savi
|  >
|  >
|  
|  _______________________________________________
|  savi mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi

---

From: Christian Vogt <[email-masked]>
Date: Thu, 29 Oct 2009 16:24:57 -0400

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?

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 29 Oct 2009 16:24:01 -0400

> doen the analysis for dhcp savi yet)

Correct; the prioritization may affect the protocol specifications
(SLAAC, DHCP, SEND) just as well as it affects the framework document.

My suggestion -- as a working group member, not as a chair -- is that
the framework document should talk about the prioritization
conceptually, whereas the protocol specifications need to include the
details that implement the prioritization.  Thoughts?

- Christian

---

From: Dong Zhang <[email-masked]>
Date: Fri, 30 Oct 2009 09:08:18 +0800

Hi,

>details that implement the prioritization.  Thoughts?
I think prioritization is an essential part. And I have already express 
this consideration in 
http://www.ietf.org/mail-archive/web/savi/current/msg00949.html

Thank you.
------------------				 
Dong Zhang
2009-10-30

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 30 Oct 2009 08:50:55 +0100

> handle non-SEND-capable SAVI devices.
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

Regards, marcelo

---

From: Alberto García <[email-masked]>
Date: Fri, 30 Oct 2009 12:50:10 +0100

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] 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
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi

---

From: Alberto García <[email-masked]>
Date: Fri, 30 Oct 2009 12:50:10 +0100

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
|  Christian Vogt
|  Enviado el: jueves, 29 de octubre de 2009 21:24
|  Para: Marcelo Bagnulo Braun
|  CC: SAVI Mailing List
|  Asunto: Re: [savi] A few comments on draft-vogt-savi-framework
|  
|  
|  On Oct 28, 2009, marcelo bagnulo braun wrote:
|  
|  >> For this case, we need a prioritization of which address assignment
|  >> methods take precedence over which other address assignment methods.
|  >> And you are right that the definition of this prioritization will
|  >> require care.
|  >>
|  >
|  > yes, moreover, we need to figure if it is enough with a prioritazation
|  > or we need to change the mechanisms in order to interact properly.
|  > As i
|  > stated earlier (and eric noted before me), we certainly need to update
|  > send savi to properly interact with the slaac savi (at least, haven't
|  > doen the analysis for dhcp savi yet)
|  
|  Correct; the prioritization may affect the protocol specifications
|  (SLAAC, DHCP, SEND) just as well as it affects the framework document.
|  
|  My suggestion -- as a working group member, not as a chair -- is that
|  the framework document should talk about the prioritization
|  conceptually, whereas the protocol specifications need to include the
|  details that implement the prioritization.  Thoughts?

Fully agree. It should be stated which is preferred over what, and a good
place for this is the framework document.
And I still believe that there is much more to detail after the general
scheme of prioritization has been stated. In particular, for SEND and SLAAC
interaction (maybe not for DHCP, this should be studied).

Regards,
Alberto

|  
|  - Christian
|  
|

---

From: Christian Vogt <[email-masked]>
Date: Fri, 30 Oct 2009 16:31:13 -0400

Forked from thread "A few comments on draft-vogt-savi-framework".

> presence of send capable hosts.

For the record:  s/slaac send/slaac savi/

Absolutely.  In my opinion, the optimal solution would include separate
SAVI SLAAC and SAVI SEND protocols, both designed for co-existence, but
with minimal functionality specific to the respective other protocol. In
particular, the SAVI SLAAC protocol should avoid complex SEND-specific
functionality.  An optimal solution would also allow non-SEND hosts to
attach to SAVI SEND switches, and SEND hosts to attach to SAVI SLAAC
switches.  Such "interworking" may lead to sub-optimal protectiveness of
SAVI, as Alberto notes, but it should not interfere with the hosts.

Assuming we succeed in engineering this optimal solution, we would
minimize the cost of SAVI SLAAC switches, while still enabling the
incremental deployment of SAVI SEND switches in a network with SAVI
SLAAC switches.  Also, the use of SAVI SLAAC switches would not hinder
the deployment of SEND, as SAVI SLAAC switches would simply provide less
protectiveness compared to what was possible with SAVI SEND switches.

Is this a reasonable goal?  Any concerns, changes, or additions?

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 30 Oct 2009 16:52:01 -0400

On Oct 30, 2009, Alberto García wrote:

> 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.

A good observation indeed.

I personally (not as a working group chair) agree with you that this
issue is minor, given the low probability for it to happen -- assuming,
as you say, that the attacker is behind a SAVI device. Yet, co-existence
issues like this one should be carefully documented.  Perhaps every SAVI
protocol specification should include a section on co-existence with
SAVI protocol instances for other address assignment methods?

- Christian