Subject: [savi] Working Group Adoption of Individual SAVI Documents

From: Christian Vogt <[email-masked]>
Date: Thu, 18 Dec 2008 13:14:46 +0800

Dear all -

At the previous SAVI meeting in Minneapolis, we did a vote regarding
which individual documents to use as starting points for the SAVI
working group deliverables.  I would now like to confirm this decision
from Minneapolis here on the mailing list.

The result of the vote in Minneapolis was thus:

- To adopt draft-mcpherson-savi-threat-scope as a starting point for the
   Threats Analysis (Problem Statement) document:  7 in favour, 0
   against.

- To adopt draft-vogt-savi-rationale as a starting point for the
   Rationale document:  7 in favour, 0 against.

- To adopt draft-bagnulo-savi-fcfs as a starting point for both the IPv4
   and IPv6 Solution documents:  11 in favour, 2 against.

- To adopt draft-bagnulo-savi-send as a starting point for the
   SeND-based IPv6 Solution document:  8 in favour, 1 against.

Arguments raised by those voting against the adoption of one of the
individual documents above related to potential security vulnerabilities
or potential issues with mobile hosts.  Both arguments would need to be
addressed as the working group deliverables are being advanced.

Please express on this mailing list whether or not you agree with the
above documents being adopted by the SAVI working group as starting
points for the various working group deliverables.  Please also state
the reasons in case you are against one of the documents being adopted.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 18 Dec 2008 13:23:38 +0800

> the reasons in case you are against one of the documents being  

Please do so before Sunday, January 4, 2009.

- Christian

---

From: Frank Xia <[email-masked]>
Date: Thu, 18 Dec 2008 09:54:30 -0600

Hi Christian

I was not in the against list of FCFS, however,
I did express my concerns of the solution.

The main idea is trying to build a
source address validation rule using the first 
data packet.  IMHO, this solution is vulnerable.

It seems to be hard to deal with the following 
scenarios:
1)A host is authorized to use a static address, while
   the host does not connect the network
2)A IPv6 host periodically changes it's  interface ID
   from privacy consideration.
3)In dynamic address configuration,  an IP address
   can be reused by other hosts.

BR
Frank

----- Original Message ----- 
From: "Christian Vogt" <[email-masked]>
To: "SAVI Mailing List" <[email-masked]>
Sent: Wednesday, December 17, 2008 11:14 PM
Subject: [savi] Working Group Adoption of Individual SAVI Documents

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 18 Dec 2008 20:11:12 +0100

Hi Frank,

some comments below...

Frank Xia escribió:
> source address validation rule using the first data packet.  IMHO, 
> this solution is vulnerable.
>
> It seems to be hard to deal with the following scenarios:
right, we need to think how to deal with this case
one obvious option is that since the address is manually configured in 
the host, it can also be manually included in the SAVI cache, so it 
knows that has been manually assigned
I understand that some people actually manually configure MAC- IP 
address associations to perform this type of checks

>   from privacy consideration.
not sure why this is a problem, could you expand?

>   can be reused by other hosts.
this is no problem, the current draft actually deals with this

Regards, marcelo

> BR
> Frank
>
>
> ----- Original Message ----- From: "Christian Vogt" 
> <[email-masked]>

---

From: Christian Vogt <[email-masked]>
Date: Sat, 20 Dec 2008 13:28:28 +0200

Marcelo and Frank -

>> It seems to be hard to deal with the following scenarios: 1)A host is
>> authorized to use a static address, while  the host does not  
>> connect the
>> network
>
> right, we need to think how to deal with this case one obvious  
> option is
> that since the address is manually configured in the host, it can also
> be manually included in the SAVI cache, so it knows that has been
> manually assigned

Right.  An alternative, more automated solution might be to have the
switch perform proxy DAD when a new address is used on a given port.
This would enable the switch to determine whether the new address is
pre-configured and hence already in use, because the pre-configured host
would respond to the switch's Neighbor Solicitation during the proxy DAD
procedure.

FCFS already uses proxy DAD -- in the Neighbor Unreachability Detection
variant -- to prevent attackers from hijacking an address by faking
link-layer movements.

An obvious optimization to avoid unnecessary proxy DAD is for the switch
to listen for non-proxy DAD, and to skip proxy DAD if non-proxy DAD was
performed for the same address/port combination.

- Christian

---

From: Lin Tao <[email-masked]>
Date: Mon, 22 Dec 2008 17:49:57 +0800

Hello, Christian, Marcelo and Frank:

I agree with Frank's view. Because the forwarding packet is 
observed in FCFS draft, so the forwarding process is disrupted, 
and the device is vulnerable, e.g. savi cache table exhausted,
the cpu of switch busy, etc.

In my opinion, observing the Control Protocol, e.g. DHCP 
or ND etc, is easy to implement in switch for these protocol
have special characteristic that can be filtered in switch port while
the forwarding packet is blocked.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 22 Dec 2008 11:26:54 +0100

Hi Lin,

> observed in FCFS draft, so the forwarding process is disrupted,

what do you mean by the process is disrupted?
could you describe in detail what is the problem you are pointing out?
>  
> and the device is vulnerable,

the device is vulnerable to what type of attacks?
again could you rpovide some detailed description of the issue that you 
are raising?
>  e.g. savi cache table exhausted,
>   
DoS to the SAVI arch is an issue that we need to assess more indetail i 
agree
see the previous disucssions in the ml about DoS attacks and SAVI

> the forwarding packet is blocked.
i don't understand what you mean here about the special characteristic
dhcp has little or no security so, i am nbot sure how you are planning 
to prevent the attacks you mentioned before.
with plain ND, is even worse imho, unless you use send, but send still 
retains some of the DoS attack vectors as been previously disucssed in 
the ml
So, how do you think these protocols solve the issues you raised above?

Regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Tue, 23 Dec 2008 12:35:51 +0200

Lin -

I agree with you that DoS is an unsolved issue that we have yet to
tackle. However, I don't think we can solve the issue, for all address
configuration methods, simply by changing which packets we snoop.  SLAAC
in particular is an address configuration method where an attacker can
overload a SAVI device just as easily with control packets (i.e.,
Neighbor Solicitation packets) as with datagram packets.

The only scenario in which snooping control packets instead of datagram
packets could mitigate the DoS issue is where addresses are exclusively
assigned via DHCP.  A SAVI device can then exclusively rely on messages
being sent by a server (not directly by the attacker), such that a DoS
attack against a SAVI device reduces to the existing threat of a DoS
attack against a DHCP server.

FWIW:  Some SAVI participants were considering a DHCP-only option for
SAVI during IETF 73.

- Christian

---

From: "David Harrington" <[email-masked]>
Date: Tue, 23 Dec 2008 16:52:12 -0500

Hi,

It appears some of these drafts have expired.
Can the drafts be re-published so people can look at them before
making a decision?
I suggest you extend the review period accordingly.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christian Vogt
> Sent: Thursday, December 18, 2008 12:15 AM
> To: SAVI Mailing List

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Wed, 24 Dec 2008 02:01:22 +0100

Correction, only one of these draft is expired, 
draft-mcpherson-savi-threat-scope, (BTW you can easily find in 
tools.ietf.org besides many other sites, such as waterspings and so on)

Regards, marcelo

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

---

From: Lin Tao <[email-masked]>
Date: Wed, 24 Dec 2008 18:03:01 +0800

Dear Christian, Guang and Marcelo,

    I agree with Guang that the normal behaviors and good guys
MUST be protected, so we should snoop at control packets than 
datagram packets. This is the worthest thing in SAVI. 
    There is two plane in SWITCH: ASIC and CPU, it 
is easy to implement ACL in ASIC to filter control packets to
CPU, and the datagram packets is discarded by default. Otherwise,
all datagram packets that havn't right to forward are all 
delivered to CPU, than it will be forwarded by CPU, this is 
a bader granularity than snooping control packets.
   
Best regards

----- Original Message ----- 
From: "Guang Yao" <[email-masked]>
To: "'Christian Vogt'" <[email-masked]>; "'Lin Tao'" <[email-masked]>
Cc: "'Frank Xia'" <[email-masked]>; "'Marcelo Bagnulo Braun'" <[email-masked]>; "'SAVI Mailing List'" <[email-masked]>
Sent: Tuesday, December 23, 2008 8:12 PM
Subject: 答复: [savi] Working Group Adoption of Individual SAVI Documents

Dear Christian and Lin,

It's clear that snooping ND cannot achieve better performance and security 
than snooping data traffic. Actually snooping ND may cost more for it must
trace 
the state of DAD.

But IMO, it is not an issue of resource saving, but an issue that what SAVI
is intending
to protect. If the SAVI device snoops ND to bind address and anchor, it
protects
good guys who are working according to the standard. But if it snoops data
traffic and
binds address and anchor using the principle of FCFS, bad behaviors, such as
attacks against
DAD, are protected. 

Mr. Fred Baker once gave us a convincing example: when an attacker receives
a
DAD NS, it immediately sends a packet with source address set to the Target
Address in the NS
to make the SAVI device set up binding without replying a NA. Then the DAD
node, although has finished
a successful DAD, cannot use the tentative address for the SAVI device will
take its traffic as spoofing traffic.

Although it is rather a security problem of ND then the fault of SAVI, the
SAVI device is
protecting bad doings in the example.

I think SAVI should at least protect normal behaviors and good guys, but not
protect bad behaviors.

I also think SAVI should protect the Target Address in NA message, for it is
another kind of source address. 

Guang
-----邮件原件-----
发件人: Christian Vogt [mailto:[email-masked]] 
发送时间: 2008年12月23日 18:36
收件人: Lin Tao
抄送: Frank Xia; Marcelo Bagnulo Braun; SAVI Mailing List; 姚 广
主题: Re: [savi] Working Group Adoption of Individual SAVI Documents

Lin -

- Christian

---

From: "David Harrington" <[email-masked]>
Date: Wed, 24 Dec 2008 14:11:05 -0500

I also did not find draft-vogt-savi-rationale in the ID repository.

dbh 

> Behalf Of MARCELO BAGNULO BRAUN
> Sent: Tuesday, December 23, 2008 8:01 PM
> To: [email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 24 Dec 2008 23:26:54 +0100

indeed, you are right and this one is not available in any mirror (or i 
couldn't find it myself)
sorry about that
I think Christian sent it to the ml
the link is 
http://users.piuha.net/chvogt/pub/2008/draft-vogt-savi-rationale-00.txt

regards, marcelo

David Harrington escribió:
>>>> Subject: [savi] Working Group Adoption of Individual SAVI
>>>>         
> Documents
>   
>>>> Dear all -
>>>>
>>>> At the previous SAVI meeting in Minneapolis, we did a vote 
>>>>         
>> regarding
>>     
>>>> working group deliverables.  I would now like to confirm this
>>>>         
>>> decision
>>>       
>>>> Arguments raised by those voting against the adoption of one of
>>>>         
> the
>   
>>>> Please express on this mailing list whether or not you agree with
>>>>         
>>> the
>>>       
>>>> above documents being adopted by the SAVI working group as
>>>>         
> starting
>   
>>>> points for the various working group deliverables.  Please also
>>>>         
>>> state
>>>

---

From: ZhangDong <[email-masked]>
Date: Sat, 27 Dec 2008 15:19:45 +0800

Hi,

Perhaps there is another potential danger that should be considered.
One node may have more than one IP addresses, but only one interface in IPv6.
We assume that node X has IPa and IPb. Its layer-2 address is MACx. According to FCFS, firstly node X uses IPa. A entry with IPa and MACx is created in SAVI device DB. The node X uses IPb. And another entry with IPb and MACx also is created. The node X may use IPb all the time. Now we should note that if an attacker sends packets with IPa and MACx, the SAVI device will do nothing but forwarding the forged packets.

This case must be faced by FCFS.

Dong Zhang

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Sat, 27 Dec 2008 12:48:58 +0100

Hi,

ZhangDong <[email-masked]> dijo:

> We assume that node X has IPa and IPb. Its layer-2 address is MACx. 
> According to FCFS, firstly node X uses IPa. A entry with IPa and MACx 
> is created in SAVI device DB. The node X uses IPb. And another entry 
> with IPb and MACx also is created. The node X may use IPb all the 
> time. Now we should note that if an attacker sends packets with IPa 
> and MACx, the SAVI device will do nothing but forwarding the forged 
> packets.

i don't see the problem here.
I mean, this is exactly the same case as if the node has a sinlgle IP 
address and the attacker sends a packet spoofing both the mac address 
and the IP address. IF we are using mac address as lower layer anchors, 
there is not much we can do about this.

So, basically, i don't understand why having multipla IP addresses make 
things any worse than with a single IP address and second, i guess any 
solution is limited by the strength of the lower level anchor we use, 
but we knew this already, i guess

regards, marcelo

> ----- ???? -----
> ???: marcelo bagnulo braun <[email-masked]>
> ??: 2008? 12? 19?, ???,  ??3:11
> ??: Re: [savi] Working Group Adoption of Individual SAVI Documents
> ???: Frank Xia <[email-masked]>
> ??: SAVI Mailing List <[email-masked]>, Christian Vogt

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 28 Dec 2008 20:12:07 +0100

> take its traffic as spoofing traffic.
but the attacker could send a NADV replying to the DAD NS and would
achieve the same effect in a NS-based SAVI approach, wouldn't it?
I mean, i fail to see how you improve security if you rely on ND than
when you rely on data packets... (FWIW, this is completelly orthogonal
to the FCFS appraoch, since FCFS may apply both to data packets or to ND
packets)

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 28 Dec 2008 20:17:47 +0100

Lin Tao escribió:
> datagram packets. 
I fail to see why this is so
could you expand?

regards, marcelo

> This is the worthest thing in SAVI.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 29 Dec 2008 18:55:02 +0100

Guang Yao escribió:
> -----邮件原件-----
> 发件人: marcelo bagnulo braun [mailto:[email-masked]] 
> 发送时间: 2008年12月29日 3:12
> 收件人: Guang Yao
> 抄送: 'Christian Vogt'; 'Lin Tao'; 'Frank Xia'; 'SAVI Mailing List'
> 主题: Re: 答复: [savi] Working Group Adoption of Individual SAVI Documents
>
> Guang Yao escribió:
>   
>> Dear Christian and Lin,
>>
>> But IMO, it is not an issue of resource saving, but an issue that what
>>     
> SAVI
>   
>> is intending
>> binds address and anchor using the principle of FCFS, bad behaviors, such
>>     
> as
>   
>> attacks against
>> DAD, are protected. 
>>
>> Mr. Fred Baker once gave us a convincing example: when an attacker
>>     
> receives
>   
>> a
>> DAD NS, it immediately sends a packet with source address set to the
>>     
> Target
>   
>> Address in the NS
>> a successful DAD, cannot use the tentative address for the SAVI device
>>     
> will
>   
> No, it wouldn't. Because the attacker has not finished a DAD to achieve the
> ownership
> of the Target Address in the NADV message, the SAVI device wouldn't bind
> this address
> with its anchor. And in this situation, the tentative node just fails to get
> an address and it 
> knows that clearly. But in FCFS case, it doesn't know the address assigned
> has been bound
> with another node, and it will try to send "spoofing" packets.
>
>   
right, i agree that the failure modes are different.

I think we are having two somehow orthogonal issues here:
- On one hand we are discussing what is the type of address ownership
proof that we want to have. I think that irrespectively whether you use
control messages or data packets, you can use the FCFS principle as
address ownership. I mean, in both cases, the first node that sends a
packet with a given address claims the address ownership. The first
packet can be a data packet or a NS or NADV packet, but it is FCFS
principle all the way. I don't thing you are propising a different
address ownership proof afaict
- On the other hand, there is the disucssion if we do this based on data
packets or using control packets, in particular NSol and NAdv). I don't
have a problem in doing it in both. I don't think you can do it only
with control packets. In particular, consider the case of optimistic
DAD. In that case, the node starts using the address even wihtout having
the DAD completed. Moreover, DAD is a one time operation that is
succesfull when there is no reply. So if we have a transite failure
duringt he DAD period, and packets are not delivered to the SAVI device
during that time, SAVI would fail. I do agree that it would be
interesting to evaluate if looking into ND messages could help to
prevent some scenarion as the one you mention above. But i think that a
solution that solely relies in ND messages would be not very robust
(i.e. it would fail if the DAD packet is lost for instance)

> And I mentioned SAVI must control the NA messages, for the Target Address in
> the NA message is another kind of source address. If the SAVI device has set
> up
> a binding table, it can filter spoofed NA with ease. 
>
> It may be argued that in any situation, a node can avoid replying to NS
> message even the
> Target Address has been assigned to it, and the tentative node will be
> assigned duplicated and "spoofing" address.
> But still it is very different because the probability for two node to
> generate same address is little and the possible damage 
> Is trivial. 
> But if an attacker designedly attacks against the tentative address, the
> consequence is very bad. Unfortunately, FCFS
> using data traffic makes this situation possible.
>
> IMO, binding address using data traffic is wrong because data traffic is not
> defined to have the
> function of assigning address to node. It is the necessary condition but not
> sufficient condition.
>
>
>   
but the problem is that there is no sufficient condition for knowing
that a node has configured an address. I mean, DAD messages can be lost
and they are only sent once in a nion reliable fashion. In addition,
nodes do optimistic DAD and start using the address without waiting for
the DAD to be completed.

So, if you want to design a robust mechanism you need to deal with all
that, and using data packets seem the ultimate line

(In order to deal with the attack you mention, the SAVI device can sniff
DAD packets and identify the suggested attacks if it first sees a DAD
packet and then a data packet with the same address and no DAD reply to
the original request... of course this makes the logic more comlex)

Regards, marcelo

>> I think SAVI should at least protect normal behaviors and good guys, but
>>     
> not
>   
>> protect bad behaviors.
>>
>> I also think SAVI should protect the Target Address in NA message, for it
>>     
> is
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 30 Dec 2008 15:28:31 +0100

[Meta comment: Guang, please indent or mark somehow your text in order
to distinguish from my previous comments, cause it is becoming
increasingly hard to follow this thread)

below...

Guang Yao escribió:
> For the SAVI device, it is correct that address ownership can be assigned
> according
> to the principle of FCFS, no matter data traffic or control traffic is
> chosen. It is not the fault 
> of the principle of FCFS. But it is correct from the view of the SAVI
> device.
>
> Please consider the hosts in the same network. For currently we cannot
> modify the
> host, they have none sense of the existing of a SAVI device. They are
> working assuming
> all the nodes are working according to the standard and
> the switch or router would never drop its traffic if it obeys the rules,
> unless congestion.
>
>   
mmm, what about ingress filtering? If a node has multiple addresses with
different prefixes, packets can get dropped cause ingress filtering
(this is fairly common case in multihomed scenarios for instance)

The point that i am trying to make is that if we intend to create a SAVI
mechanism that is transparent to the edn nodes, we will need to make
some assumptions and these assumptions are likely to not hold for every
possible scenario, and when they don't hold, some things are likely to fail.
Of course we must minimize the situations where that happens, i agree

> However, we put a superpower manager into the network without notifying the
> hosts. 
> And the manager designed two new rules: 
> 1a, if you use an address in the data traffic firstly, you get
> the ownership;
> 2a, if you use an address given to another, your packet will be dropped. 
> Unfortunately, these rules are not known by any host. The host runs
> according to these two rules: 
> 1b, If a tentative address is not replied by another, I can use it; 

> 2b, My packet will be delivered if I use my address.
>   

Well, DAD is not guaranteed to work in all the cases, so it may be
possible that there is a collision even with DAD being successful.
In that case, you enter in very strange failure modes.
So, you can use that address indeed but there is no guarantees it will
your own and your own only

> The first rules of SAVI device and host are very different.
> 1 the owner of a tentative traffic
what do you mean by the owner of tentative traffic?

>  is not enforced to reply a DAD NA. So 1a
> is not the sufficient condition of 1b.
> 2 any host can reply the DAD NS. So 1a is not the necessary condition of 1b.
> And there may be more examples to prove that 1a is not a necessary and
> sufficient condition of 1b.
> So 1a and 1b are separate conditions. 
> If we want to use 1a, we must assure that all hosts run according to 1a. Or
> else, something goes bad.
> But actually, all normal hosts run according to 1b.
>
> In short, FCFS is OK, but it will be bad if the FCFS principle is not known
> clearly by host. If we don't want to modify
> host, we must make the SAVI device transparent and import no new rule.
>
>   

I am not sure what is the problem here.

We can use the FCFS principle both with data traffic and control packets
as i suggested in the previous email
The SAVI device can create state both based on the ND traffic and the
data traffic, there is no problem with that.
I guess it is up to the WG to decide if we think that the additional
complexity required for the SAVI device to also understand ND messages
is worth it.
I am not sure we are disagreeing here...

> Optimistic DAD would not trouble for a DAD NS has been sent and the SAVI
> device
> knows exactly whether there is a collision. If there is a collision, the
> source address
> without finishing DAD will be dropped. There is no problem. And if no
> collision, there 
> is no problem to forward these packets.
>
>   
> I agree that SAVI will fail if the DAD NA message is not delivered to the
> tentative node.
> So I think maybe the SAVI device should guarantee the procedure will not be
> disrupted,
> e.g., it can play as a ND proxy.
but how do you guarantee that the ND message was delviered to the SAVI
device in the first place?
(And how do you guarantee that the ND message is delviered to all the
nodes?)

I mean, the problem with DAD robustness is that the topology can change
after the DAD procedure was done. So, suppose you have two lans that are
working and that at some point in time they are merged into one lan. In
that case, the nodes on each lan have already executed the DAD procedure
and they are not even aware of the merging, so they will not repeat the
DAD procedure. (this can happne when there is a failure and a network
gets partitioned and then repaired for example)

So DAD is inherently non robust cause the procedure is successful when
there is NO reply, but you cannot know if there is no reply cause there
is no address collision or because the packet was lost.
>  But I think relying on data traffic has the
> same problem, right?
>
>   
not really, cause there are many data packets.
So, if one data packet gets lost, there will be more to come, so sooner
or later one of them will make it (or we have bigger problems)

The problem with DAD is that we send only one packet and if it is lost
we are out of luck.
BEsides, we could send several packets, but this would imply longer
delay, whcih is also bad.
Data pakcet otoh, there are plenty of them, so the problem is handled better
>> And I mentioned SAVI must control the NA messages, for the Target Address
>>     
> in
>   
>> the NA message is another kind of source address. If the SAVI device has
>>     
> set
>   
>> up
>> IMO, binding address using data traffic is wrong because data traffic is
>>     
> not
>   
>> defined to have the
>> function of assigning address to node. It is the necessary condition but
>>     
> not
>   
>> sufficient condition.
>>
>>
>>   
>>     
> Yes, I want to design a robust mechanism. But I don’t think we have to use
> data traffic.
> I think the mechanism can be like this:
> 1 It must ensure the security and completeness of DAD.
>   
how do you think you can do that?
As i said, imho DAD is inherently non robust

> 	1.1 Address can be bound only after a DAD NS and there is no
> collision in local binding table.
>   
as i said several times, i thin it may be ok to use ND messages to
populate the SAVI DB, but i don't think we should rely solely on ND. I
think we need to use data packets as well, in case DAD packets are
missing for soem reason
BTW, i also think we should use dhcp messages if we can

I think we need to understnad what do we gain by adding this complexity
(clearly relying solely on dat packets is simpler, but relying on
signaling packets as well may prevent som attacks, but we need to
understadn that better imho)

> 	1.2 If there is a collision in local binding, and a DAD NA is
> replied from the address owner, it must
> 	   ensure the NA will be delivered to the tentative node.
>   
sure, this is basic DAD behaviour, nothing new here, right?

> 	1.3 If the address owner doesn't reply, it may either: 1, delete
> former binding and set up new binding; 
> 		or 2 Send a NA to the tentative node instead of the address
> owner.
>   
sure, this is done already in the FCFS draft,

> 	1.4 Any NA with spoofed Target Address must be dropped.
> 2 Data traffic is either dropped or forwarded according to binding, without
> triggering new binding entry.
>
>   
here, i disagree
as i said, i think we should also use data traffic as well

> I think the security and completeness of DAD is necessary even using data
> traffic to bind address. 
>   
how do you plan to achieve that?

regards, marcelo

> If this condition is not guaranteed, there will be varies of attacks and
> collisions.
>
>>> Although it is rather a security problem of ND then the fault of SAVI,
>>>       
> the
>   
>>> SAVI device is

---

From: Lin Tao <[email-masked]>
Date: Wed, 31 Dec 2008 17:55:41 +0800

Sorry so late. I think Guang have explained the meaning.
I agree his idea, the control protocol must be snooping
or proxy to protect the network security. And we can 
layout different secure level in this way. There is the
same approach in IPv4.

Happy new year!

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Wed, 31 Dec 2008 14:00:40 +0100

Lin,

> I agree his idea, the control protocol must be snooping

How do you suggest to deal with the case the NADV message is lost and 
the SAVI device does not receives it?

> or proxy to protect the network security.

as i mentioned already, this is included already in the fcfs draft

> And we can
> layout different secure level in this way.

What do you mena by this?

> There is the

how are you planning to do this? IS DAD mandatory in IPv4?

Regards, marcelo

> Cc: "Guang Yao" <[email-masked]>; "'Christian Vogt'" 
> <[email-masked]>; "'Frank Xia'" 
> <[email-masked]>; "'SAVI Mailing List'" <[email-masked]>
>>> Cc: "'Frank Xia'" <[email-masked]>; "'Marcelo Bagnulo 
>>> Braun'" <[email-masked]>; "'SAVI Mailing List'" <[email-masked]>
>>> Subject: ??: [savi] Working Group Adoption of Individual SAVI Documents
>>>
>>>
>>> Dear Christian and Lin,
>>>
>>> -----????-----
>>> ???: Christian Vogt [mailto:[email-masked]]
>>> ????: 2008?12?23? 18:36
>>> ???: Lin Tao
>>> ??: Frank Xia; Marcelo Bagnulo Braun; SAVI Mailing List; ? ?

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Wed, 31 Dec 2008 17:57:57 +0100

>> same approach in IPv4.

Follow up in this one

Address conflict detection for IPv4 is defined in RFC5227, published in 
July 2008.
I don't know how widely implemented is this, but i guess that as oposed 
to DAD which was defined from the start in ND, conflict detection for 
v4 has been defined much later on afaict and i would guess that it 
cannot be assumed to be universally implemented (or even widely 
implemented)

Of course this is just my feeling, does anyone has actual data or 
experience about this?

Regards, marcelo

---

From: Lin Tao <[email-masked]>
Date: Sun, 04 Jan 2009 21:15:29 +0800

1. About NADV message lost.
The SAVI device is the first access device, so if this message is lost, 
we can  consider the host is offline.

2.Secure level.
All the SAVI feature(ND proxy,  etc) should be optional, we can 
define the feature in differ level. The weakest level is no SAVI, than
deal with forwarding parcket, than controling parcket (there are
more level in controling parcket, ND/ARP, DHCP, etc).

3.Same approach in IPv4.
Yes, DAD mandatory in IPv4 is one. We have more approach, 
for example, ARP proxy, ARP snooping, ARP detection for same
source MAC, etc.

4. About RFC5227
This RFC may not be universally implemented. But SAVI group
dicuss the device, and the device can implement it first. Otherwise,
we can improve it for device in SAVI standard, the same as ND.

----- Original Message ----- 
From: "MARCELO BAGNULO BRAUN" <[email-masked]>
To: "Lin Tao" <[email-masked]>
Cc: "Guang Yao" <[email-masked]>; "'SAVIMailing List'" <[email-masked]>; "'Christian Vogt'" <[email-masked]>; "'Frank Xia'" <[email-masked]>
Sent: Wednesday, December 31, 2008 9:00 PM
Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents

Lin,

Regards, marcelo

---

From: "Guang Yao" <[email-masked]>
Date: Sun, 4 Jan 2009 21:38:43 +0800

[Sorry for replying late. There is something wrong with my mail server and I
have to reply using this mail address.]

-----邮件原件-----
发件人: marcelo bagnulo braun [mailto:[email-masked]] 
发送时间: 2008年12月30日 22:29
收件人: Guang Yao
抄送: 'Christian Vogt'; 'Lin Tao'; 'Frank Xia'; 'SAVI Mailing List'; 'Jun
Bi'
主题: Re: 答复: 答复: 答复: [savi] Working Group Adoption of Individual SAVI
Documents

below...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Guang, 1.4:
~As I know, ingress filtering has loose and feasible mode to handle
multihoming [RFC 3704].
~Anyway, false positive is a very bad feature for a mechanism. 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Guang, 1.4:
~I'm not sure it's a problem of assumption.
~Maybe you can make your assumptions clear.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Guang, 1.4:
~Yes, I agree it's not perfect. However, we can compare the failure
possibility of DAD snooping 
~and FCFS(false positive only):
~1. FCFS fails if (1.1) normal DAD is being attacked;
~			(1.2) DAD NA is missing;
~		    (1.3)Collision you mentioned
~2. DAD snooping fails when (2.1) DAD NA is missing
~					    (2.2) Collision you mentioned
~
~I think it is quite clear (1.2),(1.3) ,(2.1),(2.2) happen with very little
possibility, but (1.1)
~can happen with great possibility.
~And (1.2),(1.3) ,(2.1),(2.2) is the failure of DAD mechanism, not the fault
of SAVI. (1.1) is
~the fault of SAVI.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Guang, 1.4:
~I think "both" would not solve the problem. 
~ND only is the reasonable solution.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Guang, 1.4:
~SAVI device is always the device directly connected with the host(first hop
switch or router).
~So it is not hard to guarantee the first point.
~And I don't think we have to guarantee ND message is delivered to all
nodes. It is enforced
~by standard and it only fails with little possibility.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Guang, 1.4:
~A great example. But
~(1) If the nodes are not aware of merging, they must not leave their switch
(or else it is the same
~as a node is attached to the LAN for the first time.) and the switch must
be used in the new LAN. If
~the binding is performed on the switch, there is no trouble. If the binding
is performed on the router,
~also no trouble. The binding information is always not removed and it can
be used again, without requirement
~of another DAD.
~(2) It is really an infrequent situation.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Guang, 1.4:
~(1) The SAVI device knows what the situation is clearly, because it has
recorded all addresses.
~(2) And my point is: We choose DAD snooping for host relies on DAD
exclusively, rather than
~DAD is robust.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Guang, 1.4:
~Well, I wonder will DAD message be dropped at the first link? I remember
link layer protocol
~has acknowledgement and retransmission policy.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Guang, 1.4:
~OK, I will make clear WHAT we lose if we use data packet solely.
~(1) Normal behavior hosts will face additional vulnerability for their
legally got addresses 
~can be regarded as spoofing by SAVI device. Attack against Target Address
in DAD NS message
~is connived and protected by SAVI device.
~(2)Evil behavior hosts benefit from easily flooding addresses. They easily
take control of 
~an amount of addresses in an address-critical network and make other hosts
hard to find a
~useable address. Moreover, such attack is also protected by SAVI device.
However, DAD snooping
~can at least reduce the speed of address occupation.
~(3)For any data traffic may trigger binding, the cost of processing a
single packet is heavy.
~Any packet with new address will trigger a binding and attacker can design
a rather easy attack
~against SAVI device.
~
FCFS flow:
Data packet----(source in binding table)----->forward
	   ----(source not in binding table)----->check whether to bind or
not--------(address used by another)-->drop
	
-------(first use)->bind and forward
Signal packet (I'm not clear)

DAD Snooping flow:
Data packet---(source in binding table)----->forward
		  ---(source not in binding table)----->drop
Signal Packet--------(address used by another)-->drop
	       -------(first use)->bind and forward

For any packet, DAD snooping has only a check process. But FCFS may have two
checks.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Guang, 1.4:
~And if use signal packets and data packets together, (2) and (3) will still
stand.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Guang, 1.4:
~Yes. If every NA is delivered to the tentative node, the SAVI device
doesn't have to do anything here.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

here, i disagree

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Guang, 1.4:
~The security problem of DAD is easy to handle since the SAVI device has
recorded all the addresses
~a node owns. So it is easy to filter spoofing DAD NA.
~The completeness is harder. But the SAVI device can run as a ND proxy as
mention above.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Guang, 1.4:
~Regards, Guang
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
regards, marcelo

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Sun, 04 Jan 2009 14:45:12 +0100

> we can  consider the host is offline.

First, i am not sure we want to impose such restriction.
this is one possible configuration, but depending what do you want to 
enforce, it may be ok to have the SAVI function in a higher part of the 
topology (for instance, if you have a switch topology

Second, if the host is connected to a hub, for instance, and the hub is 
then connected to a switch where the SAVI function is performed, then 
from the host perspective, the DAD procedure would have been 
successfull but the sav device will not be aware of the NADV packet. IF 
the failure is restored after that, then the SAVI will filter the data 
packets

Bottom line is, what do you do when the savi device receives a data 
packet contianing a source address that is not present in the savi db?
I can see 3 options here:
1- one is to filter it. I don't think this is acceptable
2- the other one is to create a new savi db entry with the information 
of the data packet
3- the third option is to perfrom some check, like the NUD procedure 
with the information contained in the packet. I don 't feel this is 
necesary, since i fail to see what additional information would this 
new check would provide

Do you think there are more options that this?
which option do you think is reasonable and why?

> more level in controling parcket, ND/ARP, DHCP, etc).

I fail to see why do you think that a control packet packet provides a 
higher security level than the data packets
BEsides as i mention already, i don't see using control packets and 
data packets as mutually exclusive, but as complementing each other. 
The question here is about a tradeoff between simplicity and 
capabilities.

> 3.Same approach in IPv4.
> Yes, DAD mandatory in IPv4 is one.

I don't understand what you mean here...

> We have more approach,

I don't understand what you mean here
We can certainly require new capabilities in the SAVI device, but to 
rely in IPv4 DAD, the hosts need to implement it
In order to define a mechanism that is suscetible of wide deployment we 
need to rely on features that are actually widely deployed in the hosts 
and i am not sure rfc5227 is one of them

Regards, marcelo

> Cc: "Guang Yao" <[email-masked]>; "'SAVIMailing 
> List'" <[email-masked]>; "'Christian Vogt'" 
> <[email-masked]>; "'Frank Xia'" <[email-masked]>

---

From: Christian Vogt <[email-masked]>
Date: Wed, 7 Jan 2009 20:39:42 -0800

David and all -

> I also did not find draft-vogt-savi-rationale in the ID repository.

You are right; I forgot to provide a link to Internet draft
draft-vogt-savi-rationale.  Even though Marcelo kindly did this for me,
we should extend the review deadline for this draft.  Please provide
your feedback until Wednesday, Jan. 14, regarding the adoption of
draft-vogt-savi-rationale as a SAVI working group document.

Again, you find draft-vogt-savi-rationale under the following link.  The
draft should also appear soon in the official IETF repositories.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 08 Jan 2009 14:13:51 +0100

I think i have missed this one...

see below...

I simply don't agree with he way you compare the approaches
For me, it makes sense to create the FCFS SAVI state based on the first
packet that refers tot he soruce address, whether this packet is ND,
dhcp or a data packet.

So, the only disucssion we are having here is that i think we should use
both data packets and control packets and you argue that you want to use
only DAD packets.

So, what we need to compare is FCFS SAVI using both control and data
packets versus doing FCFS SAVI based only in DAD packets.

In that case, it is clear that there are more failure modes that fail in
the case of using only control packets, since it is a subset of the
other that uses both control and data packets.

Now, this is not enough to also use data packets, since we need to
quantify if it is worth the additional complexity.

the problems that is see with using only DAD packets are:
- first, i don't think this flies for IPv4, since i would assume that
DAD for v4 is not widely implemented. So for IPv4 we must use soemthing
else. (in this case, i wonder if it is worth the complexity of using
DAD, but this depends on how widely IPv4 DAD has been adopted)
- second, even for IPv6, what would you do if you are only doing DAD and
you receive a data apcket with a soruce address that is not in the SAVI
data base? you would drop it? This means that if the DAD msg was
corrupted, or lost or whatever, you are blocking a legitimate user, and
as you say, false positives are very bad.

why?

> ~So it is not hard to guarantee the first point.
what is the first point?

> ~by standard and it only fails with little possibility.
agree, but if it fails, you have a false positive, which as you said is
very bad.

right, but what i have in mind is that there are two switches connected
to each other and each switch is performing the SAVI function.
So, what breaks is the link between the two switches. So, the DAD msg is
propagated but only to the node in the same switch. When the two
switches are linked togheter again, the SAVI function of the other
switch has not seen the DAD mesages in the other switch that were sent
during they were separated

> ~also no trouble.

wait, you said before that SAVI is performed in the first hop?
So are you assuming that the savi is performed in the first hop or not?
I don't think it is a reasomnable assumption to make, but you seem to
contradict yourself here.

>  The binding information is always not removed and it can

well, all the mechanimss for the creation of adjacencies in OSPF are
intended to address problems like this when a network gets partitioned
and these are pretty complex... i don't think they would do all that
work if they thought the probablitly of such even was negligible

> recorded all addresses

but DAD messages can get lost or have errors, right?
My point is what happens in that situation? SAVI just starts droping the
packets and blocks the host out of the network cause the DAD msg was
lost? As you said, false positives are very bad.
> .
I can't parse this sentence

messages can get errors, lost in the hardware interface and so on... Are
you assuming that links don't have errors in packets?
I am not arguing we should only rely on data packets, My point is that
we should create the FCFS state based on the first apcket referring that
address, whether data or control packet
We may want to disregard some control packets if they are not widely
used, in particular i have some doubts w.r.t. IPv4 DAD as i am not sure
how widely deployed this is.

>> 2 Data traffic is either dropped or forwarded according to binding,
>>     
> without
>   
> ~a node owns. 

No, you are assuming packet don't get lost and netowrks don't get
partitioned
This is simply not true

Regards, marcelo