ietf
[Top] [All Lists]

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

2017-01-30 16:20:49
Ted,

On Jan 27, 2017, at 1:25 PM, Ted Lemon <mellon(_at_)fugue(_dot_)com> wrote:

On Jan 27, 2017, at 3:20 PM, jouni.nospam 
<jouni(_dot_)nospam(_at_)gmail(_dot_)com> 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