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

[Mark Smith <[e-mail]>]

I agree with Joel, I think observation by most likely a router is a better method, as it will capture address information regardless of whether it was configured via static, SLAAC or DHCPv6 (or any future methods).

I haven't had a chance to run Fernando's utility, however I understand it implements address recording using observation.

http://www.si6networks.com/tools/ipv6mon/



----- Original Message -----
> From: Sheng Jiang <[e-mail]>
> To: joel jaeggli <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>; IPv6 Ops WG <[e-mail]>; "[e-mail]" <[e-mail]>
> Sent: Friday, 16 November 2012 5:11 PM
> Subject: Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01
> 
>>>>> 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
>>> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>