Re: [savi] SAVI device configuration with prefixes

--------------------------------------------------
From: "Christian Vogt" <christian.vogt@ericsson.com>
Sent: Saturday, June 26, 2010 1:43 AM
To: "Jean-Michel Combes" <jeanmichel.combes@gmail.com>
Cc: "Lin Tao" <lint@h3c.com>; "Guang Yao" <yaoguang.china@gmail.com>; "SAVI 
Mailing List" <savi@ietf.org>
Subject: Re: [savi] SAVI device configuration with prefixes

> Jean-Michel,
>
> two comments:
>
> - You are right that the SAVI For SLAAC document already includes the
>  notion of a prefix table, but it currently does not tell how this
>  table gets populated.  The assumption is manual configuration, of
>  course.  But either this should be mentioned explicitly, or we
>  should add a mechanism for automatic prefix table population based
>  on Router Advertisement messages.  Of these two options, I am
>  personally in favor of the latter, because it reduces configuration
>  complexity and, hence, the risk for configuration errors.
>
> - If the working group adopts automatic prefix table population based on
>  Router Advertisement messages, then this mechanism would indeed have
>  to be protected against spoofing.  One, in my opinion feasible, way
>  to do this is by configuring SAVI devices with respect to which
>  ports connect to first-hop routers.  This would be a mechanism
>  analogous to the configuration of SAVI-For-DHCP devices with respect
>  to which ports connect to DHCP servers.

Hi Christian,

Please note that the port type "RA-Trust" was already proposed in 
draft-bi-savi-stateless-00/01. As I reported, this draft had been 
implemented by vendors joint CNGI-CERNET2 SAVI deployment project. So this 
"RA-Trust" port was ALREADY implemented by vendors and deployed in 
CNGI-CERNET2. Tsinghua University just did conformance testing for savi 
switches from 3Com, ZTE, Ruijie, and Digital China on this function in March 
and April.

Best Regards,
Jun Bi

10. Anchor Attributes

   This section specifies the anchor attributes involved in this
   mechanism.

   Anchor is defined in the [savi-framework]. Attribute of each anchor
   is configurable. In default, anchor has no attribute. An anchor MAY
   be configured to have one or more compatible attributes. However, an
   anchor MAY have no attribute.

   If an anchor has no attribute, in this solution, Router Advertisement
   message from this anchor MUST be dropped. However, other packets
   SHOULD NOT be dropped.

10.2. SAVI-RA-Trust Attribute

   If and only if an anchor is associated with a trustable router, it
   SHOULD be set to have this attribute.

   On a SAVI device enabled this solution, there may be no anchor with
   this attribute. This implies only link-local address is allowed, or
   prefix validation is not enabled, or only manually configured prefix
   is allowed. Router Advertisement message not coming from such anchors
   MUST be dropped.

>
> Makes sense?
>
> - Christian
>
>
>
> On Jun 25, 2010, Jean-Michel Combes wrote:
>
>> Hi Guang,
>>
>>> Actually I agree with these views. It's better to leave the security
>>> problem of DHCP to DHCP itself. Any improvement achieved through SAVI is
>>> costly.
>>>
>>> For SLAAC, prefix validation is of obvious necessity. As no other
>>> protocols are in charge of bogus prefix on local link, I suggest SAVI to
>>> take the responsibility.
>>
>> This is already the case in FCFS proposal:
>>
>> 4.1.  FCFS SAVI Data structures
>>
>> [snip]
>>
>> In addition to this, FCFS SAVI need to know what are the prefixes that
>> are directly connected, so it maintains a data structure called the the
>> FCFS SAVI prefix list, which contains: o  Prefix o  Interface where
>> prefix is directly connected
>>
>> [snip]
>>
>> 4.2.1.  Processing of transit traffic
>>
>> [snip]
>>
>> 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 dat
>> packet is transit traffic and the packet SHOULD be discarded. The FCFS
>> SAVI function MAY send an ICMP Destination Unreachable Error back to the
>> source address of the data packet.  (ICMPv6, code 5 (Source address
>> failed ingress/egress policy) should be used). *  If the source address
>> of the packet does belong to one of the prefixes available in the the
>> receiving port, then the SAVI local traffic validation processes is
>> executed as described below.
>>
>>> Learning proper prefix from RA automatically is a practical solution.
>>
>> Practical but, IMHO, it's dangerous: what does prevent a malicious node
>> to poison the Prefix Table? You can use SEND to prevent such a case but
>> that would require many exchanges (i.e. cert check) and CPU consumption
>> (i.e. signature check). You can also use RA-Guard which needs, IIRC,
>> manual configuration and so the SAVI device already knows the allowed
>> prefixes.
>>
>> BTW, if the SAVI device is a router, the SAVI device already knows the
>> allowed prefixes as they have been configured to be advertised.
>>
>> Best regards.
>>
>> JMC.
>
> _______________________________________________
> savi mailing list
> savi@ietf.org
> https://www.ietf.org/mailman/listinfo/savi
> 