Re: RS sending in draft-ietf-v6ops-ipv6-cpe-router-04

[Wojciech Dec <wdec@cisco.com>]

On 26/04/2010 17:45, "Ole Troan" <ot@cisco.com> wrote:

> Woj,
> 
>> As a follow-up to the discussion, here's some proposed text for the "WAN
>> side requirements" in Section 4.2:
>> 
>> W-x:    The router MUST orignate RS messages with a source IP address set to
>> one of the interface's unicast addresses.
> 
> 
> let me see if I understand where you are coming from. this is for an DSL/GPON
> access network, where you require some isolation between the CPEs. so you
> don't do address resolution downstream, but you depend on things like DHCP
> snooping to learn address to L2 address bindings. then to learn the link-local
> to L2 binding, you obviously need something different than DHCP. so the only
> reliable protocol you're left with is the RS/RA exchange. correct?

Close...
The broadband access model has come to adopting/relying on RS messages as an
authorization trigger with line-id info (draft-krishnan). Notably RS
messages are the only ones to contain such info.
As such, it's pretty much de-rigueur to be able to bind at authorization a
subscriber to their source IP address and prevent IP spoofing of that
subscriber on a shared access medium. In IPv4 this is sometime known as
ARP-lock, and happens during DHCP authorization.
If the inclusion of a specific IP address in RS messages is left as
unspecified, then effectively no such binding between ip-l2 and line-id is
possible esp given that there is no guarantee of receiving any subsequent RS
(containing line-id + ip address) from that same CPE. As such it becomes
non-trivial to defend the CPE's IP address (identified by the line-id),
especially the LL address, from spoofing.

> 
> so something like this?
> 
> W-x: The IPv6 CE router MUST generate a link-local address and finish
> Duplicate Address Detection according to RFC4862 prior to sending any Router
> Solicitations on the interface. The source address used in the subsequent
> Router Solicitation MUST be the link-local address on the WAN interface.

That's even clearer, great.

> 
> this is contrary to the section 4 of RFC4862 by the way, which recommends the
> processes should be done in parallel. BBF's TR-124i2 also has DAD and router
> solicitation done in serial.

Serial execution of DAD and RS is fine and as such there is no harm to have
the serialized RS use a specific IP address.

-Woj.

> 
> cheers,
> Ole
> 
> 
> 
>> 
>> On 15/04/2010 16:02, "Wojciech Dec" <wdec@cisco.com> wrote:
>> 
>>> Hi,
>>> 
>>> Given that RS triggered access appears to be gaining ground (based on the
>>> latest  draft-krishnan-rs-mark) it would appear that the CPE router draft
>>> specify a bit more tightly the form of RS messages a CPE sends when
>>> connecting
>>> to a network. 
>>> RFC4861 section 6.3.7 states:
>>> " A host sends Router Solicitations to the all-routers multicast
>>>   address.  The IP source address is set to either one of the
>>>   interface's unicast addresses or the unspecified address."
>>> 
>>> Now, since the source address is very likely to be one of the identifier
>>> keys
>>> for a CPE used for authorization, I would like to propose that an RS sending
>>> rule be added to the CPE spec which would ensure that the IP source address
>>> is
>>> NEVER the unspecified address, eg:
>>> 
>>> The IPv6 CE router MUST use one of its WAN interface unicast addresses when
>>> sending RS messages.
>>> 
>>> Comments?
>>> 
>>> -Woj.
>> 
>> 
>