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.
>   In reality, malicious hosts do not follow the RFCs.
untrustworthy hosts aren't necessarily malicious.
>   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.
> 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
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops