Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01

[Sheng Jiang <[e-mail]>]

>>>>In reality, malicious hosts do not follow the RFCs.
>>> untrustworthy hosts aren't necessarily malicious.
>> Ok. Let's discuss which part you don't trust from hosts. There are several
>>possibilities I can think out: a) hosts refuse to register their addresses, b) hosts
>>register wrong address/mac on purpose

>What is wrong MAC in this case? 

I referred to these malicious hosts, who uses faked MAC to get network access or plays to be other hosts.

>MACs are generally but not always stable
>(vrrp6 is a pretty good case for not stable), in any event they are
>reconfigurable. A MAC is a layer 2 binding and if you have a strong
>layer-2 authentication (as some centrally managed networks do) then
>forgery is essentially irrelvant. beyond that the correctness of a MAC
>absent ACLs, is limited to it's presence in the bridge table and any
>l2/l3 bindings it may have.

Then, why hosts are untrustworthy to register address?

>>> I can with relatively minor effort on the part of a vendor capture the
>>> same information, with a lot less signaling out of the NDP cache on my
>>> routers, and do so without consideration of hosts behavior.
>> I agree with you if we only discuss the scenario that first-hop router is fully
>>under management by ISPs. But there are other scenarios, in which first-hop
>>router is home gateway, mobile node and others. For these scenarios, ISP
>>cannot get the address information unless host registering.

>Either the network is centrally managed or it isn't. The draft describes
>a management entity (enterprise) which is fully in control of the first
>hop router(s). Here you're describing a transitory trust model where my
>first hop router managed by me passes a registration option to my hosts
>to register addresses used on my network with my ISP. That's not, in
>your document.

Yes, it was not in the document. Since this document is a DHC draft, we focused on the DHCP Protocol interaction and option definition. We did not do very well to describe suitable scenarios until recently. We will work on that. Thanks to help us improve the document.

>The network in my house, or my enterprise is managed by me, my ISP once
>they've assigned or delegated a prefix doesn't get to determine if I can
>use an address or not. It is no business of my ISP, if my fridge, or
>thermostat decides to use SLAAC to assign an address from the prefix
>which it plans to use becuase it's covered by RA.
>
>> Another point is this new registration is bi-direction interaction. It gives ISPs
>>a chance to manage these host-generated addresses, such as denying certain
>>address (such as low sec-value CGA), etc. For now, ISPs has to accept all
>>host-generated addresses. If ISP denies access because of any
>>address-relevant reasons, there is no mechanism to tell hosts why and how to
>>fix it.

>Interesting use case. It's not in the document however, which you do
>have is.
>
>    After receiving this address registration request, the address
>    registration server MUST register the requested address in its
>    address database, which may further be used by other network
>    functions, such as DNS, network access control lists, etc.
>
>so presumably you tell the IA that it can't have an address by setting
>preferred-lifetime and valid-lifetime fields to 0, that doens't seem like an
>extremely useful message to send back out a client trying to register an
>address.

Agree, more information should be provided in the case of reject address. Actually, the specific case of denying CGA with low sec-value was solved by another dedicated draft (http://tools.ietf.org/html/draft-ietf-dhc-cga-config-dhcpv6) , in which a new DHCPv6 option has been defined to feedback a recommended Sec value.

We will improve this part in next update.

Best regards,

Sheng

>Fundamentally if you don't control the network you shouldn't be managing
>address selection on it since you don't know what people will attach. if
>you do then by all means do so.
>
>
>> Best regards,
>>
>> Sheng
>>
>>>> Best regards,
>>>>
>>>> Sheng
>>>>
>>>>> If a strong assertion of L2 identity in support of l2/l3 bindings is
>>>>> required 802.1x or the wireless equivalanet seems appropiate, e.g. it's
>>>>> what we do today.
>>>>>
>>>>> Availing oneself of a dhcp/ra option entails a lot of signaling for what
>>>>> is likely a relatively ephemeral port (windows machines and macs
>>>>> registering privacy addresses for example). specifiying a binding
>>>>> lifetime seems of limited utility since the host will probably discard
>>>>> the address long before the lifetime expires if it's sufficently long
>>>>> enough to allow for long lived connections using that address.
>>>>> _______________________________________________
>>>>> v6ops mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>