Subject: Review of draft-ietf-dhc-relay-server-security-02

From: Jouni Korhonen <[email-masked]>
Date: Wed, 25 Jan 2017 22:45:07 -0800

Reviewer: Jouni Korhonen
Review result: Not Ready

Disclaimer: I have not followed recent DHC discussions to the extent
that the existence this document was new to me.

Issues:

My issues with the document are the following. First, it actually
updates a great deal of RFC3315 (Section 21.1) while there is
RFC3315bis in progress. Why the DHCPv6 part of this document is not
directly contributed to RFC3315bis work? There's even author overlap
so there must be a good reason. Second, if there is a reason to keep
the content of this document separate from RFC3315 body of work, at
least this specification should then target to update RFC3315bis and
not RFC3315.

Other smaller nits:

o This document updates both RFC3315(bis) and RFC1542. Those are not
reflected in the document title page and abstract. 

o I would separate the new recommendation text for DHCPv4 and DHCPv6
into their own respective section. Having just a one-liner statement
"also applies to DHCPv4 [RFC1542].." is kind of confusing in a middle
of very DHCPv6 specific text. I recon the DHCPv4 section would be
short, but definitely more clear in that way.

o Although it should be obvious, but I would explicitly point it out
in the Security Considerations that the security model here is
hop-by-hop. If there are multiple relays then there will be multiple
IPsec tunnels as well.

o Section 14:  s/section 14,/Section 14,

o

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 26 Jan 2017 11:24:29 +0100

W dniu 26.01.2017 o 07:45, Jouni
Korhonen pisze:

Reviewer: Jouni Korhonen
Review result: Not Ready

Issues:

Hi Jouni,

First of all, thanks for doing the review.

I will leave it up to the authors to provide further details on
this, but with my shepherd hat on, let me explain that this omission
was made on purpose. The decision was made to not update 3315 and
not bundle this into 3315bis on purpose. If we did that, then every
DHCP server would HAVE to support IPSec. This would make
implementation, certification and deployment much more complex and
this is something we wanted to avoid. With the current approach,
operators can be specific whether they need relay server security
(by requiring their vendors to support both 3315 and this document)
or not (just 3315).

This is also explained in the write-up:

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No. Even though this I-D introduces changes to RFC3315, the WG doesn't
want to enforce IPsec encryption on every DHCPv6 server. Therefore
it does not update RFC3315.

Also, I'd like to clarify that 3315bis is not a wildcard that
bundles every RFC related to DHCPv6 ever published. This document is
133 pages long and that size causes difficulties moving the work
forward. We're thinking what are the things we can take out of it,
rather what else we could add. The previous argument still stands
here. We want to have the core spec and an additional RFC that
people can point to when they require secure server-relay
communication.

If that explanation is not acceptable for you, how do you propose to
structure the text and possibly add updates 2131/3315 to achieve the
goal or being a non-mandatory feature?

I'll let the authors comment on the nits.

Again, thanks for the review. It's good to receive one that shakes
things up a bit once in a while :)

Tomek

Other smaller nits:

o

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 26 Jan 2017 13:38:40 +0000

Hi:

Thanks for the review Jouni (as Int-Dir coordinator and document coauthor).

Regarding the main issue and to extend Tomek’s comment …

We actually have used this text, but without the MUST, in 3315bis (the updated version has not been published as the coauthors are still working through the remaining open issues from the approximately 300 that we captured during the 3315bis WGLC back in August). We do expect to publish an updated version before the IETF-98 deadline (hopefully with all issues addressed, but we’ll see).

And, as Tomek explained, this idea here was to make this an OPTIONAL feature that vendors could implement (much like any new DHCP option) – but if we left the text as a SHOULD or similar, vendors could claim they supported it without actually implementing it. Thus, this document has a MUST. And, it does not update – but rather extends – 3315 and 1542.

BV> I’ll discuss this with Yogendra … I think we can just make this clearer by either breaking out this applicability text for v4/v6 into separate paragraphs. I don’t think there really should be a need to duplicate the main material – i.e., have separate sections which basically would be the same text on the IPsec items.

IPsec tunnels as well.

BV> Sure, we can add that.

BV> OK, thanks for catching that.

Again, thanks.

-          Bernie

From: Tomek Mrugalski [mailto:[email-masked]]
Sent: Thursday, January 26, 2017 5:24 AM
To: Jouni Korhonen <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Review of draft-ietf-dhc-relay-server-security-02

W dniu 26.01.2017 o 07:45, Jouni Korhonen pisze:

Reviewer: Jouni Korhonen

Review result: Not Ready

Issues:

not RFC3315.
Hi Jouni,

I will leave it up to the authors to provide further details on this, but with my shepherd hat on, let me explain that this omission was made on purpose. The decision was made to not update 3315 and not bundle this into 3315bis on purpose. If we did that, then every DHCP server would HAVE to support IPSec. This would make implementation, certification and deployment much more complex and this is something we wanted to avoid. With the current approach, operators can be specific whether they need relay server security (by requiring their vendors to support both 3315 and this document) or not (just 3315).

Also, I'd like to clarify that 3315bis is not a wildcard that bundles every RFC related to DHCPv6 ever published. This document is 133 pages long and that size causes difficulties moving the work forward. We're thinking what are the things we can take out of it, rather what else we could add. The previous argument still stands here. We want to have the core spec and an additional RFC that people can point to when they require secure server-relay communication.

If that explanation is not acceptable for you, how do you propose to structure the text and possibly add updates 2131/3315 to achieve the goal or being a non-mandatory feature?

Again, thanks for the review. It's good to receive one that shakes things up a bit once in a while :)
Tomek

Other smaller nits:

IPsec tunnels as well.

o

---

From: "jouni.nospam" <[email-masked]>
Date: Thu, 26 Jan 2017 10:25:45 -0800

Bernie, Tomek,

> On Jan 26, 2017, at 5:38 AM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Hi:
>  

Hmm.. I really do not like specification “games” like this. If you cannot justify a MUST into RFC3315bis, then trying to circumvent the fact in another document (that does not update the RFC3315 or RFC3315bis) should not be a Standards Track document. I could accept this as a BCP or a like.

- Jouni

> _______________________________________________
> Int-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-dir

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Jan 2017 13:36:59 -0500

> Hmm.. I really do not like specification “games” like this. If you cannot justify a MUST into RFC3315bis, then trying to circumvent the fact in another document (that does not update the RFC3315 or…

Hm, then you are saying that every extension ever done to a protocol that, if it contains MUSTs, MUST update that protocol, even if implementations that support the extension can interoperate with implementations that do not and vice versa.   What's your basis for this?

---

From: "jouni.nospam" <[email-masked]>
Date: Thu, 26 Jan 2017 10:58:32 -0800

> On Jan 26, 2017, at 10:36 AM, Ted Lemon <[email-masked]> wrote:
> 
> Hm, then you are saying that every extension ever done to a protocol that, if it contains MUSTs, MUST update that protocol, even if implementations that support the extension can interoperate with implementations that do not and vice versa.   What’s your basis for this?

No. But in this case there are pieces of text that change specific places in the original document from SHOULDs to MUSTs, musts to MUSTs, and adds few pieces of new stuff, etc. Now how that in not updating? Changes or “extensions” like that would be nice to follow from the base document.

- Jouni

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 26 Jan 2017 19:18:09 +0000

Hi:

It sounds like we should not use:

"The following text replaces the text in RFC3315 section 21.1 ..."

But instead just use something close to the following which replaces 1st paragraph in section 3:

   For DHCPv6 [RFC3315], this specification REQUIRES IPsec encryption of relay to
   relay and relay to server communication.

   For DHCPv4 [RFC2131], this specification REQUIRES IPsec encryption of relay to
   server communication.

   By using IPsec with encryption for this communication,  the potentially sensitive
   client message and relay included information, such as the DHCPv4 relay-agent
   information option (82), vendor-specific information (for example, [CableLabs-DHCP]),
   and Access-Network-Identifier Option(s) [RFC7839], are protected from pervasive
   monitoring and other attacks.

What is in other documents doesn't really matter ...

- Bernie

-----Original Message-----
From: jouni.nospam [mailto:[email-masked]] 
Sent: Thursday, January 26, 2017 1:59 PM
To: Ted Lemon <[email-masked]>
Cc: Bernie Volz (volz) <[email-masked]>; Tomek Mrugalski <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Jouni Korhonen <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02

- Jouni

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Jan 2017 14:27:02 -0500

> No. But in this case there are pieces of text that change specific places in the original document from SHOULDs to MUSTs, musts to MUSTs, and adds few pieces of new stuff, etc. Now how that in not…

Okay, I see your point.   But suppose the document were changed so that rather than "updating" the document as you suggest, it simply referenced the sections in question and then made the SHOULDs into MUSTs that way?   Wouldn't that mean "implementations of this extension MUST," and wouldn't that be perfectly reasonable?

---

From: "jouni.nospam" <[email-masked]>
Date: Fri, 27 Jan 2017 12:20:03 -0800

> On Jan 26, 2017, at 11:27 AM, Ted Lemon <[email-masked]> 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).

- Jouni

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Jan 2017 16:25:12 -0500

> 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 “…

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.

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?

---

From: "jouni.nospam" <[email-masked]>
Date: Mon, 30 Jan 2017 14:20:02 -0800

Ted,

> On Jan 27, 2017, at 1:25 PM, Ted Lemon <[email-masked]> wrote:
> 

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Jan 2017 17:54:23 -0500

> 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 rfc3…

Thanks.   This is the clarification I was looking for.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 30 Jan 2017 23:08:59 +0000

Hi:

Let's take the 3315bis out of the discussion as we don't yet know when that will be available and we'd like to progress on this draft sooner than that (as it is shorter and easier to do). We can get back to it later, but let’s focus first on today’s issue with is the document with RFC 3315.

So if this is released as RFC9999, the only way you as someone looking for relay or server implementations (or both) could know that this is supported is by asking the supplier whether they support RFC3315 and RFC9999. RFC9999 does not have up update 3315. This is just like many of the other DHCP RFCs which extend the functionality – Leasequery, bulk Leasequery, active Leasequery, and the many options documents. If you want certain features and they are in other documents, you have to specify the complete list.

Saying it updates RFC3315 doesn’t help since there are plenty of existing implementations that don’t support IPsec.

Back to RFC 3315 bis (draft-ietf-dhc-rfc3315bis), that is still a work in progress. Our plans to date are that we’ll incorporate all of the changes of draft-ietf-dhc-relay-server-security but leave it OPTIONAL to implement IPsec. This means that once draft-ietf-dhc-rfc3315bis is published as an RFC, those that want IPsec will have to check that the implementation supports both the bis RFC and RFC9999 (or whatever number). But that’s the same that someone wanting Leasequery must do – they’ll need to check that the bis RFC and RFC5007 are supported.

The draft-ietf-dhc-rfc3315bis and/or draft-ietf-dhc-relay-server-security authors can always raise it to the DHC WG to see if there is sufficient consensus to make IPsec a MUST in the bis document. But there hasn’t been in the past.

-          Bernie

From: Ted Lemon [mailto:[email-masked]]
Sent: Monday, January 30, 2017 5:54 PM
To: jouni.nospam <[email-masked]>
Cc: Bernie Volz (volz) <[email-masked]>; Tomek Mrugalski <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Jouni Korhonen <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02

On Jan 30, 2017, at 5:20 PM, jouni.nospam <[email-masked]<mailto:[email-masked]>> wrote:
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.

---

From: "Yogendra Pal (yogpal)" <[email-masked]>
Date: Tue, 31 Jan 2017 18:38:21 +0000

With full due respect of conversation, I see Bernie's point, towards flexibility. For e.g: We see two operators primary wherein, device operator would like to have base RFC3315 supported for n/w and security operator asking for security in n/w via RFC9999.

Regards, Yogendra Pal
From: "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 31 January 2017 4:38 am
To: Ted Lemon <[email-masked]<mailto:[email-masked]>>, "jouni.nospam" <[email-masked]<mailto:[email-masked]>>
Cc: Tomek Mrugalski <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jouni Korhonen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, Yogendra Pal <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Tomek Mrugalski <[email-masked]<mailto:[email-masked]>>
Resent-Date: Tuesday, 31 January 2017 4:39 am

Hi:

Let's take the 3315bis out of the discussion as we don't yet know when that will be available and we'd like to progress on this draft sooner than that (as it is shorter and easier to do). We can get back to it later, but let's focus first on today's issue with is the document with RFC 3315.

So if this is released as RFC9999, the only way you as someone looking for relay or server implementations (or both) could know that this is supported is by asking the supplier whether they support RFC3315 and RFC9999. RFC9999 does not have up update 3315. This is just like many of the other DHCP RFCs which extend the functionality - Leasequery, bulk Leasequery, active Leasequery, and the many options documents. If you want certain features and they are in other documents, you have to specify the complete list.

Saying it updates RFC3315 doesn't help since there are plenty of existing implementations that don't support IPsec.

Back to RFC 3315 bis (draft-ietf-dhc-rfc3315bis), that is still a work in progress. Our plans to date are that we'll incorporate all of the changes of draft-ietf-dhc-relay-server-security but leave it OPTIONAL to implement IPsec. This means that once draft-ietf-dhc-rfc3315bis is published as an RFC, those that want IPsec will have to check that the implementation supports both the bis RFC and RFC9999 (or whatever number). But that's the same that someone wanting Leasequery must do - they'll need to check that the bis RFC and RFC5007 are supported.

The draft-ietf-dhc-rfc3315bis and/or draft-ietf-dhc-relay-server-security authors can always raise it to the DHC WG to see if there is sufficient consensus to make IPsec a MUST in the bis document. But there hasn't been in the past.

-          Bernie

From: Ted Lemon [mailto:[email-masked]]
Sent: Monday, January 30, 2017 5:54 PM
To: jouni.nospam <[email-masked]<mailto:[email-masked]>>
Cc: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>; Tomek Mrugalski <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Jouni Korhonen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02

On Jan 30, 2017, at 5:20 PM, jouni.nospam <[email-masked]<mailto:[email-masked]>> wrote:
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.