Re: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ted,

> On Jan 27, 2017, at 1:25 PM, Ted Lemon <mellon@xxxxxxxxx> wrote:
> 
> On Jan 27, 2017, at 3:20 PM, jouni.nospam <jouni.nospam@xxxxxxxxx> wrote:
>> I would still argue that it updates specifically if the document here is going to be standards track. If this document here would be more of a recommendation e.g., BCP I would be fine without the “updating” part (as I remember the MUST for IPsec in RFC3315bis was not endorsed by the WG).
> 
> Ok, but it's not a BCP, it's a standard, with requirements for interop.   So it can't be a BCP.
> 
> Given that it can't be a BCP, the other choices are "informational" and "experimental" and "updates the base spec."   You are saying that you want "updates the base spec," which would mean that everybody would have to implement it to conform to the new, updated spec.   But the argument has been made that this is not desirable: not everybody needs to implement this, and it is not desired that implementing this be a requirement.

The main differences in relay-server-security compared to rfc3315bis are:
1) the addition of mandatory to implement encryption and authentication algorithms
2) removal of IKEv1
3) removal of the availability statement
4) mixing IPv4 there as well

Otherwise it is mainly about capitalizing rfc2119 keywords (well one should changes to MUST, and one ’use’ is preceded with a MUST).

Now if I decide to implement rfc3315bis *with* security, follow all musts in Section 20.1, and listed “updates” in the header, I have still no guarantee whether I can interoperate with another rfc3315bis implementation because it decided to follow relay-server-security. That is not good.

> So are you saying that you disagree with this—that you think it should be MTI?   Or are you saying that there is some other way to accomplish this goal?

I am saying.. the intention of relay-server-security is good and I support it. The way it is done is IMHO not good. What I would do is to fix Section 20.1 in rfc3315bis with proper rfc2119 keywords and missing pieces (like the algorithms), but still keeping the implementation of 20.1 optional as it is now. Then I would do (i.e., relay-server-security) as a BCP saying “implementation of the security in rfc3315bis as defined in Section 20.1 is REQUIRED and MUST use the following profile..”. This can be worded to cover both DHCPv4 and DHCPv6.

- Jouni





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]