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

[Wojciech Dec <wdec@cisco.com>]

On 26/04/2010 16:28, "Philip Homburg" <pch-v6ops@u-1.phicoh.com> wrote:

> In your letter dated Mon, 26 Apr 2010 16:06:10 +0200 you wrote:
>>>> It helps in being able to bind the MAC to an IPv6 address for that
>>>> subscriber. Coincidentally, this is exactly what is already in place for v4
>> .
>>> Why the link local address?
>> 
>> It can be any unicast address.
> 
> Yes, but in the context of an RS, that will be the link-local address. Or
> are you thinking of requiring the use of a global IPv6 address as the
> source of RS messages?

 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."

As you can see, whether the global or LL IPv6 address is used is
unspecified. From my perspective the LL is more likely, and is what the BNG
would prefer to see.

> 
>>>> Without such a binding, LL spoofing becomes an issue.
>>> 
>>> Can you be a bit more specific?
>>> 
>>> IPv4 doesn't have a link local address.
>> 
>> In IPv4 the binding is DHCP derived, something that is a bit harder to
>> assume with IPv6.
>> BTW IPv4 does have LLs too, but they happen not to be commonly used (at
>> least not by CPEs).
> 
> Can we stick to what is actually used in the context of CPEs?
> 
> I know that IPv4 LL address exist, but I have a hard time understanding how
> you would use them to provide a customer with a working Internet connection.
> 
> So for IPv4, you need a binding between the global IPv4 address and the MAC
> address.
> 
> For IPv6 you need to bind IPv6 addresses or prefixes to MAC addresses.
> 
> No need for link-local addresses.

LLs are absolutely needed. DHCPv6 uses them as does ND. Furthermore, in the
CPE draft we support the so called "unnumbered" model, whereby the WAN
interface has NO global IPv6 address.

> 
>>> So what kind of traffic do you expect to and from the link-local address.
>>> There is of course the neighbor discovery stuff. But you probably have to
>>> filter that already to avoid customers talking directly to each other
>>> without going through the router.
>>> 
>> For the CPE the vital traffic is DHCP-PD signaling and this will be sourced
>> from a LL address. If one assumes that an RS is the trigger for user
>> authorization, securing the address binding at that same time is optimal and
>> useful in also securing any follow-on DHCP-PD assignment, besides any other
>> traffic that would suffer from spoofed LLs.
>> Note that the binding table will need to factor in the other unicast
>> addresses too.
> 
> If you already have a link identifier for the RS, why not use it as well for
> the DPCP-PD? 

I'm referring to creating an IP-L2-binding using an IP address obtained from
an RS, which is used to authorize a customer.

> 
> Are you really assigning DHCP-PD prefixes based on the link-local source
> address in the solicit?

This is not what I said.

> 
>> Do you see any downside of the proposal?
> 
> I think there is a recent trent to just add all kind of extra requirements
> for CPEs that are not there in the underlying protocols.
> 
> In my opinion, if you really need this, just get RFC-4861 changed to disallow
> the use of an unspecified address as the source of an RS.

RFC-4861 allows *both*, thus it is something that is supported in the
"unerlying protocols". The unspecified address option in 4861 was/is there
to allow a host to issue an RS  on the WAN interface before attempting or
completing SLAAC. Since in the CPE spec we assume SLAAC (and DHCP-PD), I'm
saying that it would be highly welcome for the CPE to use a tighter form of
the RS sending rule, which will make BNG processing easier.

> 
> But I still have no clear picture how a customer can spoof things using his
> link local address.
>
The issue is one of overwriting ND cache entries in the BNG, by having one
customer spoof another's LL address.

I take it that other than clarifications, you see no issue with the
proposal.

-Woj.
>