Subject: [savi] SLAAC-SAVI and host address configuration

From: Alberto García <[email-masked]>
Date: Thu, 10 Dec 2009 11:00:18 +0100

Hi,

Regarding to the SLAAC-SAVI mechanism proposed so far
(draft-ietf-savi-fcfs-02), I think that there are some caveats in the
behavior of SLAAC hosts when they are in the process of configuring their
own addresses (i.e. when the address of the host is still tentative). 

Suppose that a host has configured an address, has a valid binding in a SAVI
device, and then it restarts the network configuration so the address is
configured again, DAD is executed by sending a DAD NSOL message, etc. (for
example, the user powers down and up the host - it happens all the time
:-)). Suppose that while the host is performing DAD and the SAVI device was
in VALID state for this address, the lifetime timer expires in the SAVI
device. Current specification says that the SAVI device sends a DAD_NSOL
message to the host, and changes the state to TESTING_LIFETIME. But in this
particular case (the host is still configuring its address) the DAD_NSOL
message stops address configuration in the host (instead of generating a
DAD_NADV). Current SAVI design assumes that sending DAD_NSOL is in general
side-effect free for hosts, while this is not the case when the hosts are in
the process of configuring its own address. 

Note that the same problem occurs when a host is configuring its address and
another host tries to use the same address either in a validating port of
the same SAVI device, or in another SAVI device: current specification
assumes that the first host can answer to DAD_NSOL messages, while this is
not the case if it is configuring its address.

I think the solution for this is to create a WAIT_FOR_CONFIG state. If a
host is in VALID, TESTING_TP, or TESTING_VP state, and a DAD_NSOL is
received from the port currently associated to the binding, the SAVI device
moves to this state and lifetime is set to LIFETIME. While the SAVI device
is in this state, messages from other hosts are not considered (in
particular, DAD_NSOL messages are not forwarded to the host configuring its
address). The state moves to VALID when the lifetime expires, or when data
packets are received from the current validating port (because in this case
we know the address configuration process has finished). The underlying
supposition for this behavior is that if a host sends a DAD_NSOL message
from the port from which a binding exists, (a) the host is proving that it
is alive and (b) this host in this port is supposed to be more legitimate
than other hosts trying to use the address in other ports at the same time.
Therefore, the address configuration procedure for this host should be
protected, as well as the binding for it.

Do you think this makes sense?

Regards,

Alberto

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 10 Dec 2009 18:22:50 +0800

Hi, Alberto

DAD_NSOL should never be sent to the host who is supposed to use the target
address. And it is not necessary. Actually this case is mention in DHCP
solution draft and the corresponding slides of IETF76.

If a probe should be sent to host to detect alive, use NSOL but not DAD
NSOL.

BR,

Guang

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alberto García
Sent: Thursday, December 10, 2009 6:00 PM
To: 'SAVI Mailing List'
Subject: [savi] SLAAC-SAVI and host address configuration

Hi,

Suppose that a host has configured an address, has a valid binding in a SAVI
device, and then it restarts the network configuration so the address is
configured again, DAD is executed by sending a DAD NSOL message, etc. (for
example, the user powers down and up the host – it happens all the time J).
Suppose that while the host is performing DAD and the SAVI device was in
VALID state for this address, the lifetime timer expires in the SAVI device.
Current specification says that the SAVI device sends a DAD_NSOL message to
the host, and changes the state to TESTING_LIFETIME. But in this particular
case (the host is still configuring its address) the DAD_NSOL message stops
address configuration in the host (instead of generating a DAD_NADV).
Current SAVI design assumes that sending DAD_NSOL is in general side-effect
free for hosts, while this is not the case when the hosts are in the process
of configuring its own address. 

Regards,

Alberto

---

From: Alberto García <[email-masked]>
Date: Thu, 10 Dec 2009 13:29:01 +0100

Hi Guang,

I agree that it is a good idea to use (unicast address sourced) NSOL instead
of DAD_NSOL for the messages that the SAVI device synthesize to check if a
host is still in the port or not (when it is in VALID state and the lifetime
timer expires, or when a data packet is received from a Validating port
different to the current binding). 

But my question goes further: if the SAVI host receives a DAD_NSOL from the
port through which a binding exists, do we want to protect the binding from
other hosts sending DAD_NSOL messages? (in this period, the host at the port
with the binding is not defending its address)

We could, if we wanted (by means of something like the WAIT_FOR_CONFIG state
I commented), by making the SAVI device defending the address by sending
DAD_NADV. I think the point to discuss is if it is reasonable to prefer a
host that is configuring an address in the port for which we have a binding,
over hosts doing the same in other locations. 

As it is currently defined, there are many situations in which a host in
other ports would configure the address even if a host is trying so in the
port for which a binding exists.

Has this being discussed in IETF76?

Regards,

Alberto

  _____  

De: Guang Yao [mailto:[email-masked]] 
Enviado el: jueves, 10 de diciembre de 2009 11:23
Para: 'Alberto García'
CC: 'SAVI Mailing List'
Asunto: RE: [savi] SLAAC-SAVI and host address configuration

Hi, Alberto

BR,

Guang

Hi,

Regards,

Alberto

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 15 Dec 2009 17:28:20 +0800

Hi, Alberto

Maybe we must protect the binding. Or else there may some kind of attacking.
For example, a host may send a DAD_NSOL for the same address immediately
after it receives the first one. So, protecting the first one will do no
evil, although it is always hard to know who is the real first one.

However, this protection is aggressive and  violates DAD. RFC4862 implies if
there are simultaneous DAD NSOLs, none can use the tentative address. Maybe
no perfect solution here for the tradeoff of security and fairness.

A very rare situation: two SAVI devices may protect the same address from
each other by sending DAD_NADV. Thus binding should not be protected from
DAD_NADV.

I think you have made a good point.

BR,

Guang

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alberto García
Sent: Thursday, December 10, 2009 8:29 PM
To: 'Guang Yao'
Cc: 'SAVI Mailing List'
Subject: Re: [savi] SLAAC-SAVI and host address configuration

Hi Guang,

Regards,

Alberto

  _____  

Hi, Alberto

BR,

Guang

Hi,

Regards,

Alberto

---

From: Alberto García <[email-masked]>
Date: Tue, 15 Dec 2009 11:58:06 +0100

Hi,

Thanks for your comments.

I think there are two different issues:

1- When a binding exists for an address in a SAVI device. A host connected
to the port associated to the binding can turn down and then up, and send a
DAD_NSOL. In this case, I think it should be fair to preserve the existing
binding and defend the address, based on the past events (there was a host
that successfully obtained a binding, and the time since the host defended
its right to have the binding is very short). If we want to protect this, no
DAD_NSOL should be forwarded to the host, and the SAVI device should defend
the address for other ports (sending DAD_NADV) while the host cannot do
that. 

I think it is nice to allow hosts to keep their addresses if address
reconfiguration occurs in a short period of time

>From DAD perspective, although it is not the behavior specified in RFC4862,
I think it is not opposed to its spirit, in the sense that here we have a
criteria to decide which node "deserves most" the address, the one that had
the binding first. For the hosts it is not an operational problem (only
changes which host wins in a collision) 

What do you think about this case?

2- When there is no binding for the address in a SAVI device, and two hosts
try to use the same address. In this case, I agree we do not have any
SAVI-specific clue to decide which should succeed. In RFC4862 two things may
occur: either none of them configure the address (because both hosts start
address configuration, send DAD_NSOL, and both receive the DAD_NSOL of the
other when they are in tentative state), or the last one configures its
address (one starts address configuration well before the other, sends
DAD_NSOL but the other host is not configuring the address yet so it is not
considered; some time later the other starts address configuration, sends
its DAD_NSOL and stops address configuration for the first host). 

The current SAVI specification does not address this collision in the
address configuration (says nothing about DAD_NSOL received in TENTATIVE
state). To address this case, 

-        in TENTATIVE state if a DAD_NSOL is received for the same address
from a validating port P', it should be forwarded to the Validating port P
(this will stop address configuration in the host at P), and the state
should remain in TENTATIVE, but now testing port P' (the last one, and the
port that may succeed). Note that the SAVI devices cannot know if the second
host will succeed in its address configuration or not (this depends on the
time at which the DAD_NSOL message of the first host arrived), but we know
that the host at P will not succeed, so moving the binding to tentative the
binding for P' (which can configure its address or not) seems appropriate.

-        In TENTATIVE state if a DAD_NSOL is received from a trusted port,
the state is changed to NO_BIND. The host in the local port will not
succeed. 

An additional thing should be discussed: currently, there is equal treatment
when either a DAD_NSOL or a data packet arrives when SAVI is in NO_BIND
state (send DAD_NSOL and move to TENTATIVE). However, the host sending data
(this means it has its address configured) should not be treated equally if
a DAD_NSOL is received: in this case I think we should protect the binding
for this host since it will not unconfigure the address when receiving a
DAD_NSOL. DAD_NADV from other SAVI device should move the state to NO_BIND,
but DAD_NSOL messages should be just forwarded to the host to let it defend
the address. To implement this different behavior, I think the TENTATIVE
state should be forked into a TENTATIVE_DAD_NSOL and TENTATIVE_DATA
(depending on the packet being received when the SAVI device was in
NO_BIND).

I don't think this enables any attack (which could not be made using
DAD_NSOL), since it protects the host first using the address (with data).
What do you think?

Regarding to the attack you comment, a DAD_NSOL sent immediately after it
receives other DAD_NSOL, yes it can occur. Some degree of protection is
provided if IGMP snooping is enabled, since only hosts subscribing to the
Solicited node address can receive DAD_NSOL. It is very difficult to protect
even for SAVI since you cannot identify when the second DAD_NSOL is a reply
or a legitimate collision. If you don't want to suffer from this, SEND is
the answer (although this issue is not specifically solved in the RFCs,
solutions are straightforward because there is some material that should be
different if generated by different hosts).

I don't find the situation in which the following occurs: "A very rare
situation: two SAVI devices may protect the same address from each other by
sending DAD_NADV. Thus binding should not be protected from DAD_NADV." Can
you explain?

Regards,

Alberto

  _____  

De: Guang Yao [mailto:[email-masked]] 
Enviado el: martes, 15 de diciembre de 2009 10:09
Para: 'Alberto García'
CC: 'SAVI Mailing List'
Asunto: RE: [savi] SLAAC-SAVI and host address configuration

Hi, Alberto

BR,

Guang

Hi Guang,

Regards,

Alberto

  _____  

Hi, Alberto

BR,

Guang

Hi,

Regards,

Alberto

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 17 Dec 2009 12:27:43 +0800

Hi, Alberto

Please see my comments inline.

BR,

Guang

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alberto García
Sent: Tuesday, December 15, 2009 6:58 PM
To: 'Guang Yao'
Cc: 'SAVI Mailing List'
Subject: Re: [savi] SLAAC-SAVI and host address configuration

Hi,

1-     When a binding exists for an address in a SAVI device. A host
connected to the port associated to the binding can turn down and then up,
and send a DAD_NSOL. In this case, I think it should be fair to preserve the
existing binding and defend the address, based on the past events (there was
a host that successfully obtained a binding, and the time since the host
defended its right to have the binding is very short). 

[Guang Yao] 

A situation: the host changes to another port, and sends DAD_NSOL for its
previous address. (And the previous port is attached by another host
immediately.)

If the address is preserved, the moving host has to configure another
address.

This protection will actually disturb smooth port movement.

If we want to protect this, no DAD_NSOL should be forwarded to the host, and
the SAVI device should defend the address for other ports (sending DAD_NADV)
while the host cannot do that. 

[Guang Yao] 

I agree it’s nice to keep address for a short time, if and only if there is
not a DAD_NSOL.

Though this may allow some kind of scanning attack against a disconnected
host, it’s not very bad for the host can always use another address.

I think it is not opposed to its spirit, in the sense that here we have a
criteria to decide which node “deserves most” the address, the one that had
the binding first. For the hosts it is not an operational problem (only
changes which host wins in a collision) 

[Guang Yao] 

IMO, for a SAVI solution, it’s better to make sure only one host is
configured the tentative address. Even none is better than both.

However, It’s a real hard problem for current RFC4862. If there is a
timestamp in DAD_NSOL, and DAD is sensitive to the timestamp, things may be
easier to handle.

-     in TENTATIVE state if a DAD_NSOL is received for the same address from
a validating port P’, it should be forwarded to the Validating port P (this
will stop address configuration in the host at P), and the state should
remain in TENTATIVE, but now testing port P’ (the last one, and the port
that may succeed). Note that the SAVI devices cannot know if the second host
will succeed in its address configuration or not (this depends on the time
at which the DAD_NSOL message of the first host arrived), but we know that
the host at P will not succeed, so moving the binding to tentative the
binding for P’ (which can configure its address or not) seems appropriate.

-     In TENTATIVE state if a DAD_NSOL is received from a trusted port, the
state is changed to NO_BIND. The host in the local port will not succeed. 

I don’t think this enables any attack (which could not be made using
DAD_NSOL), since it protects the host first using the address (with data).
What do you think?

[Guang Yao] 

An attack: an attacker receives a DAD_NSOL, and sends data packet
immediately.

I find it’s very hard to judge if there is no rule. Maybe we should define
the rules in DAD.

or a legitimate collision. If you don’t want to suffer from this, SEND is

[Guang Yao] 

Typical SAVI device is layer-2 switch. And IGMP snooping wouldn’t help in
such devices.

This attack is too easy . I’m afraid it may be used to argue how fragile
SAVI is.

I don’t find the situation in which the following occurs: “A very rare
situation: two SAVI devices may protect the same address from each other by
sending DAD_NADV. Thus binding should not be protected from DAD_NADV.” Can
you explain?

[Guang Yao] 

It means, two SAVI devices get a DAD_NSOL from local nearly simultaneously,
and then get the DAD_NSOL from each other. If both of they want to protect
local binding, there will be two bindings in the network for one address.
But anyway, it’s a really rare situation.

Regards,

Alberto

  _____  

Hi, Alberto

BR,

Guang

Hi Guang,

Regards,

Alberto

  _____  

Hi, Alberto

BR,

Guang

Hi,

Regards,

Alberto

---

From: Alberto García <[email-masked]>
Date: Thu, 17 Dec 2009 20:16:48 +0100

Hi,

Also inline

  _____  

De: Guang Yao [mailto:[email-masked]] 
Enviado el: jueves, 17 de diciembre de 2009 5:28
Para: 'Alberto García'
CC: 'SAVI Mailing List'
Asunto: RE: [savi] SLAAC-SAVI and host address configuration

Hi, Alberto

BR,

Guang

Hi,

[Guang Yao] 

[Alberto] This problem occurs only when the node has made DAD_NSOL _and_
then moves. And it lasts for LIFETIME since the host issued a DAD_NSOL.

The choices are:

-   protect hosts turning down and up their addresses, and let a node doing
that not be able to communicate after moving during LIFETIME time

-   don't protect hosts turning down and up their addresses (let anybody
generate a binding for this address in this case).

I think we have to choose one. 

[Guang Yao] 

I agree it's nice to keep address for a short time, if and only if there is
not a DAD_NSOL.

[Alberto]: I don't understand. Maybe "if and only if there is a DAD_NSOL"?

Though this may allow some kind of scanning attack against a disconnected
host, it's not very bad for the host can always use another address.

[Guang Yao] 

IMO, for a SAVI solution, it's better to make sure only one host is
configured the tentative address. Even none is better than both.

However, It's a real hard problem for current RFC4862. If there is a
timestamp in DAD_NSOL, and DAD is sensitive to the timestamp, things may be
easier to handle.

-   in TENTATIVE state if a DAD_NSOL is received for the same address from a
validating port P', it should be forwarded to the Validating port P (this
will stop address configuration in the host at P), and the state should
remain in TENTATIVE, but now testing port P' (the last one, and the port
that may succeed). Note that the SAVI devices cannot know if the second host
will succeed in its address configuration or not (this depends on the time
at which the DAD_NSOL message of the first host arrived), but we know that
the host at P will not succeed, so moving the binding to tentative the
binding for P' (which can configure its address or not) seems appropriate.

[Guang Yao] 

[Alberto] This is the attack I describe in the next paragraph. The solution
is to use SEND (IGMP snooping also provides some protection)

I find it's very hard to judge if there is no rule. Maybe we should define
the rules in DAD.

[Guang Yao] 

Typical SAVI device is layer-2 switch. And IGMP snooping wouldn't help in
such devices.

This attack is too easy . I'm afraid it may be used to argue how fragile
SAVI is.

[Alberto] Yes. I prefer to see it as a nice incentive for SEND.

[Guang Yao] 

It means, two SAVI devices get a DAD_NSOL from local nearly simultaneously,
and then get the DAD_NSOL from each other. If both of they want to protect
local binding, there will be two bindings in the network for one address.
But anyway, it's a really rare situation.

[Alberto] Ummm. Not sure of what you are talking about. If DAD_NSOLs are
issued almost simultaneously, the case 2) discussed above applies in
general. And only one binding is created. 

Can you detail a case in which two bindings are created?

Regards,

Alberto

  _____  

Hi, Alberto

BR,

Guang

Hi Guang,

Regards,

Alberto

  _____  

Hi, Alberto

BR,

Guang

Hi,

Regards,

Alberto

---

From: Christian Vogt <[email-masked]>
Date: Tue, 22 Dec 2009 19:06:07 +0100

On Dec 10, 2009, Alberto García wrote:

> But my question goes further: if the SAVI host receives a DAD_NSOL  
> from
> the port through which a binding exists, do we want to protect the
> binding from other hosts sending DAD_NSOL messages?

This is a good observation.  But is this case really worth being dealt
with separately?  Keep in mind that one of this working group's high-
level design goals is simplicity; it is OK not to have optimal behavior
in all corner cases.  In my opinion, this applies in particular to the
case you are describing, since the vulnerability of hosts re-configuring
their IP address already exists with regular SLAAC.

- Christian

---

From: Alberto García <[email-masked]>
Date: Wed, 23 Dec 2009 16:08:42 +0100

Hi Christian,

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
|  Christian Vogt
|  Enviado el: martes, 22 de diciembre de 2009 19:06
|  Para: Alberto García
|  CC: 'SAVI Mailing List'; 'Guang Yao'
|  Asunto: Re: [savi] SLAAC-SAVI and host address configuration
|  
|  On Dec 10, 2009, Alberto García wrote:
|  
|  > But my question goes further: if the SAVI host receives a DAD_NSOL
|  > from
|  > the port through which a binding exists, do we want to protect the
|  > binding from other hosts sending DAD_NSOL messages?
|  
|  This is a good observation.  But is this case really worth being dealt
|  with separately?  Keep in mind that one of this working group's high-
|  level design goals is simplicity; it is OK not to have optimal behavior
|  in all corner cases.  In my opinion, this applies in particular to the
|  case you are describing, since the vulnerability of hosts re-configuring
|  their IP address already exists with regular SLAAC.

I assume we want to increase protection against vulnerabilities existing in
regular SLAAC (otherwise, we would not be defining SAVI). 
Although, of course, I admit the addition of each particular feature is
debatable. 
The cost in implementation effort for this case is roughly increasing one
state the state machine (from 6 to 7 states -> around 15% of code,
considering that in all states all events to consider are more or less the
same). 
Considering the frequency of this event, it occurs naturally in "some" cases
(eg. when popular OS receive an OS update and ask you to reboot the system,
when it crashes, ...). Although I don't know if it occurs in so "many" cases
to justify its deployment. 

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

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Dec 2009 17:40:42 +0100

On Dec 23, 2009, at 16:08, Alberto García wrote:

> Considering the frequency of this event, it occurs naturally in "some"
> cases (eg. when popular OS receive an OS update and ask you to reboot
> the system, when it crashes, ...). Although I don't know if it  
> occurs in
> so "many" cases to justify its deployment.

The extra state you are proposing would be of benefit for hosts with
statically configured addresses, right?  Other hosts wouldn't care which
IP address they get after a reboot, so there is no need to protect an
old IP address for those hosts during reboot.

The question is hence how important we consider the case of hosts with
statically configured addresses.  What's your opinion?  What do others
think?

- Christian

---

From: Alberto García <[email-masked]>
Date: Tue, 29 Dec 2009 12:21:40 +0100

Hi Christian,

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
|  Christian Vogt
|  Enviado el: miércoles, 23 de diciembre de 2009 17:41
|  Para: Alberto García
|  CC: 'SAVI Mailing List'; 'Guang Yao'
|  Asunto: Re: [savi] SLAAC-SAVI and host address configuration
|  
|  On Dec 23, 2009, at 16:08, Alberto García wrote:
|  
|  > Considering the frequency of this event, it occurs naturally in "some"
|  > cases (eg. when popular OS receive an OS update and ask you to reboot
|  > the system, when it crashes, ...). Although I don't know if it
|  > occurs in
|  > so "many" cases to justify its deployment.
|  
|  The extra state you are proposing would be of benefit for hosts with
|  statically configured addresses, right?  Other hosts wouldn't care which
|  IP address they get after a reboot, so there is no need to protect an
|  old IP address for those hosts during reboot.

First, one question: when you talk about "statically configured addresses",
are you referring also to SLAAC addresses? In the discussion above, I think
the benefit would be for any SLAAC-configured (RFC4862) address, since it is
not clear to me that the behavior of RFC4862 hosts is different to
statically configured address when the address tried in the first time (and
maybe configured some time before) is used by other host when the node
reboot. Although the solution for SLAAC hosts could be just to generate
randomly a new address, it is not clear to me that SLAAC hosts do this.
RFC4862 5.4.5 suggests "just disabling network operation on the interface"
(From my point of view, RFC4862 is a bit naïve by assuming that duplicate
address only come from layer-2 address duplication, and not from an attack,
but...). A Microsoft note
(http://msdn.microsoft.com/en-us/library/aa917171.aspx) says "If duplicate
address detection fails, you must manually configure the node"... 
It is not clear to me what other SLAACnimplementations do when an address is
already in use, but may be not try a completely new address. 
(By the way, SEND has a more defined behavior for this case - try up to 3
addresses by changing a field, and only accept secured responses for the
last 2 tries.)

However, I agree that conceptually there is not much difference between a
host that reboot shortly after being communicating and a host that connects
again much later. In the last case it is not easy to provide means to
protect the address, so maybe it does not worth the effort to protect the
first case (even if we technically could).

Regards,
Alberto

|  
|  The question is hence how important we consider the case of hosts with
|  statically configured addresses.  What's your opinion?  What do others
|  think?
|  
|  - Christian
|  
|  
|  _______________________________________________
|  savi mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi

---

From: Christian Vogt <[email-masked]>
Date: Tue, 29 Dec 2009 09:00:05 -0500

Hi Alberto -

> First, one question: when you talk about "statically configured
> addresses", are you referring also to SLAAC addresses? In the  
> discussion
> above, I think the benefit would be for any SLAAC-configured (RFC4862)
> address [...]

I agree with you that your proposal would affect any SLAAC-configured IP
address.  But my point was that your proposal has real value only for
manually pre-configured IP addresses.  For these IP addresses, a DAD
collision is harmful because it breaks the pre-configuration.  For other
IP addresses, a DAD collision is not harmful:  They can be replaced
without breaking a pre-configuration and, after a reboot, there are also
no active sessions that would break due to the IP address change.  Does
this make sense?

This said, I take you point that a DAD collision can cause hosts to be
unable to communicate:

> Although the solution for SLAAC hosts could be just to generate  
> randomly
> a new address, it is not clear to me that SLAAC hosts do this. RFC4862
> 5.4.5 suggests "just disabling network operation on the interface"

But keep in mind that your proposal doesn't fully solve this problem: If
you reserve the IP address for the original owner, then the other host
trying to configure this IP address is screwed.  If you don't reserve
the IP address, the original owner is screwed.  In fact, one would need
to augment SLAAC with better DAD collision recovery mechanisms in order
to solve this problem fully.  And perhaps this is something we should
propose to the 6man working group?

Thoughts?

- Christian