Subject: [savi] Consensus call on "unregistered" source addresses

From: Christian Vogt <[email-masked]>
Date: Mon, 13 Jul 2009 21:54:52 -0700

Folks -

As announced earlier, we will have a consensus call on how SAVI devices
should treat source addresses for which no configuration signaling was
seen.  Consensus questions for this were proposed on July 8, and the
feedback received from the working group indicates that those are OK.

I would hence like to initiate the consensus call.  To participate in
the consensus call, please answer by Sunday, July 19, the following two
questions (A) and (B), using one of the two possible answers provided
for each question:

(A) In networks where SLAAC is permitted for address configuration, how
     should a SAVI device treat packets with a source address for which
     neither a successful DAD procedure nor a DHCP assignment was seen?

     (A1) Discard the packet
     (A2) Forward and optionally log the packet

(B) In networks where only DHCP is permitted for address configuration,
     how should a SAVI device treat packets with a source address for
     which no DHCP assignment was seen?

     (B1) Discard the packet
     (B2) Forward and optionally log the packet

In these questions, a SAVI device sees a "successful DAD procedure" for
an address if it sees a DAD Neighbor Solicitation message, but no
responding DAD Neighbor Advertisement message, for this address.

Please recall the relationship of our two main SAVI solution proposals
to these consensus questions:  The FCFS and CPS solutions both use the
combination of (A1) plus (B1), with different means to reduce the
probability of dropping legitimate packets.  The middle-ground solution
we are considering now -- originally suggested in [1] by Marcelo, and
slightly augmented in [2] by me with an alternative mode for DHCP-only
networks -- uses the combination of (A2) plus (B1).  I would like folks
to consider in particular this combination of (A2) plus (B1) because it
constitutes a reasonable compromise between two competing solutions.

Please also recall our working assumption that SAVI will operate
exclusively in wired networks, with switch ports constituting the
binding anchors.  The goal of this working assumption is to relieve the
discussion from considerations about scenarios where SAVI can only have
limited benefit. Unprotected wireless networks are an example of those
scenarios, where forgeable MAC addresses are the only possible binding
anchors.  We will re-evaluate at a later stage how well SAVI applies to
other scenarios.

- Christian

[1] http://www.ietf.org/mail-archive/web/savi/current/msg00654.html
[2] http://www.ietf.org/mail-archive/web/savi/current/msg00715.html

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 Jul 2009 04:45:35 -0400

I would like to postpone the consensus call until the working group  
discussion in Sweden has past. I believe that

(a) we fundamentally do not have consensus re FCFS vs control-plane- 
based technologies that monitor DHCP or ND, and that
(b) we are more likely to have consensus, or at least our viewpoints  
will be better-informed, after we have had a chance to discuss them  
face to face.

On Jul 14, 2009, at 12:54 AM, Christian Vogt wrote:

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

---

From: Christian Vogt <[email-masked]>
Date: Tue, 14 Jul 2009 10:11:17 -0700

Fred -

We had a thorough discussion on the available solution options on this
mailing list.  In this discussion, three solution options have been
identified -- FCFS, CPS, and a middle-ground approach -- and the
properties of those have been analyzed.  Which aspects, do you think,
have not been sufficiently illuminated?

What do other working group members think?  Is more discussion needed
before a consensus call can be made?

- Christian

On Jul 14, 2009, Fred Baker wrote:

> (a) we fundamentally do not have consensus re FCFS vs
> control-plane-based technologies that monitor DHCP or ND, and that
>
> face
> to face.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Jul 2009 13:30:12 -0400

I do not think that the properties of the solutions have been analyzed.
More importantly, I do not think that the problem we are trying to solve 
is agreed.

As such, adopting a specific approach to specific pieces seems very odd.

Yours,
Joel

Christian Vogt wrote:
>> will be better-informed, after we have had a chance to discuss them face
>> to face.
> 
> 
>

---

From: Christian Vogt <[email-masked]>
Date: Wed, 15 Jul 2009 09:41:20 -0700

> More importantly, I do not think that the problem we are trying to  

Joel -

I will be happy to postpone the consensus call if folks prefer more
discussion to better understand the consequences of our various
alternatives.  Yet the question we are trying to answer, and the
background for it, should be clear by now.

As per our charter:  The problem that SAVI is to solve is
insufficiencies of ingress filtering in combatting IP source address
spoofing.  Hence the charter specifies the goal to "prevent nodes
attached to the same IP link from spoofing each other's IP addresses."

What the charter doesn't specify is whether hosts should be prevented
from using, without explicit (self-) assignment, IP addresses not in use
by any other host on the same IP link.  This is the question on which we
currently have a consensus call.

For an analysis of the various alternatives with respect to this
consensus call, please see [1] and the subsequent discussion.

- Christian

[1] http://www.ietf.org/mail-archive/web/savi/current/msg00715.html

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 15 Jul 2009 13:37:21 -0400

Interesting.  Given how you are describe it, you are saying that 
preventing use of unassigned addresses is a charter extension.
If so, we should first figure out if we want to do that at all, and then 
  determine which cases we think we can / should solve.
?
Joel

---

From: Christian Vogt <[email-masked]>
Date: Wed, 15 Jul 2009 19:12:43 -0700

Joel -

> preventing use of unassigned addresses is a charter extension.

Yes, strictly speaking, preventing use of unregistered addresses goes
beyond our charter.  Whether it requires a charter extension would have
to be discussed with the area directors.  The charter was deliberately
written to give the working group liberties with respect to the design
of a SAVI solution.  So we may find that no charter extension is needed.
Otherwise, I don't think a charter extension would be a big deal.

> determine which cases we think we can / should solve.

Agreed.  And this is what we are doing right now; it is the topic of the
ongoing consensus call.

The reason we are already now thinking of specific cases in which use of
unregistered addresses should be prevented -- rather than first only
thinking of whether we want to prevent such use in general -- is that
the benefits and costs of doing it strongly depend on the permitted
address configuration methods.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 17 Jul 2009 13:39:13 -0700

Everybody -

This is a reminder of our ongoing consensus call on the protection of
unregistered IP addresses.  Please send your feedback -- either by
answering the consensus questions, or by stating that you want more
discussion prior to making a decision.  The feedback we have received so
far is insufficient to make a conclusion.

The consensus call will continue until Sunday, July 19.

- Christian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 20 Jul 2009 08:31:25 +0300 (EEST)

This is a bit late, but:

>     (A2) Forward and optionally log the packet

This begs the question of 'seen' when?  How long should a SAVI device 
remember these exchanges?  Is the assumption that these are kept in 
volatile memory, so when the device reboots, the information is lost?

What happens immediately after SAVI device reboot assuming the 
connected hosts do not re-issue DAD procedure, with A1 such hosts 
would be blackholed if this information is only kept in memory until 
they issue DAD?

The network should not break if SAVI device reboots.  With sufficient 
constraints (e.g. the use of non-volatile memory) it may be possible 
to achieve this with A1.  However, A2 seems a more robust and more 
likely achievable approach at the moment.

>     (B2) Forward and optionally log the packet

In this case I suppose SAVI device would need to be manually 
configured to behave in this manner (i.e. it could not figure this out 
reliably on its own)?  In that case, B1 would seem to be fine.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 20 Jul 2009 14:59:17 +0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Pekka Savola
> Sent: Monday, July 20, 2009 1:31 PM
> To: Christian Vogt
> Cc: SAVI Mailing List
> Subject: Re: [savi] Consensus call on "unregistered" source addresses
> 
> This is a bit late, but:
> 
[Guang Yao] 
I think maybe the connected hosts must re-perform DAD procedure.
There is no assurance that their previous addresses wouldn't be used
during the period of their reboot.
If they insist to use their previous address, it can cause address conflict.
Even use default-forwarding policy, their address may be bound by another
host,
And they will still be separated.

And according to RFC4862, they MUST perform DAD again when interface is
re-initialized.
If they are directly connected to switch, their interfaces will surely be
re-initialized. That's
why I insist to set up binding only for directly connected hosts.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 20 Jul 2009 09:04:00 +0200

> reliably on its own)?  In that case, B1 would seem to be fine.
Why are you not concerned about the SAVI device rebooting and loosing 
its state (only learnt through the DHCP msg exchange snooping) and 
blocking legit nodes out of the network in this case?

I mean, isn't a similar problem that you mentioned in the above case 
also possible here?

Thanks, marcelo

---

From: Pekka Savola <[email-masked]>
Date: Mon, 20 Jul 2009 10:08:21 +0300 (EEST)

On Mon, 20 Jul 2009, Guang Yao wrote:
> And according to RFC4862, they MUST perform DAD again when interface 
> is re-initialized. If they are directly connected to switch, their 
> interfaces will surely be re-initialized. That's why I insist to set 
> up binding only for directly connected hosts.

But as far as I know, we have not (at least yet) restricted SAVI 
solution to only directly connected hosts.  And hence the problem with 
DAD reinitialization assumption.

Marcelo: yes, losing DHCP binding information is a similar concern. 
Maybe I was thinking that some switches which do perform that snooping 
already store information in non-volatile media.  I agree that these 
should be treated similarly.

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 20 Jul 2009 15:10:06 +0800

> marcelo bagnulo braun
> Sent: Monday, July 20, 2009 3:04 PM
> To: Pekka Savola
> Cc: SAVI Mailing List; Christian Vogt
[Guang Yao] 
In RFC3315, when the interface is re-initialized, it must send a CONFIRM
to the server to check whether the assigned DHCP address is still valid.
This message can be used to re-bind address.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 20 Jul 2009 10:00:29 +0200

Guang Yao escribió:
>>>>     neither a successful DAD procedure nor a DHCP assignment was
>>>>         
>> seen?
>>     
>>>>     (A1) Discard the packet
I guess the question is what it means an interface being reinitialized 
in the context of RFC4862 and RFC3315.
Each time the link is down is the interface reinitialized? Is this true 
for wifi links that are very flappy?

Regards, marcelo

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 20 Jul 2009 16:38:25 +0800

> From: Pekka Savola [mailto:[email-masked]]
> Sent: Monday, July 20, 2009 3:08 PM
> To: Guang Yao
> Cc: 'SAVI Mailing List'
> Subject: RE: [savi] Consensus call on "unregistered" source addresses
> 
[Guang Yao] 
Sure there is no that restriction.
However, design a solution also for not directly connected hosts has other
problems:
1: Memory cost.
2: The mechanism to remove binding when remote host leaves.

I just suggest a solution designed only for directly connected hosts is
stable and more simple.

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 20 Jul 2009 12:15:01 +0200

Sorry for the late response, see inline ...

>     (A2) Forward and optionally log the packet
The logging looks like the poor-man solution, and it carries its own 
issues and caveats. It basically says "we can't rely on the accuracy of 
the binding table, so let's log to let the final word to a human".
However logging carries it's own serious issues: it forces to take high 
level hence slow actions in the data path, which makes the switch either 
a lot more vulnerable, or likely to fail to log important informations.
It is also likely to generate amount of information out of reach of many 
network operators.
Using the logging as the excuse for failing to build an accurate binding 
table sounds dangerous: it suggests we expect a lot of false positive, 
which will make the log analysis hard, and will be exploited by attackers.
I'll prefer that we make assumptions on what it takes to build an 
accurate binding table (non-volatile memory, maybe some assumption on 
DAD, snooping on other NDP packets, etc), and when these assumptions 
are  true, we drop & log.
All devices are not equal (hardware/software wise, but also 
deployment-wise), so would be acceptable to habe those which can't 
verifyi the assumptions to not drop/log in my opinion.
Eric

---

From: Alberto García <[email-masked]>
Date: Mon, 20 Jul 2009 12:49:13 +0200

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
Eric
|  Levy-Abegnoli
|  Enviado el: lunes, 20 de julio de 2009 12:15
|  Para: Christian Vogt
|  CC: SAVI Mailing List
|  Asunto: Re: [savi] Consensus call on "unregistered" source addresses
|  
|  Sorry for the late response, see inline ...
|  
|  Christian Vogt a écrit :
|  > Folks -
|  >
|  > As announced earlier, we will have a consensus call on how SAVI devices
|  > should treat source addresses for which no configuration signaling was
|  > seen.  Consensus questions for this were proposed on July 8, and the
|  > feedback received from the working group indicates that those are OK.
|  >
|  > I would hence like to initiate the consensus call.  To participate in
|  > the consensus call, please answer by Sunday, July 19, the following two
|  > questions (A) and (B), using one of the two possible answers provided
|  > for each question:
|  >
|  > (A) In networks where SLAAC is permitted for address configuration, how
|  >     should a SAVI device treat packets with a source address for which
|  >     neither a successful DAD procedure nor a DHCP assignment was seen?
|  >
|  >     (A1) Discard the packet
|  >     (A2) Forward and optionally log the packet
|  >
|  The logging looks like the poor-man solution, and it carries its own
|  issues and caveats. It basically says "we can't rely on the accuracy of
|  the binding table, so let's log to let the final word to a human".

I think we are loosing perspective: A2 option does protect the binding
performed by a DAD that is not lost. 
What it is saying is what happens when this does not occur. I have read in
the list a number of cases in which this occurs. What A2 saying is that in
that events (may be not frequent, but that occur) communication of
legitimate users cannot be interrupted. 
Logging is optional. The protection is the binding when DAD occurs, and this
is valuable in itself. If you have resources to do logging, ok, go for it. 

Personally, I consider A1 unacceptable.
For what to do for packets forwarded without seeing a DAD, maybe there are
other options to consider apart from A2:
(A3) create a bind just when a data packet is received for the first time
(A4) create a bind just when a data packet is received for the first time
and use a SAVI protocol to check that there isn't a different binding for
the same address in other switches.
More analysis should be carried to decide among A2, A3, A4... Ax. 
But I don't consider A1.

|  However logging carries it's own serious issues: it forces to take high
|  level hence slow actions in the data path, which makes the switch either
|  a lot more vulnerable, or likely to fail to log important informations.
|  It is also likely to generate amount of information out of reach of many
|  network operators.
|  Using the logging as the excuse for failing to build an accurate binding
|  table sounds dangerous: it suggests we expect a lot of false positive,
|  which will make the log analysis hard, and will be exploited by
attackers.
|  I'll prefer that we make assumptions on what it takes to build an
|  accurate binding table (non-volatile memory, maybe some assumption on
|  DAD, snooping on other NDP packets, etc), and when these assumptions
|  are  true, we drop & log.

I don't think non-volatile memory is a solution.
Consider the root switch fails. Spanning tree takes sometime to be built
again. In the meanwhile, a host connected to a switch has issued a DAD NSOL.
The host has no means to know that the switched infrastructure is not going
to deliver appropriately the DAD packet. When everything recovers, the host
traffic is blocked.
And when switches change its position in the spanning tree, I don't think
there is an easy way to use the previous information, because it can be
topologically meaningless.

Snooping NDP packets: why NDP packets are more reliable than data packets?
For me this is just (A3).

Regards
Alberto

|  All devices are not equal (hardware/software wise, but also
|  deployment-wise), so would be acceptable to habe those which can't
|  verifyi the assumptions to not drop/log in my opinion.
|  Eric
|  > (B) In networks where only DHCP is permitted for address configuration,
|  >     how should a SAVI device treat packets with a source address for
|  >     which no DHCP assignment was seen?
|  >
|  >     (B1) Discard the packet
|  >     (B2) Forward and optionally log the packet
|  >
|  > In these questions, a SAVI device sees a "successful DAD procedure" for
|  > an address if it sees a DAD Neighbor Solicitation message, but no
|  > responding DAD Neighbor Advertisement message, for this address.
|  >
|  > Please recall the relationship of our two main SAVI solution proposals
|  > to these consensus questions:  The FCFS and CPS solutions both use the
|  > combination of (A1) plus (B1), with different means to reduce the
|  > probability of dropping legitimate packets.  The middle-ground solution
|  > we are considering now -- originally suggested in [1] by Marcelo, and
|  > slightly augmented in [2] by me with an alternative mode for DHCP-only
|  > networks -- uses the combination of (A2) plus (B1).  I would like folks
|  > to consider in particular this combination of (A2) plus (B1) because it
|  > constitutes a reasonable compromise between two competing solutions.
|  >
|  > Please also recall our working assumption that SAVI will operate
|  > exclusively in wired networks, with switch ports constituting the
|  > binding anchors.  The goal of this working assumption is to relieve the
|  > discussion from considerations about scenarios where SAVI can only have
|  > limited benefit. Unprotected wireless networks are an example of those
|  > scenarios, where forgeable MAC addresses are the only possible binding
|  > anchors.  We will re-evaluate at a later stage how well SAVI applies to
|  > other scenarios.
|  >
|  > - Christian
|  >
|  >
|  > [1] http://www.ietf.org/mail-archive/web/savi/current/msg00654.html
|  > [2] http://www.ietf.org/mail-archive/web/savi/current/msg00715.html
|  >
|  >
|  >
|  > _______________________________________________
|  > savi mailing list
|  > [email-masked]
|  > https://www.ietf.org/mailman/listinfo/savi
|  >
|  
|  _______________________________________________
|  savi mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Jul 2009 12:51:57 -0400

While I agree with most of what Eric says below, I want to clarify one 
aspect of logging.

Even if we can get perfect enforcement, if we are concerned about 
external use of addresses (which is almost certainly the case if we care 
about preventing unregistered address usage), logs are absolutely 
necessary.  These may be logs of the allocation and binding process, 
rather than logs of the enforcement process (which is a big advantage in 
terms of complexity impact), but when someone external comes in and says 
"IP address X did action Y" there needs to be enough information to 
figure out what that means.  More than just "yes, that is one of our 
addresses."  Otherwise, when all is said and done, not much has been 
accomplished.

Yours,
Joel

---

From: Christian Vogt <[email-masked]>
Date: Wed, 22 Jul 2009 15:21:41 -0700

On Jul 20, 2009, Marcelo Bagnulo Braun wrote:

>> configured

>> to behave in this manner (i.e. it could not figure this out  
>> reliably on
>> its own)?  In that case, B1 would seem to be fine.
>

Good point.  A solution to deal with state loss in SAVI devices in DHCP-
only networks, which enables (B1), is described in CPS:

In DHCP-only networks, one can ensure, through manual configuration of
SAVI devices, that SAVI protection is active only on ports that directly
connect to hosts.  This way, if a SAVI device loses state due to a
reboot, hosts discard their DHCP state as well because the link
temporarily goes down. Afterwards, hosts obtain new addresses via DHCP,
thereby re-building the state in SAVI devices.

The same could theoretically be applied also to networks where SLAAC is
permitted (question A).  But here, the cost of manual configuration may
not pay off.  The reason is that strong protection of unassigned
addresses is of little use in networks where SLAAC is permitted due to
the ability of hosts to self-assign any yet-unassigned address.

Consequently, I think the combination of (A2) and (B1) does make sense.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 22 Jul 2009 15:26:24 -0700

On Jul 20, 2009, Eric Levy-Abegnoli wrote:

> [..] All devices are not equal (hardware/software wise, but also

Eric, are you saying that you prefer (A2) without logging?

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 09:23:03 +0200

Christian Vogt escribió:
>>> In this case I suppose SAVI device would need to be manually configured
>
>>> to behave in this manner (i.e. it could not figure this out reliably on

I have not checked the dhcp spec in detail for this, but does it 
mandates that the dhcp lease MUST be renewed after a link goes down and up?
Or is it like the SLAAC case where it is clearly not ambiguous the way 
the RFC is written and there is a bunch of exceptions when DAD can not 
be performed?

Regards, marcelo

---

From: "Greg Daley" <[email-masked]>
Date: Thu, 23 Jul 2009 17:49:11 +1000

Hi Marcelo, 

> the RFC is written and there is a bunch of exceptions when 
> DAD can not  be performed?

DHCPv6 Solicit/Advertise can be used to check the existing DHCP
Relay/Router is in use.

By default if there is an existing lease, there is no requirement to
retrieve a lease from
the server.

Of course, to talk DHCPv6 one is required to have an autoconfigured
Link-local address...

Greg

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Thu, 23 Jul 2009 10:25:09 +0200

> Eric, are you saying that you prefer (A2) without logging?

Christian , in the current state of the proposals, I am against both A1 
and A2. A2 is the worse though, because it's "politically correct": it 
does not break anything and provides "on the paper" all the tools to 
further investigate anomalies.
In reality, logging in the data path is not safe, not reliable (must be 
rate-limited), and prone to attacks. Logging it a useful and necessary 
tool, not a solution in itself. We should not use it as an excuse for 
not fixing the inaccuracy of our binding table.
As far as the "optional log", if we forward and don't log, what have we 
accomplished? Isn't it what current non-savi devices do today?
So my choice would go for
1) Work to build a more accurate binding table
2) With certain assumptions (to be specified), drop optionally
3) When assumptions can't be verified, log.
BTW, do we really need to make a choice there? It depends so much on the 
device capabilities and on the deployment environment that 
mandating/preventing whatever behavior don't seem to be practical. I’d 
rather treat that as a policy and mandate it to be configurable.
Eric

---

From: "Greg Daley" <[email-masked]>
Date: Thu, 23 Jul 2009 18:16:09 +1000

Greg Daley
Security Consultant
NetStar Australia Pty Ltd

E-mail: [email-masked]
Mobile: +61 401 772 770
Direct: +61 3 8532 4042
Fax:    +61 3 8532 4032 

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Thursday, 23 July 2009 5:58 PM
> To: Greg Daley
> Cc: Christian Vogt; SAVI Mailing List
> Greg Daley escribió:
> >> mandates that the dhcp lease MUST be renewed after a link  
> goes down
> >>     
> > and up?
> >   
> >> Or is it like the SLAAC case where it is clearly not  ambiguous the
> >>     
> > way 
> >   
> I am sorry, i am not sure i understand this.
> 
> suppose a host has obtained the lease fro the dhcp server
> then the link goes down for 30 secs and then back up,
> then what does the host does?
> 
> does it need to exchange a msg with the dhcp server or it can simply 
> keep on using the address it has (i am assuming the lease has not 
> expired and it is not close to the renewal date neither)

On a link where all addresses are managed by DHCP (RFC4862 M=1), it has complete ownership of the
address.  There is no explicit need to ask the DHCP server for an address in RFC3315.  It may try to 
check that the service is there with DHCPv6 SOLICIT or CONFIRM (which by default doesn't bind an address)

In section 18.1.2, a host which believes it may have moved to a new link MUST CONFIRM.
This doesn't mean that a lease is being allocated though.

The Simple DNAv6 procedures cover this in more detail though, and specify that the 
host should check if the DHCP server is actually there, even if the Router says no movement has occurred.
Clearly this is not standard RFC3315 behaviour though.

Greg

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 09:58:00 +0200

Greg Daley escribió:
>> mandates that the dhcp lease MUST be renewed after a link  goes down
>>     
> and up?
>   

Thanks, marcelo

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 23 Jul 2009 17:51:32 +0800

Hi All,

We support two modes in SAVI.
(1) In DHCP-only network.
(2) In DHCP-SLAAC mixed network.

We believe what the users want is the higher security level.
We think the default dropping will bring the network more secure, accounting 
accuracy,
and manageable.

Best Regards,
Jun Bi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 12:12:06 +0200

Guang Yao escribió:
>> Sent: Thursday, July 23, 2009 3:23 PM
>> To: Christian Vogt
>> Cc: SAVI Mailing List
>>>>> to behave in this manner (i.e. it could not figure this out reliably
>>>>>           
> on
>   
> See rfc3315 18.1.2
> The host _MUST_ send CONFIRM when
> 	o  The client reboots.
>
>    o  The client is physically connected to a wired connection.
>
>    o  The client returns from sleep mode.
>
>    o  The client using a wireless technology changes access points.
>
>   
so the node is not mandated to send a confirm when the switch that it is 
connected reboots as long as it remains the same

regards, marcelo

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 23 Jul 2009 17:33:12 +0800

configured
on
[Guang Yao] 
See rfc3315 18.1.2

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 23 Jul 2009 19:52:41 +0800

> Sent: Thursday, July 23, 2009 6:12 PM
> To: Guang Yao
> Cc: 'Christian Vogt'; 'SAVI Mailing List'
[Guang Yao] 
You must be kidding.
When the switch reboot, its ports are first turned down: then the client is
disconnected;
then turned on: then the client will be connected to the port. This is the
second case.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 15:01:07 +0200

Guang Yao escribió:
>>>>> Good point.  A solution to deal with state loss in SAVI devices in
>>>>>           
> DHCP-
>   
>>>>> SAVI devices, that SAVI protection is active only on ports that
>>>>>           
> directly
>   
>>>>> temporarily goes down. Afterwards, hosts obtain new addresses via
>>>>>           
> DHCP,
>   

is the host _physically_ disconnected?
>>>>> The same could theoretically be applied also to networks where SLAAC
>>>>>           
> is
>   
>>>>> permitted (question A).  But here, the cost of manual configuration
>>>>>           
> may
>   
>>>>> Consequently, I think the combination of (A2) and (B1) does make
>>>>>           
> sense.
>   
>>>>> - Christian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 23 Jul 2009 21:15:04 +0800

Dear Marcelo,

When the switch reboot, the host's interface thinks it is disconnected (no 
power at the cable), then the host send out
confirm when the link is up. I did see it during the test and I think you 
could also observe it if you snoop the packet.

Thanks,
Jun Bi

> [Guang Yao] You must be kidding.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 16:15:59 +0200

Jun Bi escribió:
> Dear Marcelo,
>
> When the switch reboot, the host's interface thinks it is disconnected 
> (no power at the cable), then the host send out
> confirm when the link is up.

sure, this is what i would call disconnect as you do

my question is what is the difference between disconnected and 
physically disconnected?

In addition, i guess there are at least two other problematic cases 
where the reboot in the savi device would result in problems:

The case when the host is connected to the SAVI device through a legacy 
switch, in case the reboot of the savi device is invisible to the host, 
so it won't send any dhcp msg

Ans besides, if we move to the wireless case,  it is explicilty stated 
in the below rules that:

So, in wireless networks a reboot in the savi device would not imply any 
dhcp mesage, so the lost state in case of reboot in this cannot be 
recovered by epxecting the host will send a new dhcp msg.

Regards, marcelo

> I did see it during the test and I think you could also observe it if 
> you snoop the packet.
>
> Thanks,
> Jun Bi
>
>>>>>
>>>> [Guang Yao]
>>>> See rfc3315 18.1.2

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 23 Jul 2009 22:33:58 +0800

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "'SAVI Mailing List'" <[email-masked]>; "'Christian Vogt'" 
<[email-masked]>; "Guang Yao" <[email-masked]>
Sent: Thursday, July 23, 2009 10:15 PM
Subject: Re: [savi] Consensus call on "unregistered" source addresses

      Please see my another reply on none-directly host.

      For the wired Ethernet case, it is no problem.

      thanks,
      Jun

Regards, marcelo

> I did see it during the test and I think you could also observe it if you 
> snoop the packet.
>
> Thanks,
> Jun Bi
>
>>>>>
>>>> [Guang Yao]
>>>> See rfc3315 18.1.2

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 16:42:19 +0200

Jun Bi escribió:
>
> ----- Original Message ----- From: "marcelo bagnulo braun" 
> <[email-masked]>
>> When the switch reboot, the host's interface thinks it is 
>> disconnected (no power at the cable), then the host send out

so basically also for the dhcp case, the cps solution is incompatible 
with legacy switches i.e. savi and legacy devices cannot be connected 
int he same subnetwork

>      For the wired Ethernet case, it is no problem.
we haven't yet clarified the disconnected versus physically disconnected 
issue

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 16:50:42 +0200

Jun Bi escribió:
> To: "Jun Bi" <[email-masked]>
> Sent: Thursday, July 23, 2009 10:42 PM
>          Did you see my another reply?
>          The more you deploy, the more you could anti-spoof.
>          There is a deployment suggestion.

which basically implies having different IP subnetworks, one with all 
SAVI devices and the other without SAVI devices

My point is that the limitation applies to both the SLAAC and the dhcp case
>> we haven't yet clarified the disconnected versus physically 
>> disconnected issue
>
>
>        I don't know how to anwer you.
>        What's your point?
>

that we should ask people who wrote the dhcp spec and people doing dhcp 
implementations  to give us some background on this
>
>
>
>>
>> Regards, marcelo
>>
>>
>>
>>>      thanks,
>>>      Jun
>>>
>>> Regards, marcelo
>>>
>>>
>>>> I did see it during the test and I think you could also observe it 
>>>> if you snoop the packet.
>>>>
>>>> Thanks,
>>>> Jun Bi
>>>>
>>>>>>>>
>>>>>>> [Guang Yao]
>>>>>>> See rfc3315 18.1.2

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 23 Jul 2009 22:45:03 +0800

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "'SAVI Mailing List'" <[email-masked]>; "'Christian Vogt'" 

> so basically also for the dhcp case, the cps solution is incompatible with 
> legacy switches i.e. savi and legacy devices cannot be connected int he 
> same subnetwork
>

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 23 Jul 2009 23:16:26 +0800

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "'SAVI Mailing List'" <[email-masked]>; "'Christian Vogt'" 
<[email-masked]>; "Guang Yao" <[email-masked]>
Sent: Thursday, July 23, 2009 10:50 PM
Subject: Re: [savi] Consensus call on "unregistered" source addresses

Jun Bi escribió:
>> with legacy switches i.e. savi and legacy devices cannot be connected int 
>> he same subnetwork
>>
>

           But it works.

           Setting up binding based on Control Packet Snooping (CPS) provide 
the beinit,
           and could be deployed in real enviroment,with a very low cost (no 
new protocol,
          no host change, etc). Please trade off the benifit and cost.

              Thanks,
              Jun

          In the real test, CPS works when switch reboot, change port, 
change switch.
          There is a SAVI implmentation in a switch, we will demo it at SAVI 
WG meeting.

          thanks,
          Jun

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Jul 2009 11:45:31 -0400

I think we should recognize that there are "non-SAVI" networks.
Some network configurations / operational policies simply do not meet 
the goals of SAVI.  It is perfectly reasonable (and I think necessary) 
for the working group to say that if you want the benefits (to the 
network operator and the larger community) that SAVI brings, you need to 
run your network in certain ways.

As an extreme example, a wireless network with no per-user security at 
either the MAC, Admission, or IP layers probably can not be "SAVI."

Similarly, a network using SLAAC probably needs to have certain 
additional mechanisms in place in order to be "SAVI."

I would suggest that we focus on what properties and constraints we need 
to have in place to meet our goals, and then what mechanisms can make 
use of those properties.

Yours,
Joel

PS: The reason for sending this is that it seems likely that many fixed 
wired networks (for example in office environments) using SLAAC will not 
be able to meet our requirements without additional constraints.

Jun Bi wrote:
> We think the default dropping will bring the network more secure, 
> accounting accuracy,
> and manageable.
> 
> Best Regards,
> Jun Bi
> 
> ----- Original Message ----- From: "Christian Vogt" 
> <[email-masked]>

---

From: "Jun Bi" <[email-masked]>
Date: Thu, 23 Jul 2009 23:57:05 +0800

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "Christian Vogt" <[email-masked]>; "SAVI Mailing List" 
<[email-masked]>
Sent: Thursday, July 23, 2009 11:45 PM
Subject: Re: [savi] Consensus call on "unregistered" source addresses

> Some network configurations / operational policies simply do not meet the 
> goals of SAVI.  It is perfectly reasonable (and I think necessary) for the 
> working group to say that if you want the benefits (to the network 
> operator and the larger community) that SAVI brings, you need to run your 
> network in certain ways.
>

Dear Joel and WG members,

I agree with that.
If the operator wants to prevent hosts in SAVI-area to spoof source address,
then please deploy more SAVI swtches.

Thanks,
Jun Bi

> Similarly, a network using SLAAC probably needs to have certain additional 
> mechanisms in place in order to be "SAVI."
>
> to have in place to meet our goals, and then what mechanisms can make use 
> of those properties.
>
> Yours,
> Joel
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Jul 2009 18:07:08 +0200

Jun Bi escribió:
>>> so basically also for the dhcp case, the cps solution is 
>>> incompatible with legacy switches i.e. savi and legacy devices 
>>> cannot be connected int he same subnetwork
>>>
>>

depends what do you mean by works....If you think that a solution that 
allows any attacker that connects to a savi device to sppof any address 
int he network works...

>           Setting up binding based on Control Packet Snooping (CPS) 
> provide the beinit,
>           and could be deployed in real enviroment,with a very low 
> cost (no new protocol,
>          There is a SAVI implmentation in a switch, we will demo it at 
> SAVI WG meeting.
>
>          thanks,
>          Jun
>>
>>
>>
>>>
>>> Regards, marcelo
>>>
>>>
>>>
>>>>      thanks,
>>>>      Jun
>>>>
>>>> Regards, marcelo
>>>>
>>>>

---

From: Christian Vogt <[email-masked]>
Date: Fri, 24 Jul 2009 23:22:57 -0700

> (2) In DHCP-SLAAC mixed network.

This exactly matches with the two questions of the consensus call:  Your
case (1) corresponds to question (B), your case (2) to question (A).

Given that you obviously agree with the way the consensus call was made,
why didn't you send your response?

- Christian

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Jul 2009 01:57:47 -0700

>     (A2) Forward and optionally log the packet

I think the question was malformed for the following reasons.

*IF* SLAAC is permitted, then by definition the host can pick whatever 
address it wants. DAD as defined is not a reliable protocol, thus 
pretending it is the way a host *registers* a SLAAC address makes no 
sense. For instance, if 802.1D bridges wait for 30 seconds before 
enabling a Ethernet port, then no DAD packet would be seen on the network.

Thus I think the case when the the admin wants to only allow registered 
addresses then SLAAC can not be used; DHCPv6 would need to be used as 
the assignment/registration protocol.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Jul 2009 01:57:57 -0700

> This doesn't mean that a lease is being allocated though.

What happens when a host can't tell that it has moved to a new link? I 
think in practice there are issues where the host can't tell or can't 
easily tell that it might be connected to a different l2 device.

To make the SAVI protocol robust I think we shouldn't rely on the "MUST 
CONFIRM".

> Clearly this is not standard RFC3315 behaviour though.

-08 of that draft says
    Where the host has acquired addresses from DHCPv6 or the host does
    not have a global prefix, it MAY prefer to use DHCPv6 messages either
    before or simultanously with Neighbour Discovery probing.

That doesn't seem to require that the host confirm.

FWIW I think the same issues show up for DHCPv4 where we have DNAv4 (RFC 
  4436) where the hosts sends a unicast ARP request to verify 
reachability after suspected movement. That specification doesn't 
request the host to do a DHCP transaction. It merely RECOMMENDs it be 
done in parallel with the ARP check as a performance optimization for 
the case when the host moved to a different subnet.

    Erik

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 28 Jul 2009 11:49:27 +0200

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
To: "Greg Daley" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Christian Vogt" 
<[email-masked]>
Sent: Tuesday, July 28, 2009 10:57 AM
Subject: Re: [savi] Consensus call on "unregistered" source addresses

>> address.  There is no explicit need to ask the DHCP server for an address 
>> in RFC3315.  It may try to check that the service is there with DHCPv6 
>> SOLICIT or CONFIRM (which by default doesn't bind an address)
>>

Dear Eric,

Thank you for the analysis.
However, from the viewpoint of network opeartor, if we chose DHCPv6-ONLY 
mode, it means that the administrator
needs higher level of management on source addresses. Then host can only get 
the address by following DHCPv6
prcedure, so that the administrator could manage the network without any 
source spoofing.
If the host failed to do DHCPv6 procedure, it's reasonable that the host 
can't access the network.

During our real test on CPS, host did send CONFIRM when it change to another 
port or switch reboot
(in was triggered by the link down and up). We will demo CPS at SAVI-WG. CPS 
is being widely deployed
in CNGI-CERNET2, if we found the problem, we will report it. Up to now,no 
problem on this was found.
I also believe the long time use of IP source guard in IPv4 also proved no 
problem was found.

Best Regards,
Jun

>> The Simple DNAv6 procedures cover this in more detail though, and specify 
>> that the host should check if the DHCP server is actually there, even if 
>> the Router says no movement has occurred.
> 4436) where the hosts sends a unicast ARP request to verify reachability 
> after suspected movement. That specification doesn't request the host to 
> do a DHCP transaction. It merely RECOMMENDs it be done in parallel with 
> the ARP check as a performance optimization for the case when the host 
> moved to a different subnet.
>
>    Erik

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 28 Jul 2009 12:20:11 +0200

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
To: "Christian Vogt" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Sent: Tuesday, July 28, 2009 10:57 AM
Subject: Re: [savi] Consensus call on "unregistered" source addresses

>>     (A2) Forward and optionally log the packet

Hi Eric,

I believe up to know, most people in the mailing-list thinks that in 
DHCP-ONLY network,
It will discard the packet (where FCFS doesn't discard but forwarding).

The purpose of the WG is to anto-spoofing in fine granularity. So  In 
DHCP-SLAAC mixed mode,
I think maybe the switch still need to discard the packet A1) because the 
DHCP is still here.

We could discuss for SLAAC-only case. See below.

> address it wants.

Sorry, I don't agree with that. In SLAAC-only case, the administrator *at 
least* doesn't
want a host to use the source address of another *unsed* address being used 
in the same link,
so you could not say "by definition the host can pick whatever address". If 
you statement was correct,
then "the requrement of SAVI solution to work on SLAAC-only network" should 
be remove from
the SAVI charter becasue "by definiation", we did't need anti-spoofing in 
SLAAC-only mode ("host can pick up whatever address it wants").
I know you are an expert, so I don't belive you really think so.

Best Regards,
Jun Bi

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Tue, 28 Jul 2009 13:31:05 +0200

Erik,
Erik Nordmark a écrit :
> Thus I think the case when the the admin wants to only allow 
> registered addresses then SLAAC can not be used; DHCPv6 would need to 
> be used as the assignment/registration protocol.
>
Maybe it's a matter of wording. In the SLACC case, the host does not 
*register*,  however it is not unreasonnable to expect that the first 
hop (L2 switch)  have seen a binding for it. In a sense, it's not very 
different from RPF. If you don't have a return path to it, it is 
suspicious. Not broken because the nexthop will do address resolution on 
the reverse path, but suspicious because bindings are announced in a 
fairly redundant way (DAD * n, NA, NS*3)
It really takes some specific cases to not see any binding prior to 
forward a host traffic. And then it's a matter of policy: Your example 
is the one of a non-savi switch (your 802.1D bridge) connected to a savi 
switch. The policy could be to forward by default in this case.
Eric.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Jul 2009 05:12:14 -0700

Jun Bi wrote:

> needs higher level of management on source addresses. Then host can only 
> get the address by following DHCPv6

Agreed.

> During our real test on CPS, host did send CONFIRM when it change to 
> another port or switch reboot

Did you test all implementations that exist?
Did you test future implementations (not yet implemented) which will 
conform to draft-ietf-dna-simple?

> (in was triggered by the link down and up). We will demo CPS at SAVI-WG. 
> CPS is being widely deployed
> in CNGI-CERNET2, if we found the problem, we will report it. Up to 
> now,no problem on this was found.
> I also believe the long time use of IP source guard in IPv4 also proved 
> no problem was found.

Has IPv4 source guard been tested with all possible DHCPv4 
implementations, including implementations that conform to RFC 4436?

I think for DNAv4 and DNAv6 is it relatively simple to make the host 
fall back to sending a DHCP packet; just need to make sure that the 
ARP/ND packet that is used to verify the connectivity is blocked by the 
SAVI device (when the source address is not registered).

For non-DNA implementations things are harder assuming that we want to 
support folks having unmanaged switches at the edges of the network, 
because in that case the host would not see a link down event if the 
SAVI switch fails. Similar issues can appear for wireless technologies 
if the NIC or device driver transparently reconnects to a different 
access point.

In those case it would be difficult to come up with a robust DHCPv* SAVI 
approach.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Jul 2009 05:13:54 -0700

Jun Bi wrote:

> Sorry, I don't agree with that. In SLAAC-only case, the administrator 
> *at least* doesn't
> want a host to use the source address of another *unsed* address being 
> used in the same link,
> so you could not say "by definition the host can pick whatever address". 
> If you statement was correct,
> then "the requrement of SAVI solution to work on SLAAC-only network" 
> should be remove from
> the SAVI charter becasue "by definiation", we did't need anti-spoofing 
> in SLAAC-only mode ("host can pick up whatever address it wants").

You missed the key point that DAD is not a reliable address registration 
protocol.

Regards,
    Erik

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 28 Jul 2009 15:20:18 +0200

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "Christian Vogt" <[email-masked]>; "SAVI Mailing List" 
<[email-masked]>
Sent: Tuesday, July 28, 2009 2:13 PM
Subject: Re: [savi] Consensus call on "unregistered" source addresses

Hi Eric,

I didn't think in my last email I was talking about how to set up the 
binding table in CPS.
Then I don't know why you ask such a question here.
In my last email, I questioned your such a statement: "*IF* SLAAC is 
permitted, then by definition the host can pick whatever address it wants". 
Can a savi-swtich allow a host to use the address that another host under 
another SAVI switch being legally used ? (you statement permits this). It is 
really source address spoofing. If you statement was agreed in SAVI WG, then 
the SLAAC network should be removed from SAVI charter.  Then I thought you 
mistyped something.

Since you mentioned the DAD loss again, I am happy to let you know that in 
the new verison of CPS-01,
no only DAD is used, but also the  unsolicited NA and NS to resovle the 
address, based on the suggestion from Eric Levy-Abegnoli. As he stated and 
we agreed, "the odds of getting none of them are extremely low." You 
questions helped us to improve the CPS, so thank you very much. I am happy 
because so far the CPS is still a low cost solution to makes the low end 
access switch (as low as 200-300USD per switch as we will demo on Thursday) 
easy to implement CPS.

There is another way could be consdiered to enhace the reliability of DAD.

    In RFC4862.
   "   DupAddrDetectTransmits  The number of consecutive Neighbor
      Solicitation messages sent while performing Duplicate Address
      Detection on a tentative address.  A value of zero indicates that
      Duplicate Address Detection is not performed on tentative
      addresses.  A value of one indicates a single transmission with no
      follow-up retransmissions.
      Default: 1, but may be overridden by a link-type specific value in
      the document that covers issues related to the transmission of IP
      over a particular link type (e.g., [RFC2464])."

    One possible way is to ask the value of  DupAddrDetectTransmits  for 
SAVI client to change
  it to a value of 2 or greater than 2 (then loss possiblity will be really 
lowered).
   It's not a heavy effort like to design a reliable BDP.

We also discussed with vendors on the possiblity of implementation. For 
example, if we have 20 IPv6 address bound at one port (one host could have 
multiple IPv6 addresses) in an access SAVI-switch, then the binding table 
wil be only 480 entries in ONE acceess switch (usually a switch has 24 
ports). If we use the default forwarding at the access switch, then the 
binding table of other access SAVI-switches will has to be distributed to 
every SAVI-switches. Let say if we have 50 SAVI switches in the link, then 
each SAVI-switch will have 480*50=24K entries. The problems then are:

(1) The cost of the switch will be extremely higher. You could check in the 
market how many ACL entries in the 2.5 layer access switches.

(2) The size of binding table in a single switch  will increase when the 
network getting larger. In a large network, it will be worse.

(3) Every DATA packet will go through this 24K-long list, it is a heavy 
burden for low end 2.5 layer access switch. It might has 24 100Mbit ports 
and giga ports. In CPS, the data packets only go through a list of 480 
entries.

(4)Defaul fowarding has to have a complicated binding talbe remove mechnisam 
for savi access switch, to synchonize the binding table with other 49 
savi-switch in the local link. Otherwise, your binding table will be 
increased. When a host plug out the cable from one of other 49 far away 
switches, how could a local switch know this event and remove that host's 
address form its local binding table?  It's even worse in IPv6, because the 
large space of IPv6, the possiblity of the new host to use the unpluged 
address will be very low, then the new host's address just be added into 
binding entry in  all 50 savi-switches, the unpluged host's "old" address 
won't be removed. Then the binding table size in each access swithc will be 
larger and larger.
Yes, you colud say, we could ask a bigger switch with bigger ACLs to do it, 
but it means the opeator like us, we have
to buy expensive switch to use it as access switch. I don't think it's 
acceptable.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Jul 2009 07:35:36 -0700

Jun Bi wrote:

> permitted, then by definition the host can pick whatever address it 
> wants". Can a savi-swtich allow a host to use the address that another 
> host under another SAVI switch being legally used ? (you statement 
> permits this). It is really source address spoofing. If you statement 
> was agreed in SAVI WG, then the SLAAC network should be removed from 
> SAVI charter.  Then I thought you mistyped something.

FWIW what I meant is that a host can pick an address with any interface 
ID, which is different than the DHCP case when the DHCP server assigns 
the interface ID. Of course we want SAVI to prevent stealing somebody 
else's IP address even when SLAAC is used.

> Since you mentioned the DAD loss again, I am happy to let you know that 
> in the new verison of CPS-01,
> address, based on the suggestion from Eric Levy-Abegnoli. As he stated 
> and we agreed, "the odds of getting none of them are extremely low." You 
> questions helped us to improve the CPS, so thank you very much. I am 
> happy because so far the CPS is still a low cost solution to makes the 
> low end access switch (as low as 200-300USD per switch as we will demo 
> on Thursday) easy to implement CPS.

I suspect you have a model where
  - SAVI must be implemented on the first hop switch (the one connected 
to the host)
  - the hosts can reliably get indications from layer 2 when the switch 
fails or the link goes down and up

I want SAVI to applicable in a broader model.

It seems to be sufficient to require that there is a (convex) SAVI 
perimeter where all the switch ports that cross that perimeter have SAVI 
enabled. Switch ports inside the perimeter (e.g., the ports that connect 
switches together) do not need to have SAVI enabled.
That model allows non-SAVI devices outside of the perimeter.

However, in that model you can't assume that the host will send anything 
when there are switch failures. Instead you have to build the robustness 
into the SAVI mechanisms themselves.

In the case that we allow unregistered access that isn't hard; the SAVI 
device would send a DAD probe on behalf of the host when it hears a new 
IP address on a port. Thus it gets triggered (subject to rate limiting 
of course) by any IPv6 packet arriving on the port that doesn't match 
the allowed set of IPv6 addresses on the port.

>  it to a value of 2 or greater than 2 (then loss possiblity will be 
> really lowered).

I don't think the reliability of SAVI should depend on changes to the 
hosts. If we are going to allow changes to host we might as well have 
the host do something designed to be reliable such as 
http://tools.ietf.org/html/draft-nordmark-6lowpan-reg-00

>   It's not a heavy effort like to design a reliable BDP.

FWIW I don't see a need to design a reliable BDP, nor a need for every 
SAVI device to know all the IP addresses in use.

But SAVI needs to be robust against different host behavior. And if we 
can't allow unmanaged switches outside of the SAVI perimeter then I 
think we are significantly limiting the utility of SAVI.

    Erik

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 28 Jul 2009 17:10:42 +0200

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Christian Vogt"
<[email-masked]>; "Greg Daley" <[email-masked]>
Sent: Tuesday, July 28, 2009 2:12 PM
Subject: Re: [savi] Consensus call on "unregistered" source addresses

> Did you test all implementations that exist?

We will demo with dhcpv6 client on Vista on Thursday.
We also test the open source dhcpv6 client software dibbler with linux and
windows.

There is an "IPv6 ready" logo test on the confermance to IPv6 protocols.
They do test IPv6-ready-DHCPv6. The current conclusion is that for those
implementations conform to standard, we don't found problem yet.
Don't we hope the implementations conform to standards?

> conform to draft-ietf-dna-simple?

If it is not yet implemented, certianly we didn't test it.

> I think for DNAv4 and DNAv6 is it relatively simple to make the host fall 
> back to sending a DHCP packet; just need to make sure that the ARP/ND 
> packet that is used to verify the connectivity is blocked by the SAVI 
> device (when the source address is not registered).
>

CPS does snoop DHCPv4/v6, as well as APR/ND to set up binding table.
Don't forget, the princle of CPS is "control packets snooping ".
So I wonder why you ask such a question. What we blocked are the unwanted
data traffic.

> because in that case the host would not see a link down event if the SAVI 
> switch fails.

I don't quit understand you questions.
We only use default dropping at the savi access switch for the port directly
attached to a host.
In the case, the host should know the link down/up at the port.
Please see the multiple roles of port defined in CPS.

>Similar issues can appear for wireless technologies if the NIC or device 
>driver transparently reconnects to a different access point.

The current CPS is consdiered to be used in wired ethernet first
(What we will demo is also in wired ethernet, at least we know it works for
wired ethernet now.)
Extention will be considered later (how the savi-wifi ap should do).

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Jul 2009 08:26:23 -0700

Eric Levy-Abegnoli wrote:
> hop (L2 switch)  have seen a binding for it.

Which protocol reliably established that binding?

> In a sense, it's not very 

Standard IPv6 DAD does 1 DAD probe and nothing more.
The proposal I've seen is to only rely on that DAD probe.

> switch. The policy could be to forward by default in this case.

My primary example is SAVI/802.1D switches which leave the port in 
blocked or learning state for a while thereby dropping the DAD probe.

For the case where there is a legacy switch between the host and the 
SAVI switch I don't think we want to completely disable SAVI; that would 
severely limit the utility of SAVI (and I really want to see SAVI 
enabled by default everywhere) in common topologies. For instance 
corporate IT organizations that de-fact encourage folks to have small 
unmanaged switches in their office by charging per Ethernet drop.

I think the WG should figure out how to handle such cases in a robust 
manner.

    Erik

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 28 Jul 2009 17:40:13 +0200

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Christian Vogt"
<[email-masked]>
Sent: Tuesday, July 28, 2009 4:35 PM
Subject: Re: [savi] Consensus call on "unregistered" source addresses

>> permits this). It is really source address spoofing. If you statement was
>> agreed in SAVI WG, then the SLAAC network should be removed from SAVI
>> charter.  Then I thought you mistyped something.
>
> ID, which is different than the DHCP case when the DHCP server assigns the
> interface ID. Of course we want SAVI to prevent stealing somebody else's
> IP address even when SLAAC is used.
>

Hi Eric,

Thank you for the reply. You explaination make me undertand that we have the
same goal.

>> low end access switch (as low as 200-300USD per switch as we will demo on
>> Thursday) easy to implement CPS.
>
>  - SAVI must be implemented on the first hop switch (the one connected to
> the host)

   In CPS-01, we have the following port tyeps:

 8.1.1. Port Attributes
 The attribute of port depends on the role of the port.
 A port on a SAVI switch can be set to have none or more of all the 
attributes. If a port has an attribute, the corresponding snooping and 
filtering policy will be used on this port. If a port has multiple 
attributes, all the corresponding policies will be used. Conflict attributes 
MUST not be set to the same port.
8.1.1.1. SAVI-Host Attribute
 If and only if a port is directly connected with a host, this port can be 
set to have SAVI-Host attribute. Trunk port cannot be set to have this 
attribute.
 If a port has SAVI-Host attribute, control packet snooping MUST be 
performed on this port to set up bindings, and then the data packets from 
this port MUST be verified based on these bindings.
8.1.1.2. SAVI-DHCP-Trust Attribute
  If and only if a port is directly connected with a trustable DHCP server, 
or is a trunk port from which the DHCP reply should arrive, it can be set to 
have this attribute.
 When a port is configured to have SAVI-DHCP-Trust attribute, the switch 
trusts the DHCP reply messages from this port to establish bindings.
 If DHCP is used to assign address in the network, there should be at least 
one port has this attribute. DHCP reply message not from such ports MUST be 
dropped.
 In the situation DHCP-PD is used to configure prefix of the network, the 
switch also trust the Prefix Delegation message from port with this 
attribute.
8.1.1.3. SAVI-RA-Trust Attribute
 If and only if a port is directly connected with a trustable router, or is 
a trunk port from which the Router Advertisement should arrive, it can be 
set to have this attribute.
 When a port is configured to have a SAVI-RA-Trust attribute, the switch 
trusts the Router Advertisement messages from this port to learn the 
prefixes used on the link.
 There may be no SAVI-RA-Trust port in the network, even if only SLAAC is 
used to configure address.
 Router Advertisement received not from SAVI-RA-Trust port MUST be 
discarded.
8.1.1.4. SAVI-Trunk-Default Attribute
 If and only if a port is a trunk port, it can be set to have this 
attribute. This attribute is a conflict attribute of SAVI-Host attribute and 
SAVI-Trunk-Snooping attribute.
 No packet snooping will be performed on port with this attribute. Packet 
from port with such attribute will be forwarded if its source address doesn't 
conflict existing local bindings.
8.1.1.5. SAVI-Trunk-Snooping Attribute
 If and only if a port is a trunk port, it can be set to have this 
attribute. This attribute is a conflict attribute of SAVI-Host attribute and 
SAVI-Trunk-Default attribute.
 Control packet snooping MUST be performed on port with this attribute. The 
filtering policy on port with such attribute is based on 
 "default-forwarding" principle, which means packets from this port can be 
forwarded if its source address doesn't conflict local bindings.
 It is not SUGGESTED to set a trunk port to have this attribute, unless it 
is found that only to set a port to have this attribute will achieve the 
spoofing mitigation goal. Setting a port to have this attribute will 
possibly result in forwarding performance problem.

> into the SAVI mechanisms themselves.

However, we really observed the hosts realy sent control packets when the
switch down and up. We have such a demo.

> device would send a DAD probe on behalf of the host when it hears a new IP
> address on a port. Thus it gets triggered (subject to rate limiting of
> course) by any IPv6 packet arriving on the port that doesn't match the
> allowed set of IPv6 addresses on the port.

Hi Eric, are you proposing some enhancement on CPS?
If yes, then I understand.
If no, then I have to ask futher questions to understand it:
(1) How the binding table is setup up? By CPS or by FCFS?
(2) You do the DAD only at the access switch (directly connected to host)or 
at trunk ports.
(3)After the DAD, if there is no NA replyed, will the savi-switch setup a 
permit entry for that source address.
(4) If there is NA replyed, then will the savi-swtich setup a deny entry for 
that source address

> hosts. If we are going to allow changes to host we might as well have the
> host do something designed to be reliable such as

The current chart prevent to do much host change. The value setting of
DupAddrDetectTransmits is a very
minor thing. It is called the "value setting", not the host change.
Since DupAddrDetectTransmits is defined as a vaiable, not a constant, it
should be setable.
(Anway, please also see the above session another methond to reduce the
effction of dad loss.)

If we could change host much, please also see my solution draft CSA
presented in the
first SAVI meeting in IETF72 at Dublin.

So I think it depends on the degree of host change. Setting a value is very
lightweight and reasonable.

> SAVI device to know all the IP addresses in use.

Oh, I thought you are on the side to support a BDP or a way to let every
savi--switch know
the IP addresses being used, so that the savi-switch could use this binding
table to do anti-spoofing.
I am a little bit confused.
Then how you drop the spoofed trafic to achive the goal your statement at
the top of this email:

"Of course we want SAVI to prevent stealing somebody else's IP address even
when SLAAC is used."

I really don't belive you can make it without our idea "control packet
snooping".

Hi Eric, although curently I don't agree all you points, but I really feel
good to discuss technical questions
with you. You reply inspired me sometimes.

> can't allow unmanaged switches outside of the SAVI perimeter then I think
> we are significantly limiting the utility of SAVI.
>

I don't quite understand this.

Best Regards,
Jun Bi

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 28 Jul 2009 17:52:49 +0200

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
To: "Eric Levy-Abegnoli" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Christian Vogt" 
<[email-masked]>
Sent: Tuesday, July 28, 2009 5:26 PM
Subject: Re: [savi] Consensus call on "unregistered" source addresses

Eric Levy-Abegnoli wrote:
>> addresses then SLAAC can not be used; DHCPv6 would need to be used as the 
>> assignment/registration protocol.
>>
> *register*,  however it is not unreasonnable to expect that the first hop 
> (L2 switch)  have seen a binding for it.

> In a sense, it's not very different from RPF. If you don't have a return 
> path to it, it is suspicious. Not broken because the nexthop will do 
> address resolution on the reverse path, but suspicious because bindings 
> are announced in a fairly redundant way (DAD * n, NA, NS*3)

    Hi Eric,
      You saw the current CPS will do this in my last email.
      That is DAV*N (the value N of  DupAddrDetectTransmits) + NA + NS).
      In this case, the lost all of them is rare.

         Since you mentioned the DAD loss again, I am happy to let you know 
that in
        the new verison of CPS-01,
         no only DAD is used, but also the  unsolicited NA and NS to resovle 
the
       address, based on the suggestion from Eric Levy-Abegnoli. As he 
stated and
        we agreed, "the odds of getting none of them are extremely low." You
       questions helped us to improve the CPS, so thank you very much. I am 
happy
       because so far the CPS is still a low cost solution to makes the low 
end
       access switch (as low as 200-300USD per switch as we will demo on 
Thursday)
       easy to implement CPS.

       There is another way could be consdiered to enhace the reliability of 
DAD.

    In RFC4862.

    One possible way is to ask the value of  DupAddrDetectTransmits  for
    SAVI client to change t to a value of 2 or greater than 2 (then loss 
possiblity will be really
   lowered). It's not a heavy effort like to design a reliable BDP.

   Best Regards,
 Jun Bi

         Hi Eric,
        I just replyed you the port type of CPS in my last email.
        Please take a look at those port attributes defined.
       different logic are designd by different type of ports.
        I believe CPS will handle the case you mentioned.

       However, in FCFS, the swtich reboot will cause serious problems.

         thanks,
         Jun Bi

Erik

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Tue, 28 Jul 2009 21:45:33 +0200

Erik Nordmark a écrit :
>>> *IF* SLAAC is permitted, then by definition the host can pick 
>>> whatever address it wants. DAD as defined is not a reliable 
>>> protocol, thus pretending it is the way a host *registers* a SLAAC 
>>> address makes no sense. For instance, if 802.1D bridges wait for 30 
>>> seconds before enabling a Ethernet port, then no DAD packet would be 
>>> seen on the network.
>>>
>>> registered addresses then SLAAC can not be used; DHCPv6 would need 
>>> to be used as the assignment/registration protocol.
>>>
Did you read "reliably established"? None, so? We can spend years 
solving a problem that is a completely theoritical problem in most 
environments. Or we can try to do with what we have.
DAD is theoritically broken. I mean DAD, no savi. If your DAD packet is 
lost, you never know that your address is duplicate. - in theory, it 
could be- *exactly* in the case that you describe below, you don't know 
neither. Does that prevent node to test duplicate in most cases? no.
It would be great to have a declarative reliable protocol. Not sure we 
need yet another one though. InverseND would do. But the truth is, 
getting anything like this into the host is going to take a decade, and 
only if there is a buyout. I find the charter very wise from that 
regard: no new protocol allowed.
 
>
>> In a sense, it's not very different from RPF. If you don't have a 
>> return path to it, it is suspicious. Not broken because the nexthop 
>> will do address resolution on the reverse path, but suspicious 
>> because bindings are announced in a fairly redundant way (DAD * n, 
>> NA, NS*3)
>
One DAD is the default,.certainly not a MUST. So I don't see anything 
wrong in recomemnding to use a higher value in a savi setup. As fas as 
using more than DAD, well, it's still opened, isn't it?
>> forward a host traffic. And then it's a matter of policy: Your 
>> example is the one of a non-savi switch (your 802.1D bridge) 
>> connected to a savi switch. The policy could be to forward by default 
>> in this case.
>
> SAVI switch I don't think we want to completely disable SAVI; that 
> would severely limit the utility of SAVI (and I really want to see 
> SAVI enabled by default everywhere) in common topologies. For instance 
I am not ruling that out. But a non-savi switch, not doing 
authentication at layer2, connected to a savi switch is the hard case. I 
would not pre-req solving it to make progress on the other cases.
Eric