Subject: [savi] dealing with topology changes in dhcp savi

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 09 Mar 2010 08:51:03 +0100

Hi,

I have another question about dhcp save

How do you handle the following situation?

    In the case SAVI is being deployed in a switched Ethernet network,
    topology changes may result in a SAVI device receiving packets from a
    legitimate user for which the SAVI device does not have a binding
    for.  Consider the following example:

           +------+             +--------+       +---------------+
           |SAVI I|-------------|SWITCH I|-------|rest of the net|
           +------+             +--------+       +---------------+
              |                    |
              |                 +--------+
              |                 | SAVI II|
              |                 +--------+
              |   +----------+     |
              +---|SWITCH II |-----+
                  +----------+
                      |
                   +-----+
                   | Host|
                   +-----+

    The DHCP server is located in the part called rest of the network.
    Suppose that after bootstrapping all the elements are working
    properly and the spanning tree is rooted in the router and it
    includes one branch that goes SWITCH I-SAVI I- SWITCH II and another
    branch that goes SWITCH I-SAVI II.

    Suppose that the Host boots at this moment and perfomrs the DHCP sxchange.
    The message is propagated through the spanning tree and it received
    by SAVI I but not by SAVI II. Same happens with the reply.
    SAVI I creates the binding.

    Suppose that SAVI I fails and the spanning tree reconverges to SWITCH
    I- SAVI II- SWITCH II.  Now data packets coming from the Host will be
    coursed through SAVI II which does not have binding state and will
    drop the packets.

Regards, marcelo

---

From: "Bi Jun" <[email-masked]>
Date: Tue, 9 Mar 2010 18:47:45 +0800

Hi Marcelo,

Since you are entitled "topology change", I want to say sth.
Based on our operational experience, if we do a planed topology change,
then we have to plan we will have more serious problem than this.
So topology change in an operational network is usually carefully planed.
We don't do it very often, and once we do it, we will let users understand 
us.

So I don't see a problem of planed topology change. The only thing is the 
power-down
of a switch, which is really a low frequency event in an operational 
network. If we found the power down, we will also inform users (only users 
under that switch will be affected, not all users will be affect) that if 
you had any problem thank you please renew your connection.

thanks,
Jun Bi

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Tuesday, March 09, 2010 3:51 PM
To: "SAVI Mailing List" <[email-masked]>
Subject: [savi] dealing with topology changes in dhcp savi

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Mar 2010 13:09:38 +0100

Hi Jun,

sorry for the delay, i was away for a few days.

Ok, let me rephrase my question then.

Suppose that you have the topology that is depicted below,
with multiple redundant switches to benefit from robustness.
My point is that the introduction of SAVI that is unable to
cope with data packets for which there is no binding will
reduce the robustness of the network, even if network
has been designed to be redundant.

    In the case SAVI is being deployed in a switched Ethernet network,
    failures in a single device changes may result in a SAVI device
    receiving packets from a
    legitimate user for which the SAVI device does not have a binding
    for.  Consider the following example:

    Suppose that the Host boots at this moment and perfomrs the DHCP 
sxchange.
    The message is propagated through the spanning tree and it received
    by SAVI I but not by SAVI II. Same happens with the reply.
    SAVI I creates the binding.

Comments?

Regards, marcelo

El 09/03/10 11:47, Bi Jun escribió:
> We don't do it very often, and once we do it, we will let users 
> understand us.
>
> So I don't see a problem of planed topology change. The only thing is 
> the power-down
> network. If we found the power down, we will also inform users (only 
> users under that switch will be affected, not all users will be 
> affect) that if you had any problem thank you please renew your 
> connection.
>
> thanks,
> Jun Bi
>

---

From: "Bi Jun" <[email-masked]>
Date: Mon, 15 Mar 2010 20:26:56 +0800

Hi Marcelo,

We can guide the users in this document or in framework,
if you want to put a hub between savi-device or your host, please buy an 
more expensive savi-device that implemented the xxx options functions (e.g 
the data triggered functions listed in savi-dhcp-02, or another solution 
document).

thanks,
Jun

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Monday, March 15, 2010 8:09 PM
To: "Bi Jun" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Subject: the impact of SAVI in the overall network robustness (was Re: 
[savi] dealing with topology changes in dhcp savi

>> users under that switch will be affected, not all users will be affect) 
>> that if you had any problem thank you please renew your connection.
>>
>> thanks,
>> Jun Bi
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Mar 2010 14:54:44 +0100

So, if you do discard the packets for which there is no binding, the 
overall network robustness is worse, in particular settings where a 
redundant topology has been set.

This seems quite severe to me.

Regards, marcelo

El 15/03/10 13:26, Bi Jun escribió:
> if you want to put a hub between savi-device or your host, please buy 
> an more expensive savi-device that implemented the xxx options 
> functions (e.g the data triggered functions listed in savi-dhcp-02, or 
> another solution document).
>
> thanks,
> Jun
>
>>> So I don't see a problem of planed topology change. The only thing 
>>> is the power-down

---

From: "Bi Jun" <[email-masked]>
Date: Mon, 15 Mar 2010 22:28:07 +0800

I meant please in the guideline, says that your host SHOULD be directly plug 
to the savi-device.
If not, please purchase an higher-end savi-device that implemented the 
options.

thanks,
Jun

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Monday, March 15, 2010 9:54 PM
To: "Bi Jun" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Subject: Re: the impact of SAVI in the overall network robustness (was Re: 
[savi] dealing with topology changes in dhcp savi

>> more expensive savi-device that implemented the xxx options functions 
>> (e.g the data triggered functions listed in savi-dhcp-02, or another 
>> solution document).
>>
>> thanks,
>> Jun
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Mar 2010 15:55:46 +0100

El 15/03/10 15:28, Bi Jun escribió:
> I meant please in the guideline, says that your host SHOULD be 
> directly plug to the savi-device.

this is not how the SHOULD work for the specification since this is not 
somehting the protocol MUST/SHOULD implement.

The MUST/SHOULD affects the protocol extensions and not the 
configurations where you use it
The configurations where you use safely or not are the qualification of 
the SHOULD

Regards, marcelo

> Subject: Re: the impact of SAVI in the overall network robustness (was 
> Re: [savi] dealing with topology changes in dhcp savi
>
>>> if you want to put a hub between savi-device or your host, please 
>>> buy an more expensive savi-device that implemented the xxx options 
>>> functions (e.g the data triggered functions listed in savi-dhcp-02, 
>>> or another solution document).
>>>
>>> thanks,
>>> Jun
>>>
>>> Subject: the impact of SAVI in the overall network robustness (was 
>>> Re: [savi] dealing with topology changes in dhcp savi
>>>
>>>> Hi Jun,
>>>>
>>>>> of a switch, which is really a low frequency event in an 
>>>>> operational network. If we found the power down, we will also 
>>>>> inform users (only users under that switch will be affected, not 
>>>>> all users will be affect) that if you had any problem thank you 
>>>>> please renew your connection.
>>>>>
>>>>> thanks,
>>>>> Jun Bi
>>>>>

---

From: "Bi Jun" <[email-masked]>
Date: Mon, 15 Mar 2010 22:59:56 +0800

I think everything has it's working condition.
The guideline is part of the RFC to discuss the condition.
For more discussion, please see my another replied email.

thanks,
Jun

Sent: Monday, March 15, 2010 10:55 PM

>> I meant please in the guideline, says that your host SHOULD be directly 
>> plug to the savi-device.
>
> The MUST/SHOULD affects the protocol extensions and not the configurations 
> where you use it

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Mar 2010 11:11:33 -0400

We can write an applicability statement that captures some of this. 
But, for this problem, I don't think it will help.  Given that the 
protocol needs to cover all cases, and the protocol machinery can not 
tell which case it is in, then you can't write a SHOULD about it.

(That is one of the interesting properties of the spanning tree case 
Marcelo raised.  it is detectable.  The device can complain about 
inappropriate usage if it actually sees spanning tree coming from a 
place it is not prepared to cope with.)

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Mar 2010 11:14:23 -0400

I realized after sending this that it was not as clear as I would like. 
  One can write SHOULD statements that are not protocol detectable.  If 
they are at least controllable by the implementor.  Marcelo has argued 
cogently that not even the deployer can reliably know if this condition 
is actually being met.  (Which, for the DHCP case, makes storing state 
in NVRAM a very sensible behavior.)

Yours,
Joel

Joel M. Halpern wrote:
> We can write an applicability statement that captures some of this. But, 
> for this problem, I don't think it will help.  Given that the protocol 
> needs to cover all cases, and the protocol machinery can not tell which 
> case it is in, then you can't write a SHOULD about it.
> 
>> this is not how the SHOULD work for the specification since this is 
>> not somehting the protocol MUST/SHOULD implement.
>>
>> The configurations where you use safely or not are the qualification 
>> of the SHOULD
>>
>> Regards, marcelo
>>
>>> If not, please purchase an higher-end savi-device that implemented 
>>> the options.
>>>
>>> thanks,
>>> Jun
>>>
>>> Subject: Re: the impact of SAVI in the overall network robustness 
>>> (was Re: [savi] dealing with topology changes in dhcp savi
>>>
>>>>>>> So I don't see a problem of planed topology change. The only 
>>>>>>> thing is the power-down

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Mar 2010 16:14:24 +0100

Right, this is the applicability of the protocol and does not affect the 
normative language of the spec.

El 15/03/10 15:59, Bi Jun escribió:
>>>> So, if you do discard the packets for which there is no binding, 
>>>> the overall network robustness is worse, in particular settings 
>>>> where a redundant topology has been set.
>>>>
>>>>> functions (e.g the data triggered functions listed in 
>>>>> savi-dhcp-02, or another solution document).
>>>>>
>>>>> thanks,
>>>>> Jun
>>>>>

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 15 Mar 2010 23:19:12 +0800

then you meant all of those functions will be "SHOULD", then state in the 
applicability section in this rfc?

thanks,
Jun Bi

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Monday, March 15, 2010 11:14 PM
To: "Bi Jun" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Subject: Re: [savi] the impact of SAVI in the overall network robustness 
(was Re: dealing with topology changes in dhcp savi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Mar 2010 16:52:46 +0100

mmm, not sure if i understand exactly what you mean, but i think yes

We need to decide which features are MUST and which ones are should.
then we need to  qualify the SHOULDs, which can be complemented by an 
applicability statement.

So, for the dhcp savi case, i can live with including the feature of 
triggering the binding creation process upon the reception of data 
packets as a should and then qualify it by describing what it would 
break if this is not implemented and what configurations would have 
suffer less problems

regards, marcelo

El 15/03/10 16:19, Jun Bi escribió:
> then you meant all of those functions will be "SHOULD", then state in 
> the applicability section in this rfc?
>
> thanks,
> Jun Bi
>
> Subject: Re: [savi] the impact of SAVI in the overall network 
> robustness (was Re: dealing with topology changes in dhcp savi
>
>> Right, this is the applicability of the protocol and does not affect 
>> the normative language of the spec.
>>
>>
>>
>>>> The configurations where you use safely or not are the 
>>>> qualification of the SHOULD
>>>>
>>>> Regards, marcelo
>>>>
>>>>>>> if you want to put a hub between savi-device or your host, 
>>>>>>> please buy an more expensive savi-device that implemented the 
>>>>>>> xxx options functions (e.g the data triggered functions listed 
>>>>>>> in savi-dhcp-02, or another solution document).
>>>>>>>
>>>>>>> thanks,
>>>>>>> Jun
>>>>>>>
>>>>>>> Subject: the impact of SAVI in the overall network robustness 
>>>>>>>>> We don't do it very often, and once we do it, we will let 
>>>>>>>>> users understand us.
>>>>>>>>>
>>>>>>>>> inform users (only users under that switch will be affected, 
>>>>>>>>> not all users will be affect) that if you had any problem 
>>>>>>>>> thank you please renew your connection.
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>> Jun Bi
>>>>>>>>>

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 15 Mar 2010 17:08:24 +0100

> break if this is not implemented and what configurations would have 
I would strongly oppose to a SHOULD if the technique implies the switch 
to be a L3 device (see my point on sourcing DHCP messages). That would 
not be constraining the device capabilities (which to me would be more 
acceptable) but rather the deployment model. And that is bogus.
Eric
>>>>> this is not how the SHOULD work for the specification since this 
>>>>> is not somehting the protocol MUST/SHOULD implement.
>>>>>
>>>>>> If not, please purchase an higher-end savi-device that 
>>>>>> implemented the options.
>>>>>>
>>>>>> thanks,
>>>>>> Jun
>>>>>>

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Mar 2010 09:41:59 +0200 (EET)

On Mon, 15 Mar 2010, Joel M. Halpern wrote:
> I realized after sending this that it was not as clear as I would like.  One 
> can write SHOULD statements that are not protocol detectable.  If they are at 
> least controllable by the implementor.  Marcelo has argued cogently that not 
> even the deployer can reliably know if this condition is actually being met. 
> (Which, for the DHCP case, makes storing state in NVRAM a very sensible 
> behavior.)

FWIW, I agree with Marcelo's and Joel's point here.  As an operator, I 
would not be very comfortable deploying a solution that described lack 
of robustness in the scenario Marcelo described.  As a user, I would 
be strongly opposed if e.g. an ISP would deploy such network 
robustness degrading mechanism.  As a participant in telecom 
regulation, I would be pushing for regulations which disallow ISPs 
from deploying mechanisms like these in the customer front.

-- 
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: "Jun Bi" <[email-masked]>
Date: Tue, 16 Mar 2010 16:11:34 +0800

Hi Pekka,

Thank you for your comment.

Did you see Fred Baker's comment?

By the way, maybe, you might misunderstood Joel's opinion.

thanks,
Jun Bi

--------------------------------------------------
From: "Pekka Savola" <[email-masked]>
Sent: Tuesday, March 16, 2010 3:41 PM
To: "Joel M. Halpern" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Subject: Re: [savi] the impact of SAVI in the overall network robustness 
(was Re: dealing with topology changes in dhcp savi

>> is actually being met. (Which, for the DHCP case, makes storing state in 
>> NVRAM a very sensible behavior.)
>
> would not be very comfortable deploying a solution that described lack of 
> robustness in the scenario Marcelo described.  As a user, I would be 
> strongly opposed if e.g. an ISP would deploy such network robustness 
> degrading mechanism.  As a participant in telecom regulation, I would be 
> pushing for regulations which disallow ISPs from deploying mechanisms like 
> these in the customer front.
>
> --

---

From: Fred Baker <[email-masked]>
Date: Tue, 16 Mar 2010 06:57:51 -0400

If this is the lack of robustness you're talking about, then I would have to agree with Jun that having the switch re-check the DHCP binding with the DHCP server gets it the information it needs. It drops packets for a period measured in hundreds to thousands of milliseconds while the situation is sorted out, but I doubt you would see a TCP session loss from this alone.

I'm afraid we don't see your concerns in the field.

On Mar 15, 2010, at 8:09 AM, marcelo bagnulo braun wrote:

>> We don't do it very often, and once we do it, we will let users understand us.
>> 
>> So I don't see a problem of planed topology change. The only thing is the power-down
>> of a switch, which is really a low frequency event in an operational network. If we found the power down, we will also inform users (only users under that switch will be affected, not all users will be affect) that if you had any problem thank you please renew your connection.
>> 
>> thanks,
>> Jun Bi
>> 

http://www.ipinc.net/IPv4.GIF

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 Mar 2010 17:28:29 +0100

Hi Fred,

El 16/03/10 11:57, Fred Baker escribió:
> If this is the lack of robustness you're talking about,

This is one of the cases of reduced robustness, the other is the usage 
of stalled information (but can be dealt with the same approach as this 
one that you mention below)

>   then I would have to agree with Jun that having the switch re-check the DHCP binding with the DHCP server gets it the information it needs.
So, you mean that upon the reception of a packet for which the dhcp SAVI 
device has no binding, the dhcp savi device must retrieve the binding 
information from the dhcp server (in case there is one)?

I agree that that would address the issue and would imply a lost of 
packets that is negligible.

regards, marcelo

>   It drops packets for a period measured in hundreds to thousands of milliseconds while the situation is sorted out, but I doubt you would see a TCP session loss from this alone.
>
>>> From: "marcelo bagnulo braun"<[email-masked]>
>>> To: "SAVI Mailing List"<[email-masked]>

---

From: Fred Baker <[email-masked]>
Date: Tue, 16 Mar 2010 12:29:46 -0500

On Mar 16, 2010, at 11:28 AM, marcelo bagnulo braun wrote:

> So, you mean that upon the reception of a packet for which the dhcp SAVI device has no binding, the dhcp savi device must retrieve the binding information from the dhcp server (in case there is one)?

If we're talking about a switch in a transit configuration - a switch that the host in question is not directly connected to - I see no reason to assume that the switch is protecting that host. It could be configured to (eg the case of a major switch connected to a non-SAVI desktop switch), but even there it would be preferable for the desktop switch to protect its own ports. 

If we're talking about a switch protecting its own ports, yes, it needs to somehow get the information restored. One way to do so would be to send a DHCP request to the server as if from the host in question.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 Mar 2010 20:17:02 +0100

> If we're talking about a switch in a transit configuration - a switch that the host in question is not directly connected to - I see no reason to assume that the switch is protecting that host. It…
I am not sure i understand the terminology.

So, as they say, one picture...

I am talking about this configuration

+---------------+
|Rest of the net|
+---------------+
      |
+------+
|SAVI  |
+------+
      |
+-------------+
|Legacy switch|
+-------------+
      |
+------+
|host  |
+------+

In this case, the SAVI is enforcing that the addresses used by the host 
come from the port through which the legacy switch is connected to.
The problem is when the savi switch looses its state and start 
discarding the packets from the host after that

The solution i understand you describe (making the SAVI device to query 
the dhcp server upon the reception of a data packet for which it has no 
binding) would address this problem and solve the robustness concerns

Are we talking about the same thing?

Regards, marcelo

---

From: Fred Baker <[email-masked]>
Date: Tue, 16 Mar 2010 16:01:07 -0400

On Mar 16, 2010, at 3:17 PM, marcelo bagnulo braun wrote:

> In this case, the SAVI is enforcing that the addresses used by the host come from the port through which the legacy switch is connected to.
> The problem is when the savi switch looses its state and start discarding the packets from the host after that
> 
> The solution i understand you describe (making the SAVI device to query the dhcp server upon the reception of a data packet for which it has no binding) would address this problem and solve the robustness concerns
> 

I imagine so. The legacy switch in this case is one of two things - a desktop four or 8 port "port extension", which doesn't worry me much, or a bazillion-port monster. In the latter case, I wouldn't automatically assume that the SAVI switch had enough memory to protect its ports. As a vendor, I would tell my customer that rather than adding an inter-switch protocol and a ton of memory to the SAVI switch, they would do better if they upgraded the legacy switch.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 Mar 2010 21:20:01 +0100

> I imagine so. The legacy switch in this case is one of two things - a desktop four or 8 port "port extension", which doesn't worry me much, or a bazillion-port monster. In the latter case, I wouldn…

makes perfect sense to me

i do agree that the deployment considerations should make some referecne 
about the amount of devices that can be hanging from a SAVI device, as 
you mention (i am not very sure how to write that down, but i guess we 
will give it a try and see what happens)

Regards, marcelo

---

From: "Guang Yao" <[email-masked]>
Date: Wed, 17 Mar 2010 16:55:46 +0800

Hi folks,

   In stateless scenario, nodes can "assign" address to themselves, and
   perform unreliable duplicate detection to check whether the address
   is being used. For IPv6 address, collision happens with very little
   probability because of large address space, thus the unreliable
   nature of DAD is not serious in reality. However, the unreliability
   of DAD troubles source address validation. It is very hard, if not
   impossible, for a SAVI device to determine which node can use one
   address when conflict happens.

   A wise principle, "First Come First Served" is currently used by
   SAVI-FCFS to determine ownership of address. This principle is
   correct, however, the problem is, how to determine which node is the
   first to use an address. Because the unreliable nature of DAD, the
   first one assigned itself an address, may not be the one first using
   the address to send traffic sniffed by the SAVI device. SAVI-FCFS
   requires device to send detection probes to determine whether an
   address is being used by another node. However, this effort may be
   vain, because malicious node can reply any probe, and the probe is
   still unreliable to reach the possible target node.

   After a long time attempt, we finally find that because of the
   unreliability of DAD and ND, there is no perfect arbitration policy.
   In another word, if a arbitration policy is perfect, it must rely on
   a reliable DAD. We can prove this through a simple deduction:

   Perfect arbitrate=>

   The one having assigned itself an address first gets the ownership of
   the address=>

   The one having performed DAD first gets the address=>

   The arbitrator must know who is the first to perform DAD=>

   The DAD must be reliable to be sniffed by the SAVI device.

   And the deduction can be reversed.

   In the end, we found we were building tower on the quick sand. It
   concerns nothing about whether choosing data trigger or control
   packet trigger. Unless stateless assignment changes to be reliable,
   no solution can be secure.

   In the attached document, we decide to follow RFC4862, which is the only
   stand track on stateless address assignment. This means, if a node
   finishes a successful DAD, including the DAD is performed by SAVI
   device in case of data trigger, the address MUST be bound with it.
   Then the ownership conflict is actually handled through allowing one
   address to be bound with multiple anchors. The bindings are only
   removed when the lifetime expires, which equals prefix life time
   learned from RA. Then we achieve a simple solution, whose security is
   based on the reliability of RFC4862.

   (The doc in the attachment is not used to challenge current solution, but
used to help discuss on this topic.)

	Thanks to any comment.

BR,
Guang