Subject: Re: [savi] AD review of draft-ietf-savi-fcfs

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 13 Oct 2011 17:13:29 +0200

Hi Jari,

Please find the replies below marked with MB>

El 04/05/11 20:41, Jari Arkko escribió:
> I have reviewed this draft. The specification is well written, and 
> while it took an entire day for me to be (relatively) convinced that 
> the state machine is correct, it is easy to read.
>
> I have sent the draft forward to an IETF last call. However, I did 
> have a few suggestions and questions that I hope you can treat and if 
> needed, issue a new draft version.
>
>> Neighbour Solicitation (NSOL)
>> and Neighbour Advertisement (NADV) messages
>
> Can we use the usual abbreviations, NS and NA?
>
MB> Done

>> Router Advertisement: A SAVI device MUST support discovery of on-link
>> prefixes through Router Advertisement messages.  The SAVI device will
>> learn the on-link prefixes following the procedure defined for a host
>> to process the Prefix Information options described in section 6.3.4
>> of [RFC4861] <http://tools.ietf.org/html/rfc4861#section-6.3.4> with 
>> the difference that the prefixes will be configured
>> in the FCFS SAVI Prefix List rather than in the ND Prefix List.  In
>> addition, when the SAVI device boots, it MUST send a Router
>> Solicitation message as described in section 6.3.7 of [RFC4861] 
>> <http://tools.ietf.org/html/rfc4861#section-6.3.7>,
>> using the unspecified source address.
>
> Will this process be run on all ports, or just the trusted ones? 
> Please specify.
>
MB> Only the trsuted ones. I have added a sentence clarifying that.

>> o  If the data packet is received through a Validating port, then the
>>    SAVI function checks whether the received data packet is local
>>    traffic or transit traffic.  It does so by verifying if the source
>>    address of the packet belongs to one of the directly connected
>>    prefixes available in the receiving interface.  It does so by
>>    searching the FCFS SAVI Prefix List.
>>    *  If the IP source address does not belong to one of the local
>>       prefixes of the receiving interface, this means that the data
>>       packet is transit traffic and the packet SHOULD be discarded.
>
> You need to add a special case for supporting the unspecified address.
>
MB> Right, i have added the following text:

<t>If the source address of the packet is the unspecified address, the 
packet is forwarded and no SAVI processing is performed except for the 
case of the Neighbor Solicitation messages involved in the Duplicate 
Address Detection which are treated as described in <xref target="local" 
/>.</t>

>> This may due to an attack or to the fact that the host
>> may have moved. 
>
> ... may be due to an ...

MB> done
>
>
>> and 250 millisconds later
>
> Milliseconds. And please put the value to a constant in a separate 
> section.
>

MB> Done
>> The DAD_NSOL messages are sent
>> through the proper Trusted Ports (as defined by the switch
>> behaviour that will depend on whether it performs MLD snooping or
>> not). 
>
> The word "proper" is confusing here. How about this text instead:
>
> The DAD_NSOL messages are sent through Trusted Ports (but of course 
> subject to usual switch behavior and possible MLD snooping 
> optimizations).
>
MB> Done (in all the instances fo that expression)

>> the SAVI device MUST forward the NSOL and 250
>> millisconds later it MUST execute the process of sending Neighbour
>> Solicitation messages
>
> This could be clearer. First, you forward the NSOL completely 
> normally. Then you separately run the NS process *on behalf of the 
> host*, but forward these NSOL messages only to TP ports. Correct?
>
> A couple of questions, however. What's the source MAC address in such 
> packets, the host's or the switch's address? And why aren't you simply 
> copying the same message, separated by X ms? Finally, are you 
> forwarding one message and generating two copies, altogether three 
> messages?
>
> Additional clarity here would be useful.
>

MB> The savi basically sends the DAD MS message twice, the original one 
and a copy after 250ms.
I have rewritten this to be clearer as follows:

<t>Upon the reception through a Validating Port (VP) of a Neighbour 
Solicitation (NS) generated by the Duplicate Address Detection (DAD) 
procedure (hereafter named DAD_NS) containing Target Address IPAddr, the 
SAVI device MUST forward the NS and T_WAIT millisconds later it MUST 
send a copy of the same message.
These DAD_NS messages are not sent through any of the ports configured 
as Validating Ports. The DAD_NS messages are sent through the Trusted 
Ports (but of course subject to usual switch behavior and possible MLD 
snooping optimizations).

Is this clearer now?

>> o  DAD_NSOL packets containing IPAddr as the target address received
>>    through a Trusted port are NOT forwarded through any of the
>>    Validating ports but they are sent through the proper Trusted
>>    Ports (as defined by the switch behaviour that will depend on
>>    whether it performs MLD snooping or not)
>
> I don't understand why these  messages are only forwardded to the TPs.
>

MB>BEcause doing so would enable a hostile host to claim ownership on an 
address that someone else is actually already using.
I mean, the DAD_NS can be generated by the SAVI device upon the 
recpetion of a data packet for whcih there is no binding. If we allow 
any host connected to any port to reply, then any host could steal the 
address.  Of course, if there is a binding, the state for this address 
would not be NO-BIND and in the VALID state these packets are forwarded 
to the port where the rightful owner of the address is attached to so it 
can defend its address.

MAkes sense?

>> o  Neighbor Advertisement packets sent to all nodes as a reply to the
>>    DAD_NSOL (hereafter called DAD_NADV) containing IPAddr as the
>>    target address coming through a Validating port are discarded.
>
> This seems to break the principle of SAVI not changing network 
> behavior except where a delay is necessary while you verify something. 
> Why is it necessary to not forward these messages as they normally are 
> forwarded through the network?
>

MB> this happens in No_BIND state. This means that the sender is not the 
owner of the address, because there is no binding for that address. So 
sending a NA for that address from an authorized host replying to a 
DAD_NS is a host that didn't own the address originally, trying to 
prevent someone else to configure it. Moreover, since this NS may have 
been geenrated by the SAVI device as a result of receiving a data packet 
for which there is no binding, it may well be the case tat host is 
already using the address in question. So blocking this address is 
needed to prevent the attacker to claim ownership of an anddres that is 
currently being used by some other host. (This is related to the case above)

Makes sense?

>> So, when SEND is deployed, it is recommended to use SEND SAVI
>> [I-D.ietf-savi-send 
>> <http://tools.ietf.org/html/draft-ietf-savi-fcfs-09#ref-I-D.ietf-savi-send>] 
>> rather than FCFS SAVI."
>
> Is there some reason why proxy SEND cannot be employed here?
>

MB> I will let Alberto to reply this one.

Regards, marcelo

> Jari

---

From: Jean-Michel Combes <[email-masked]>
Date: Thu, 13 Oct 2011 17:42:01 +0200

Hi,

> El 04/05/11 20:41, Jari Arkko escribió:

[snip]

> MB> I will let Alberto to reply this one.

This text comes from my review as shepherd of this document.

As proxy SEND doesn't permit to check the validity of SENDized ND
exchanges, IMHO, proxy SEND cannot be used easily.

Best regards.

JMC.

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

---

From: Jean-Michel Combes <[email-masked]>
Date: Thu, 13 Oct 2011 17:57:26 +0200

Sorry, in fact, proxy SEND checks validity of SENDized ND exchanges
(draft-ietf-csi-proxy-send-05, section 5.2.1, 1.B). So, proxy SEND
could be used but:
- proxy SEND requires hosts, in the network, are compliant with proxy SEND
- proxy SEND is not "transparent" and so SAVI device will lose its
"invisibility" feature
- proxy SEND requires many actions (certificate management, IP packet
modification, etc) and I am not sure that SAVI device will be able to
do this as in common use cases the SAVI device is a L2 device.
- proxy SEND would need an API with FCFS SAVI

Best regards.

JMC.

---

From: Alberto García <[email-masked]>
Date: Fri, 14 Oct 2011 17:26:13 +0200

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
|  Jean-Michel Combes
|  Enviado el: jueves, 13 de octubre de 2011 17:57
|  Para: marcelo bagnulo braun
|  CC: [email-masked]; SAVI Mailing List
|  Asunto: Re: [savi] AD review of draft-ietf-savi-fcfs
|  
|  Sorry, in fact, proxy SEND checks validity of SENDized ND exchanges
(draft-
|  ietf-csi-proxy-send-05, section 5.2.1, 1.B). So, proxy SEND could be used
but:
|  - proxy SEND requires hosts, in the network, are compliant with proxy
SEND

Yes. We should assume the following scenario (scenario #1): a link in which
all receivers are capable of processing proxy SEND messages (aka 'SPND
nodes'), and nodes either generate SEND or Proxy SEND messages.

|  - proxy SEND is not "transparent" and so SAVI device will lose its
|  "invisibility" feature

I don't understand this. 
Maybe you are thinking about a different deployment scenario to the one I
commented above, an alternative way of 'mixing' SAVI and proxy SEND, in
which SAVI devices would act as Proxy SEND devices for non-SEND nodes
(scenario #2). 
I think this is a bad idea, because it provides without reason the same
confidence to SEND and non-SEND devices, and I'm sure that this is not what
we want to do. In the examples shown in the Proxy SEND draft, there is a
strong security link between the Proxy SEND device and the proxied nodes.

|  - proxy SEND requires many actions (certificate management, IP packet
|  modification, etc) and I am not sure that SAVI device will be able to do
this
|  as in common use cases the SAVI device is a L2 device.
In scenario #1, SAVI devices only validate Proxy SEND messages. They only
need to have the same capabilities of SPND nodes. So this features you
comment are not needed.
I think adding proxy SEND validation to SEND SAVI would be quite simple, and
without much trouble.

Makes sense?
If the answer is 'yes', then 
- I could add some comment on Proxy SEND in the SEND SAVI document
- A line in the fcfs-savi document such as the current 'So, when SEND is
deployed, it is recommended to use SEND SAVI' (or could be also this
alternative text 'So, when SEND or Proxy SEND is deployed, it is recommended
to use SEND SAVI') sounds ok to me.

Regards,
Alberto

|  - proxy SEND would need an API with FCFS SAVI
|  
|  Best regards.
|  
|  JMC.
|  
|  2011/10/13 Jean-Michel Combes <[email-masked]>:
|  > Hi,
|  >
|  > 2011/10/13 marcelo bagnulo braun <[email-masked]>:
|  >> Hi Jari,
|  >>
|  >> Please find the replies below marked with MB>
|  >>
|  >>
|  >> El 04/05/11 20:41, Jari Arkko escribió:
|  >>>
|  >
|  > [snip]
|  >
|  >>
|  >>>> So, when SEND is deployed, it is recommended to use SEND SAVI
|  >>>> [I-D.ietf-savi-send
|  >>>> <http://tools.ietf.org/html/draft-ietf-savi-fcfs-09#ref-I-D.ietf-sa
|  >>>> vi-send>]
|  >>>> rather than FCFS SAVI."
|  >>>
|  >>> Is there some reason why proxy SEND cannot be employed here?
|  >>>
|  >>
|  >> MB> I will let Alberto to reply this one.
|  >
|  > This text comes from my review as shepherd of this document.
|  >
|  > As proxy SEND doesn't permit to check the validity of SENDized ND
|  > exchanges, IMHO, proxy SEND cannot be used easily.
|  >
|  > Best regards.
|  >
|  > JMC.
|  >
|  >>
|  >> Regards, marcelo
|  >>
|  >>
|  >>> Jari
|  >>>
|  >>>
|  >>
|  >>
|  >> _______________________________________________
|  >> 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: Jean-Michel Combes <[email-masked]>
Date: Tue, 18 Oct 2011 20:11:30 +0200

Hi,

> nodes'), and nodes either generate SEND or Proxy SEND messages.

Agree.

> |  - proxy SEND is not "transparent" and so SAVI device will lose its

With proxy SEND, the nodes know there is a proxy SEND entity (based on
the Proxy Signature Option), that could act as SAVI device too (i.e.,
an useful information for a potential attacker).
With SEND SAVI, IIRC, the SAVI device is not visible for the nodes on
the link (as the SAVI device uses SENDized NUD messages, it looks like
to a common SEND node).

> which SAVI devices would act as Proxy SEND devices for non-SEND nodes

no no, cf. above :)

> I think adding proxy SEND validation to SEND SAVI would be quite simple, and

I think you (or is it me? :)) missed the point from Jari: from what I
understood, Jari's question is "Is it possible to use proxy SEND
(combined with FCFS SAVI) instead of SEND SAVI?".
Jari, confirmation?

Best regards,

JMC.