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

[joel jaeggli <[e-mail]>]

On 11/15/12 6:33 PM, Sheng Jiang wrote:
>> -----Original Message-----
>> From: joel jaeggli [mailto:[e-mail]]
>> Sent: Friday, November 16, 2012 9:51 AM
>> To: Sheng Jiang
>> Cc: [e-mail]; IPv6 Ops WG;
>> [e-mail]
>> Subject: Re: [v6ops] some feedback on
>> http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01
>>
>> On 11/15/12 4:51 PM, Sheng Jiang wrote:
>>>> There's a couple issues that are quite striking. I kind of concur with
>>>> Fred  Baker that the most appropiate method for tracking l2/l3 binding
>>>> for address identification is probably more akin to syslog.
>>>>
>>>> That is, since you don't really trust the hosts, having a switch/router,
>>>> simply sysloging all new NDP cache entries pretty much achives the same
>>>> thing execept with a lot less signaling.
>>> Hi, Joel,
>>>
>>> I am not agree the precondition you have here: "since you don't really trust
>> the hosts". The assume we take is that hosts, at least host IP stack, would do
>> this right. Or at least they will do right things by standard definitions.
>> That's an interesting assumption given that all pre-existing host stacks
>> will be unaware of the availability of the mechanism and therefore not
>> use it.
> This argument seems too wide. If so, our IETF should never define any new extension headers/options/mechanisms because all pre-existing host stacks do not unaware them.
There should be a pretty high standard associated with  changing the 
behavior of things which already exist.
> For me, your argument is available if it comes like this way: there should be more considerations for how to support backwards compatibility. We can work on that.
>
>>>    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? 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.
> c) host stacks does not register address/mac right. For me, a has been described in the draft; b should be consider as malicious behavior; c is down to implementation, it is not a standard issue.
>
> If you have other untrustworthy considerations, please give details. I am happy to discuss them.
>
>>>    Therefore, they are considered as security issues. It only means more
>> security mechanism/infrastructure should be deployed. It should not deny the
>> meaning of address registration. It servers most of ordinary hosts, which may
>> be 99% of all users.
>> 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.

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.


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
>