Skip to main content

Security of Messages Exchanged between Servers and Relay Agents
draft-ietf-dhc-relay-server-security-05

Note: This ballot was opened for revision 04 and is now closed.

Warren Kumari
(was Discuss) No Objection
Comment (2017-04-20) Unknown
"This document specifies the optional requirements for relay agent and	
 	   server implementations to support IPsec authentication and encryption	
 	   and recommends operators enable this IPsec support."

Thank you, this adequately addresses my discuss.
Alexey Melnikov Former IESG member
Yes
Yes (2017-04-12 for -04) Unknown
Thank you for writing this document.

I am curious to know whether there are existing or planned implementations/deployments of this document.

I am also agreeing with Warren concerns.
Ben Campbell Former IESG member
Yes
Yes (2017-04-12 for -04) Unknown
I am balloting "Yes", but I share the curiosity about whether people will really do this.

-3, third paragraph: "MUST exchange messages securely"
"Securely" is too ambiguous for a MUST. What specific protections are required?

-3, paragraph 4:
The list starts with no context. A sentence or paragraph describing the purpose of the list would be helpful.
Kathleen Moriarty Former IESG member
Yes
Yes (2017-04-11 for -04) Unknown
Thank you very much for your work on this document.  Once Warren's discuss has been cleared with adequate clarifications and 'updates' text, which I support, this will be a helpful document.  It will be very nice to no longer have the discussion as to why encryption is not required for DHCP, this is a welcome and overdue change.  

Is there an expected change to encrypt the full path in a future revision?
Suresh Krishnan Former IESG member
Yes
Yes (for -04) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (2017-04-12 for -04) Unknown
I agree with both Warren's discuss and Benoit's comments about balloting being
easier when others have already done so :-)
Alissa Cooper Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2017-04-10 for -04) Unknown
I agree with Warren's confusion about the relationship between this document, RFC3315 and draft-ietf-dhc-rfc3315bis.
Benoît Claise Former IESG member
No Objection
No Objection (2017-04-12 for -04) Unknown
The advantage of a late review is that everything has been said already by other ADs :-)
Deborah Brungard Former IESG member
No Objection
No Objection (2017-04-12 for -04) Unknown
Agree with other ADs' comments.
Eric Rescorla Former IESG member
(was Discuss) No Objection
No Objection (2017-04-24) Unknown
Based on e-mail it seems like at least one company is implementing.

Personally, were I voting, I'd vote against making an MTI that I expect almost nobody to follow, but I concede that there's not sufficient evidence of that to hold a discuss here.
Mirja Kühlewind Former IESG member
No Objection
No Objection (2017-04-11 for -04) Unknown
I strongly agree with Warren's discuss. This document is an update of RFC3315 and therefore MUST carry the update tag. If someone decides not to implement this new specification, they will still only confirm to RFC3315 and not this new document. As Warren said, someone who wants this encryption needs to require conformance to this new RFC anyway. However I think the IETF should give a clear recommendation here that encryption must be used. If the working group really believes there are cases where encryption is not needed, this document must be rewritten to allow for these cases (by using SHOULD/RECOMMENDED instead of MUST/REQUIRED) and give a clear recommendation when it is acceptable to not use encryption.

Further, I'm also wondering why this is not just incorporated in rfc3315bis?
Spencer Dawkins Former IESG member
No Objection
No Objection (2017-04-09 for -04) Unknown
Thanks for producing this document, when the DISCUSSes clear :-)