Hi Sri, Reason for the X.509 certificate is that, in some environments, an attacker can spoof a DHCP Client Identifier and receive services that were intended for the authentic client. With X.509 certificate, the certificate holder has to sign its DHCP messages with its private key so the DHCP server can authenticate using the public key and therefore defeat any spoofing.
Thanks - Fred [email protected] From: Sri Gundavelli (sgundave) [mailto:[email protected]] Sent: Monday, July 13, 2015 11:08 AM To: Templin, Fred L; Charlie Perkins; jouni korhonen; [email protected]; Charlie Perkins Subject: Re: [DMM] RFC4283bis progress.. HI Fred, MIP NAI structure is some what designed for carrying an identifier that can be represented in a simple structure. It is bound by the 1-octet size limit defined in RFC6275. X.509 is a complex structure, it includes the signed public key, serial number and number of other parameters and based on the key size it can be in Kbytes. Wondering, why a simple DHCP Client Identifier is not sufficient here. Support for EUI based identifiers is already present and that allows us to map to DHCP client identifiers ? Regards Sri From: "Templin, Fred L" <[email protected]<mailto:[email protected]>> Date: Monday, July 13, 2015 at 10:50 AM To: Charlie Perkins <[email protected]<mailto:[email protected]>>, Sri Gundavelli <[email protected]<mailto:[email protected]>>, jouni korhonen <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Charlie Perkins <[email protected]<mailto:[email protected]>> Subject: RE: [DMM] RFC4283bis progress.. Hi, I would like to suggest one additional identifier before publication: X.509 certificate as per Section 5.2 of Secure DHCPv6: https://www.ietf.org/id/draft-ietf-dhc-sedhcpv6-08.txt Thanks - Fred [email protected]<mailto:[email protected]> From: dmm [mailto:[email protected]] On Behalf Of Charlie Perkins Sent: Thursday, July 09, 2015 7:45 PM To: Sri Gundavelli (sgundave); jouni korhonen; [email protected]<mailto:[email protected]>; Charlie Perkins Subject: Re: [DMM] RFC4283bis progress.. Hello folks, The last discussion about the document was related to whether or not Vehicle ID should be included in the draft. No resolution was reached for that discussion. However, the draft may still be considered ready for publication. Other ID formats can certainly be added in the future. Regards, Charlie P. On 7/9/2015 6:30 PM, Sri Gundavelli (sgundave) wrote: I can review and provide comments. I think its ready for publication, may be after a minor edit. From: dmm <[email protected]<mailto:[email protected]>> on behalf of jouni korhonen <[email protected]<mailto:[email protected]>> Date: Thursday, July 9, 2015 at 1:49 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Charlie Perkins <[email protected]<mailto:[email protected]>> Subject: [DMM] RFC4283bis progress.. Charlie, WG, In last IETF and slightly after that there was discussion about missing MN-IDs in the current -00 version. Have these been or rather will these be addressed? I'd like to move this trivial document forward. - Jouni & Dapeng _______________________________________________ dmm mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
