Subject: [savi] Binding establishment based on data or control packets?

From: Christian Vogt <[email-masked]>
Date: Wed, 7 Jan 2009 16:48:13 -0800

Dear all -

Marcelo and Guang had an interesting discussion on whether FCFS SAVI
should establish bindings based on data packets or based on control
packets.  I would like to follow up on this.

To summarize:  Whereas draft-bagnulo-savi-fcfs proposes the exclusive
use of data packets to establish bindings, Guang believes that bindings
should be established exclusively based on control packets.  According
to Guang, the advantage of exclusively using control packets to
establish bindings would be a better means to synchronize hosts and SAVI
devices regarding a host's right to use an address.  The standard way
for hosts to determine their right to use an address is via the
Duplicate Address Detection or DHCP procedure, whereas according to
draft-bagnulo-savi-fcfs, SAVI devices determine such right based on
previously received data packets.  The use of different procedures for
hosts and SAVI devices raises the question of whether hosts and SAVI
devices may lose sync regarding the right to use an address.

One case where this is an issue, as brought up by Guang, is the
deliberate establishment of bogus bindings by an attacker in order to
keep a victim host from aquiring a functioning address.  The Neighbor
Solicitation message that the victim host must send during the Duplicate
Address Detection procedure discloses the address that the victim host
is trying to acquire without establishing a binding for the address.
This enables the attacker to establish a bogus binding, and hence to
make the address dysfunctional for the victim host, by sending a data
packet that appears to originate from the address.

To prevent this attack, Guang concludes that bindings should exclusively
be established based on control packets, i.e., based on monitoring the
messages exchanged during the Duplicate Address Detection or DHCP
procedure.  Like Marcelo, I agree with this partly, but not entirely:
Although using control packets for binding establishment is necessary to
prevent the attack described above, it is not required that control
packets are used /exclusively/.  Using both, control and data packets,
for binding establishment would be possible as well.

More specifically, the reason for the aforementioned attack is the
existence of a shortcut for binding establishment, which is
non-legitimate, but which is not prevented either.  To prevent the
attack, the shortcut must be eliminated.  And this means that binding
establishment should be based on the first packet independent of whether
this is a data packet or a control packet.

The residual question therefore is whether or not data packets should be
used for binding establishment in addition to control packets.  There
are pros and cons for either approach:

- The advantage of using data packets is that statically configured
   addresses become straightforward to support.  Hosts with statically
   configured addresses cannot be expected to engage in any exchange of
   control packets, so a simple method to establish a binding in this
   case is based on the first data packet.

- The advantage of /not/ using data packets is that it becomes less
   likely for hosts and SAVI devices to lose sync regarding a host's
   right to use an address.  A host and its connected SAVI device then
   always determine such right based on the same control packets, so in
   the absence of control packet loss on the link segment between the
   host and the SAVI device, it is impossible for the host and the SAVI
   device to have different understanding regarding the host's right to
   use an address.

However, neither of these is a strong argument for or against the use of
data packets for binding establishment.  Statically configured addresses
could also be supported if bindings were established based on only
control packets:  A SAVI device could, e.g., initiate a Duplicate
Address Detection procedure on behalf of a host when the host sends the
first data packet from a statically configured address.  Loss of
synchronization between hosts and SAVI devices could, e.g., also be
resolved with the Neighbor Unreachability Detection procedure, such as
proposed in draft-bagnulo-savi-fcfs.

I think that, in order to move forward and decide whether or not to use
data packets for binding establishment, we should also consider the
affects on SAVI solution components other than the initial binding
establishment.  One such component is inter-switch mobility:  Would the
re-establishment of the binding in the new switch become easier based on
data packets or control packets?  How about the removal of the binding
in the old switch?  Another component is SeND support (in the SeND-based
SAVI variant):  If binding establishment is exclusively based on control
packets, the use of SeND automatically protects binding establishment.
This is not the case if data packets are used to establish bindings
because SeND does not protect the source address in data packets.  SeND
can then only protect the Neighbor Unreachability Detection procedure,
which is used for garbage collection in draft-bagnulo-savi-fcfs.

What does the working group think about this?  Please comment.

One final, important note:  Of course, the FCFS principle, the core idea
of draft-bagnulo-savi-fcfs, is orthogonal to whether or not data packets
are used for binding establishment.  And based on the feedback we got at
the SAVI meeting in Minneapolis and so far on this mailing list, the
FCFS principle is by many considered the way to go.

- Christian

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Thu, 08 Jan 2009 04:28:44 +0100

Hi Christian,

thanks for the summary

some comments below...

> this is a data packet or a control packet.

Right, i concur with this, the savi state must be created with the firs 
packet, either data or control packet (dhcp, ND)

>   case is based on the first data packet.

Actually, i think there are more reasons for using data packets

The main reason is that DAD is not reliable. The ND packet can be lost 
and not make it to the SAVI device (e.g. error in the packet for 
instance)

Let's consider the following situation:
Suppose that the SAVI device receives a data packet for which source 
address it doens't have a binding, what does the savi device does_? 
does it discards the packet? It seems an overkill to me, since we are 
not sure what happned. In the data based approach, we create the state. 
Using only control packet introduces this error mode.

>   device to have different understanding regarding the host's right to

I don't understand this.
Suppose that a host configures the address performs DAD and then goes 
quit for a really long time. At some point the SAVI device will discard 
the state for that address. The node then sends a data packet, what 
happnes? In this case, they are out of sync and the straight forward 
way to deal with this is to react upon the reception of data packets.

> data packets for binding establishment.

IMHO there is strong case for using data packets, as described above

> Statically configured addresses

Right, actually this is what i was thinking as inter switch protocol to 
spread the state crated using data packets

> data packets or control packets?

Does the node needs to perform DAD  when the host moves from one swithc 
to another?

How about the removal of the binding
> because SeND does not protect the source address in data packets.

The SEND based savi already performs a ND query to verify address 
ownership. i.e. upon the reception of a data packet it forces the 
sender to generate a control packet, which is ok for send imho

Regards, marcelo

  SeND

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

---

From: Christian Vogt <[email-masked]>
Date: Thu, 8 Jan 2009 11:10:06 -0800

> some comments below...

Marcelo -

I agree with you that we cannot always expect a host to initiate control
signaling before it sends data packets via a SAVI device that does not
have a corresponding binding.  Static addresses or loss of Neighbor
Discovery messages, as you say, may create situations in which a SAVI
device will receive packets with a source address that is legitimate,
but for which the SAVI device does not have a binding.

However, I don't think that having a SAVI device create a binding based
on data packets in that case is the only way to handle said situations.
A second option would be to have the SAVI device solicit the necessary
control messages from the host, such as with a Neighbor Solicitation
message.  (Please note that I am not an advocate of either approach.  I
am just analyzing the solution space so as to make sure we pick the
right solution.  It may well be that we eventually choose to enable
binding establishment via data packets.)

The advantage of enabling data packets to create bindings is that it
does not introduce extra signaling overhead.  The extra signaling we
would need if we restricted binding establishment to control packets
does not have value unless (i) we use SeND, where the extra signaling
would provide extra security in form of a cryptographic address
ownership proof, or unless (ii) the signaling has the extra function of
synchronizing multiple SAVI devices on a link.

The advantage of restricting binding establishment to control packets is
that it provides extra security where SeND is used, and that the extra
signaling may be re-used to synchronize multiple SAVI devices on a link.

We are certainly free to pick different solutions for the SeND-based and
non-SeND variants of SAVI.  But if we decide to use the same control
signaling for both, binding establishment and inter-SAVI-device
synchronization, then we may perhaps conclude to always restrict binding
establishment to control packets.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 8 Jan 2009 11:10:06 -0800

Marcelo -

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 04 Feb 2009 12:17:17 +0100

Hi Guang,

yaog escribió:
> 1 Both data traffic and control traffic are used, and design a new protocol
> to synch all the devices.
>
> 2 Only control traffic is used, and use option 3 to handle the exception of
> DAD packet loss.
>
>   
the problem is not only DAD packet loss, but also aging of SAVI
bindings. I mean, SAVI is using soft state, so it will need some form of
garbage collection, right?

So, suppose the following situation.

A node configures its address, preforms DAD and the SAVI binding is created.
After a while the node goes silent for a long period.
The SAVI entry expires.
The node sends a packet
the SAVI device has deleted the entry (cause it has expired) so it will
drop the packet.

In other words, the SAVI device must do something upon the reception of
a data packet with an unknown source address and i don't think dropping
the packet is an option
> I think these two ways are competitive. The first way has been completed by
> Mr. Marcelo.
not really

>  But 
> the second one has not been specified. Should we write a new draft to
> specify the second way?
>
>   
IMHO, the problem about savi binding distribution protocol is how to
authenticate the SAVI devices. If we can't authenticate the SAVI
devices, we are in trouble, cause any attacker can inject false
bindings, drop existent bindings and so on.

the problem with auhtentication is that it is likely to require some
configuration, which is not really that nice

Regards, marcelo

> Best regards,
> Guang
> -----邮件原件-----
> 发件人: Christian Vogt [mailto:[email-masked]] 
> 发送时间: 2009年1月22日 9:51
> 收件人: MARCELO BAGNULO BRAUN
> 抄送: SAVI Mailing List; Guang Yao
> 主题: RE: Binding establishment based on data or control packets?
>
> Marcelo -
>
> In your email below, you identified several situation in which a SAVI
> device may erroneously discard packets if binding establishment was
> based on control packets only.  This is correct if you assume that the
> SAVI device does not react to data packets.  OTOH, the SAVI device may
> initiate the necessary control packet exchange upon receiving a data
> packet.  This is what I was assuming to be the case, and what you were
> assuming not to be the case, I guess.  Hence the misunderstanding.  I
> think we are on the same page.
>
> Having said this, I like the summary of possible solution approaches
> that you have suggested earlier:  When a SAVI device receives a data
> packet for which source address it does not have a binding, does it...
>
> (1) discard the packet 
> (2) create a binding for the packet's source address directly
> (3) initiate a control packet exchange (such as NUD) to verify the
> packet's source address before creating a binding
>
> I agree with you that option (3) does not have a directly apparent
> advantage.  The only /potential/ advantage that I can think of is that
> the control packet exchanges initiated in option (3) might be re-usable
> as a protocol for inter-SAVI-device coordination.  However, this
> requires more analysis.
>
> - Christian
>
> PS:  Sorry for the delay in responding.  I relocated to the U.S.
> recently, and this has been consuming part of my time.
>
>
>
>   
>> -----Original Message-----
>> From: MARCELO BAGNULO BRAUN [mailto:[email-masked]] 
>> Sent: Wednesday, January 07, 2009 7:29 PM
>> To: Christian Vogt
>> Cc: SAVI Mailing List; Guang Yao
>> Subject: Re: Binding establishment based on data or control packets?
>>
>> Hi Christian,
>>
>> thanks for the summary
>>
>> some comments below...
>>
>>> attack, the shortcut must be eliminated.  And this means 
>>>       
>> that binding 
>>     
>>> establishment should be based on the first packet independent of 
>>> whether this is a data packet or a control packet.
>>>       
>> Right, i concur with this, the savi state must be created 
>> with the firs packet, either data or control packet (dhcp, ND)
>>
>>     
>>> The residual question therefore is whether or not data 
>>>       
>> packets should 
>>     
>>> be used for binding establishment in addition to control packets.  
>>> There are pros and cons for either approach:
>>>
>>>   addresses become straightforward to support.  Hosts with 
>>>       
>> statically
>>     
>>>   configured addresses cannot be expected to engage in any 
>>>       
>> exchange of
>>     
>> The main reason is that DAD is not reliable. The ND packet 
>> can be lost and not make it to the SAVI device (e.g. error in 
>> the packet for
>> instance)
>>
>> Suppose that the SAVI device receives a data packet for which 
>> source address it doens't have a binding, what does the savi 
>> device does_? 
>> does it discards the packet? It seems an overkill to me, 
>> since we are not sure what happned. In the data based 
>> approach, we create the state. 
>>>   right to use an address.  A host and its connected SAVI 
>>>       
>> device then
>>     
>>>   always determine such right based on the same control 
>>>       
>> packets, so in
>>     
>>>   host and the SAVI device, it is impossible for the host 
>>>       
>> and the SAVI
>>     
>>>   device to have different understanding regarding the 
>>>       
>> host's right to
>>     
>>>   use an address.
>>>
>>>       
>> I don't understand this.
>> Suppose that a host configures the address performs DAD and 
>> then goes quit for a really long time. At some point the SAVI 
>> device will discard the state for that address. The node then 
>> sends a data packet, what happnes? In this case, they are out 
>> of sync and the straight forward way to deal with this is to 
>> react upon the reception of data packets.
>>
>>     
>>> However, neither of these is a strong argument for or 
>>>       
>> against the use 
>>     
>>> of data packets for binding establishment.
>>>       
>>> Address Detection procedure on behalf of a host when the host sends 
>>> the first data packet from a statically configured address. 
>>>       
>>  Loss of 
>>     
>>> resolved with the Neighbor Unreachability Detection 
>>>       
>> procedure, such as 
>>     
>> Right, actually this is what i was thinking as inter switch 
>> protocol to spread the state crated using data packets
>>
>>     
>>> I think that, in order to move forward and decide whether or not to 
>>> use data packets for binding establishment, we should also consider 
>>> the affects on SAVI solution components other than the 
>>>       
>> initial binding 
>>     
>>> establishment.  One such component is inter-switch mobility:  Would 
>>> the re-establishment of the binding in the new switch become easier 
>>> based on data packets or control packets?
>>>       
>> Does the node needs to perform DAD  when the host moves from 
>> one swithc to another?
>>
>>> in the old switch?  Another component is SeND support (in the 
>>> SeND-based SAVI variant):  If binding establishment is exclusively 
>>> based on control packets, the use of SeND automatically 
>>>       
>> protects binding establishment.
>>     
>> The SEND based savi already performs a ND query to verify 
>> address ownership. i.e. upon the reception of a data packet 
>> it forces the sender to generate a control packet, which is 
>> ok for send imho
>>
>> Regards, marcelo
>>
>>
>>   SeND
>>     
>>> can then only protect the Neighbor Unreachability Detection 
>>>       
>> procedure, 
>>     
>>> One final, important note:  Of course, the FCFS principle, the core 
>>> idea of draft-bagnulo-savi-fcfs, is orthogonal to whether 
>>>       
>> or not data 
>>     
>>> packets are used for binding establishment.  And based on 
>>>       
>> the feedback 
>>     
>>> we got at the SAVI meeting in Minneapolis and so far on 
>>>       
>> this mailing 
>>     
>>> list, the FCFS principle is by many considered the way to go.
>>>
>>> - Christian
>>>
>>>
>>>
>>>       
>>
>> --
>> ----
>> MARCELO BAGNULO BRAUN
>> WebCartero

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 04 Feb 2009 12:50:56 +0100

yaog escribió:
> -----邮件原件-----
> 发件人: marcelo bagnulo braun [mailto:[email-masked]] 
> 发送时间: 2009年1月22日 18:34
> 收件人: Christian Vogt
> 主题: Re: Binding establishment based on data or control packets?
>
> Christian Vogt escribió:
>   
>> Marcelo -
>>
> right
> I have been thinking about this
> Triggering an NSOL upon the reception of a data packet for which there 
> is no binding in the SAVI device could have two potential advantages:
> - first, that can be used to synchronize multiple SAVI devices. this is 
> indeed a benefit
> - second that could allow a victim to know if an attacker is trying to 
> set up a savi state for the victim's address. Now this seems like an 
> advanatage, but after some thought, i don't think it is.
>
> Let's suppose that the savi device sends a RSOL packet upon the 
> reception of a data packet with an unknown source address.
> Suppose the SAVI device receives two replies. What can the SAVI device 
> do with this?
>
> ~Comment Start~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~Guang:
> And another comment:
> If you mean two node can get the same address both legally, this just 
> means the nodes and SAVI devices are not well synched.
> ~ Comment End~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   

I don't understand what you mean here

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 04 Feb 2009 13:00:21 +0100

yaog escribió:
> Actually, I have a method to distinguish spoofing and a node with two 
> interfaces to the same LAN, which both can cause two replies.
> The NA packet has such format:
> [source address][dest address][target address]
> If two replies are got, then we should get two source address S1, S2.
> Generally S1,S2 are link local addresses. This point depends on the source
> address the SAVI device chooses to send NS.
> Then we can ask the attempt node if it knows S2(suppose it sends packet with
> S1).
> If it knows, they are the same nodes.
> If it doesn’t know, it is spoofing or incorrect configuration.
> More details can be discussed. I have some ideas to make this procedure more
> secure.
>   
but this requires changes in the host, right?

i think host changes are ut of scope

> Actually what happens when we design SAVI such that it sends RSOL 
> packets, is that the RSOL packet acts as a synchronization point, that 
> can be used by attacker to claim the address ownership and confuse the 
> SAVI device. In other words, the whole point of a FCFS appraoch, is that 
> requests arrive in the natural. If we introduce the RSOL 
> synchronization, the order is broken and we can hardly tell who is the 
> first one to request.
>
> I don't think the SAVI device should allow spoofing NA.
> Maybe you are considering the partial deployment, and there can be spoofing
> from local nodes. This is a problem. If we specify that the mechanism should
> work when partially deployed, many things should be re-considered.
>   

what do you mean by partially deployed?

> I don't quite catch this sentence:
> " In other words, the whole point of a FCFS appraoch, is that 
> requests arrive in the natural. If we introduce the RSOL 
> synchronization, the order is broken and we can hardly tell who is the 
> first one to request."
>   

The whole point in FCFS is that the first one that claims an address has it.
Now, an attacker could claim all the addresses and if it does so, we
have a problem (that is why i am more and more convinced that FCFS SAVI
is not good enough for IPv4).
In IPv6, the attacker cannot claim all the addresses cause there are
simply too many addresses.
So, an attacker needs to choose which addresses have "value".
One of the things that gives value to an address is that this particular
address is configured in a host.
The problem that the attacker has is that in order to launch the attack
it needs to know which address to attack.
One way of knowing that is looking into DAD. That is the attack you
described a while ago. The attacker learns what address has a value by
looking into DAD and then creates a SAVI binding for that address.
Now, we have closed that vulnerability by using the DAD to create the
SAVI binding.

Now, if we allow the SAVI device to send a NSOL for an address, this
acts as a call for arms for the attacker. It bassically tells the
attacker "this si the right moment to try to get over this address", and
the savi device has no way to defend itself, cause it cannot know if the
NADV comes from an attacker or not.

Makes sense?

> So, i don't think SAVI should send a RSOL upon the reception of a data 
> packet
>
> BTW this has implications for the inter savi protocol, since we 
> shouldn't use any broadcasted message (at least in the clear) cause it 
> would have the same effect
>
> What I want to emphasize is, DAD packet loss is of little possibility.
> Even the solution brings some false negative, it is still acceptable.
>   
not really
in a wireless network, i don't think the possibility of packets not
being delivered is so small

in addition, you have to deal with the case of gargabe collection, as i
have described in the previous email

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 04 Feb 2009 13:03:17 +0100

yaog escribió:
> 发送时间: 2009年1月23日 7:39
> 抄送: Guang Yao; SAVI Mailing List
> 主题: Re: [savi] Binding establishment based on data or control packets?
>
> Christian Vogt escribió:
>   
>> On Jan 22, 2009, marcelo bagnulo braun wrote:
>>
>>     
>> The potential issue that an attacker can trick a SAVI device into
>> creating a false binding already exists in FCFS without binding
>> distribution protocol.  In that case, false bindings are limited to the
>> SAVI device to which the attacker attaches directly.  Why do you think
>> the issue becomes so much worse if a binding distribution protocol
>> enabled the attacker to create a false binding also in other SAVI
>> devices?
>>     
>
> cause the difference here is that attacker knows what IP address is a 
> valuable target (i.e. the address included in the NSOL msg)
>
> The NSOL msg acts like a call for arms for the attacker to attack that 
> address.
>
> I mean, let's focus in the IPv6 case. In IPv6, the attacker cannot 
> attack all the addresses cause 2^64 are way too many addresses. So, it 
> needs some hint about which address is a good target. Issuing the RSOL 
> acts as such.
>
> Note that there is a difference between the attacker replying to the 
> NSOL issued by the end host during the DAD and the attacker replying to 
> the NSOL issued by a SAVI device. In the case of DAD, if the attacker 
> replies, the host will not sue that address. However, when the SAVI 
> issues the NSOL message, the host is already using the address, so 
> blocking the address would imply that the host cannot use the address it 
> has configured.
>
> 1 We are actually blocking wrong configuration. It is reasonable.
>   
I am not sure i understand
blocking a packet sent by the rightfull owner of the address (which is
what i described above) is _not_ ok

> 2 Let pass the packets will cause more trouble.
>   

letting pass the packets sent by the rightfull owner is the right thing
to do

> 3 I think it is still synch problem first.
>   

not sure what you mean

regards, marcelo

> Finally, suppose that the SAVI device actually sends the NSOL, then what 
> does the SAVI device does it receives two NADV  replying?
> I mean, there is no way to tell who is the rightful owner, so what 
> should the SAVI device do in that case?
>
> Regards, marcelo
>
>   
>> (I am saying "potential" issue above because the issue can be avoided if
>> the SAVI device knows that the address is already being used elsewhere.)
>>
>> - Christian
>>
>>
>>
>>     
>
>
>
>

---

From: Christian Vogt <[email-masked]>
Date: Fri, 13 Feb 2009 19:13:54 -0800

Marcelo -

A late comment on our previous discussion on whether SAVI devices should
initiate an NS/NA exchange upon reception of a data packet with a new
source address.  In this discussion, you had identified the following
attack vulnerability that would appear if SAVI devices did initiate an

> reception of a data packet with an unknown source address. Suppose the
> SAVI device receives two replies. What can the SAVI device do with  
> this?
>

(* Replace "RSOL" with "NSOL" in the quotation; this was a typo.)

What if SAVI devices blocked NA packets that do not correspond to any of
their cached bindings?  (I believe this is what Guang was alluding to in
one of his earlier messages.)

Then, if a SAVI device receives a data packet with a new source address,
and if this SAVI device sends a "proxy" NS on behalf of the host sending
the packet, an attacker won't be able to interfere by sending an NA for
said source address.

Blocking illegitimate NA packets would therefore prevent the attack that
you have identified, which would exist if SAVI devices let the
attacker's NA packet pass.  So it would be a way to retain the natural
FCFS order of address requests -- where an "address request" comes in
form of a data packet with a new source address.  Also, blocking
illegitimate NA packets should make it impossible that a SAVI device
receives two NA packets for its proxy NS.

In other words, SAVI devices should use the following rules:

- Let NS packets pass.  If no corresponding binding exists, create such
   binding if no responding NA packet received during next X seconds.

- Let NA packets pass if and only if a binding exists for the NA's
   target address.  Otherwise, drop the NA packet.

- Let data packets pass if a corresponding binding exists.

- Send a proxy DAD NS packet if a data packet does not correspond to an
   existing binding.  Create a corresponding binding if no responding
   NA packet is received during next X seconds.  (We would need to
   discuss whether the SAVI device should drop, or let pass, any data
   packets received throughout the X seconds during which it waits for
   NA packets.)

Does this make sense?

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 16 Feb 2009 09:27:03 +0100

Hi Chrstian,

Christian Vogt escribió:
>> SAVI device receives two replies. What can the SAVI device do with this?
>>

What about legitimate NA for source addresses _not_ corresponding to an 
existing SAVI binding?
I mean, SAVI bindings are soft state, hence it can and will be discarded 
at some point. So, it seem perfectly possible to me that a node sends a 
legitimate NA and that the binding if once existed, has been discarded.
Dropping legitimate NA packets seems to be problematic, i think

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 16 Feb 2009 10:30:12 +0100

yaoguang escribió:
> at some point. 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> I don't quite understand your meaning of " SAVI bindings are soft state ".
>   

What i mean by this is that the state is created by the SAVI device as
the response of a data or ND packet sent by the host (but that the goal
of that packet is not to explicitly create state) and that the
responsability of discarding that state is completelly up to the SAVI
device i.e. the host will not send a FIN packet to delete the state.

In other words, the SAVI device will receive a packet from the host, and
will create the SAVI binding
The SAVI binding will have a given lifetime.
It is likely that the lifetime is extended if the host keeps on sending
packets, but if a long period passes and no packets are seen by the SAVI
device referring to that address, the SAVI device will unilaterally
(i.e. without asking the host) will discard the state. This is
essentially needed for memory reasons

I guess a reasonable lifetime for a binding would be similar to the dhcp
lease lifetime... so, between a day and a week, would seem reasonable to me

(probably, if the SAVI device is under a DoS attack, it will need to
discard the bindings earlier)

So, it is perfectly possible that a host is the rightful owner of an
address and that the SAVI device has discarded the binding

regards, marcelo

> When and why will SAVI bindings be discarded, and how often?
>
> I think they are somewhat soft, but they are not as soft as bubbles.
>
>
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 16 Feb 2009 11:15:28 +0100

mmm, i think you forgot to copy the ml so i added it

yaoguang escribió:
> Thank your for your kind reply.
>
> I agree with your idea that there must be a lifetime for a binding entry.
> As I know, other than manually configured address, SAC address and DHCP
> address have their lifetime prescribed in the RFC doc. 
>
> But why the SAVI device has to delete the bindings unilaterally when the
> lifetime expires?
> It can simply ask whether the owner is still using the address by a NS
> message.
>   
what about the case the node is asleep or standby mode but still has the
address configured?
what about the case the node is momentarily disconnected from the
network? (this can easily happen quite often in a wireless network (at
least it happens often to me)

IMHO, it is not the best approach to try to build mechanisms to make
sure that the binding information is reliably distributed, stored and
deleted, but it makes more sense to have in place the mechanisms to be
able to recover the information if it is missing.

> In the case of DoS attack, because we have an assumption that the anchor is
> unspoofable,
>   

i am not sure when we made that assumption
In other words, i disagree this is a valid assumption
for me, the point is that the SAVI solution will be as secure as the
lower layer anchor, but i am not assuming it is not spoofable

> the SAVI device can just delete the entries related to the flooding packets.
>
>   
But, an attacker can send multiple packets with different source
addresses, so you cannot distinguish the legitimate packets from the attack

I mean, consider the example as follows. The case is SAVI implemented in
ehternet switches.
First of all, i understnad that we are planning to support partial
deployment scenarios i.e. a scenario where some switches support SAVI
and other not.
This means that we need to be able to bind multiple source addresses to
a given switch port (cause there may be a non savi switch in that port)
So, how would you in that cae distinguish an attacker sending packets
with different source addresses from legitimate users?

Regards, marcelo

> 发送时间: 2009年2月16日 17:30
> 收件人: yaoguang
> 抄送: 'Christian Vogt'; 'SAVI Mailing List'
> 主题: Re: 答复: Binding establishment based on data or control packets?
>
> yaoguang escribió:
>

---

From: Christian Vogt <[email-masked]>
Date: Mon, 16 Feb 2009 20:12:58 -0800

Marcelo -

> existing SAVI binding? I mean, SAVI bindings are soft state, hence it
> can and will be discarded at some point. So, it seem perfectly  
> possible
> to me that a node sends a legitimate NA and that the binding if once
> existed, has been discarded. Dropping legitimate NA packets seems to  
> be
> problematic, i think

Yes, you are right; this is a problem.  In fact, there are more variants
of the case where the legitimate address owner's SAVI device does not
have a binding for the address in question:  It can also happen if the
address in question was manually configured into the legitimate address
owner, and the legitimate address owner has never used the address and
hence never created a binding in its SAVI device.  (This is a situation
that Guang had described earlier.)  Obviously, these cases need to be
handled.

Suggestions?  Do we need to adopt manual configuration of SAVI bindings
for manually configured addresses?

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 17 Feb 2009 10:00:54 +0100

Christian Vogt escribió:
>> can and will be discarded at some point. So, it seem perfectly possible
>> existed, has been discarded. Dropping legitimate NA packets seems to be
>> problematic, i think
>
Ok, we have two issues here:
how to handle manually configured issues
how to make the binding distribution protocol work

Now, for the issue about manually configured addresses, for IPv6, there 
is no problem
I re read rfc2462 and it states:

5.4.  Duplicate Address Detection

   Duplicate Address Detection is performed on unicast addresses prior
   to assigning them to an interface whose DupAddrDetectTransmits
   variable is greater than zero. Duplicate Address Detection MUST take
   place on all unicast addresses, regardless of whether they are
   obtained through stateful, stateless or manual configuration, with
   the exception of the following cases:

    - Duplicate Address Detection MUST NOT be performed on anycast
        addresses.

      - Each individual unicast address SHOULD be tested for uniqueness.
        However, when stateless address autoconfiguration is used,
        address uniqueness is determined solely by the interface
        identifier, assuming that subnet prefixes are assigned correctly
        (i.e., if all of an interface's addresses are generated from the
        same identifier, either all addresses or none of them will be
        duplicates). Thus, for a set of addresses formed from the same
        interface identifier, it is sufficient to check that the link-
        local address generated from the identifier is unique on the
        link. In such cases, the link-local address MUST be tested for
        uniqueness, and if no duplicate address is detected, an
        implementation MAY choose to skip Duplicate Address Detection
        for additional addresses derived from the same interface
        identifier.

So, manual configured addresses are not an issue, cause the perform the 
DAD procedure, so the savi device learn about them through it.

Interestingly, we may need to do something with the global addresses if 
the DAD have been performed for the link local. But i guess the SAVI 
device could create binding for the associated global addresses upon the 
DAD for the link local address (note that if the address is used from a 
different lower layer anchor, the savi device will check the exisitng 
binding, which i  guess is what we want)

So, i think there is no problem here

The problem is how to build the binding distribution protocol wihtout 
introducing new vulnerabilities.
And at this point, i don't see any obvious answer beyond having some 
configuration in the savi devices (e.g. a shared key) which is certainly 
not the most attractive approach

Regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Mon, 23 Feb 2009 16:04:01 -0800

Guang Yao wrote:

> If the SAVI device asks the node before deleting bindings, it is  
> safe in
> most cases and only fails in some specified examples. If the SAVI  
> device
> doesn't ask the node and delete bindings unilaterally, it may fail  
> with
> great possibility. So I don't think this is a good example to prove
> querying the node is useless.

I think the conclusion regarding the use of probing prior to removing
soft-state bindings should be that (1) SAVI devices do probe to minimize
premature binding removal, but that (2) we cannot rely on a binding to
exist if a host is using the bound address.  In other words, the probing
can only be an optimization.

Does this make sense?

- Christian