Subject: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 9 Dec 2016 15:58:17 +0100

Hi,

There are my review of the draft. Apologies for sending it up so late,
but I was travelling a lot recently. Finally got back home and catching
up on my IETF duties.

Section 3 uses non-normative language like "it is highly recommended"
and "relay agents A and B must be configured to use IPsec". This is a
standards track document, so why not normative language? I would very
much prefer to have a normative text. When a vendor claims "my solution
supports this RFC", what would it mean in its current form? The text is
not normative, so technically someone could claim compliance and not do
any of the IPsec at all.

The text in section 3 is also a bit conflicting. One part says "highly
recommended" and the next sentence says "must". This should be
consistent. My preferred way would be to go with "implementations
conformant to this document MUST ...". This wording does not enforce
vendors to implement it, but if they want to claim compliance, they
really need to be able to do IPsec.

idnits report some issues with references. The text cites RFC2409, but
it was obsoleted by RFC4306. If you have specific reasons why you
reference the old text, please state it in the text explicitly.
Otherwise, just update the references.

idnits also complains about a disclaimer for pre-RFC5378 work. I think
this is ok, because you're providing an updated text from RFC3315.

When you upload the next rev, make sure you bump up reference to
sedhcpv6 to -18.

The document is very specific as to what is updated in RFC3315 (section
21.1), but it's blurry regarding RFC1542 update. Is there any specific
text that is being updated? If there is, please clearly state so. If
there isn't, maybe this draft doesn't update RFC1542?

Other than the normative text clarification and 1542 update
clarification, I think the draft is in very good shape. With my co-chair
hat off, I support this work. With one more rev it should be ready to go.

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 9 Dec 2016 16:27:28 +0000

I discussed some of these issues with Tomek a bit.

Regarding the non-normative language issue, we have a proposal as follows:
- We will move the existing (non-normative language) into draft-ietf-dhc-rfc3315bis as it is best we don't require (but recommend) IPsec for DHCPv6. This would also correct the open issue we have in the draft-ietf-dhc-rfc3315bis document regarding the algorithms to use.
- We will reword this draft (in the 02) to use the normative (i.e., MUST) language. That way, if a vendor claims to be in compliance with this (future) RFC, they would have to fully support IPsec for the relay to server communication.

> idnits report some issues with references. The text cites RFC2409, but it was obsoleted by RFC4306.

I could be wrong, but my understanding is that RFC 2409 documents IKEv1. This was indeed obsoleted by IKEv2 (which is actually specified in RFC 7296 now -- 4306 was obsoleted by 5996 which was obsoleted by 7296). The reason we have both here is that we are referencing IKEv1 and IKEv2. I'm not so sure if there is any value in specifying IKEv1 anymore given that this us now almost 20 years old. I think the best move might be to change " Accordingly, IKE [RFC2409] / IKE2 [RFC7296] with preshared..." to just be " Accordingly, IKE2 [RFC7296] with preshared ..." and drop RFC 2409 altogether.

> idnits also complains about a disclaimer for pre-RFC5378 work. I think this is ok, because you're providing an updated text from RFC3315.

Correct.

>The document is very specific as to what is updated in RFC3315 (section 21.1), but it's blurry regarding RFC1542 update. Is there any specific text that is being updated? If there is, please clearly state so. If there isn't, maybe this draft doesn't update RFC1542?

For 1542, it really "extends" it since that document was silent about IPsec ... so we can remove this.

And, I wonder if we should even say it updates 3315 as that might imply it is "required" -- and we'll be updating draft-ietf-dhc-rfc3315bis already, as mentioned above. Thus I propose to just remove that (in the meta data and in the text). 

I'll wait a few days to see if anyone has any comments to this thread before publishing the -02 revision.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Friday, December 09, 2016 9:58 AM
To: [email-masked]
Subject: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01

Hi,

There are my review of the draft. Apologies for sending it up so late, but I was travelling a lot recently. Finally got back home and catching up on my IETF duties.

Section 3 uses non-normative language like "it is highly recommended"
and "relay agents A and B must be configured to use IPsec". This is a standards track document, so why not normative language? I would very much prefer to have a normative text. When a vendor claims "my solution supports this RFC", what would it mean in its current form? The text is not normative, so technically someone could claim compliance and not do any of the IPsec at all.

The text in section 3 is also a bit conflicting. One part says "highly recommended" and the next sentence says "must". This should be consistent. My preferred way would be to go with "implementations conformant to this document MUST ...". This wording does not enforce vendors to implement it, but if they want to claim compliance, they really need to be able to do IPsec.

idnits report some issues with references. The text cites RFC2409, but it was obsoleted by RFC4306. If you have specific reasons why you reference the old text, please state it in the text explicitly.
Otherwise, just update the references.

idnits also complains about a disclaimer for pre-RFC5378 work. I think this is ok, because you're providing an updated text from RFC3315.

The document is very specific as to what is updated in RFC3315 (section 21.1), but it's blurry regarding RFC1542 update. Is there any specific text that is being updated? If there is, please clearly state so. If there isn't, maybe this draft doesn't update RFC1542?

Other than the normative text clarification and 1542 update clarification, I think the draft is in very good shape. With my co-chair hat off, I support this work. With one more rev it should be ready to go.

Tomek

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 9 Dec 2016 17:53:44 +0100

> - We will reword this draft (in the 02) to use the normative (i.e., MUST) language. That way, if a vendor claims to be in compliance with this (future) RFC, they would have to fully support IPsec f…
That seems fine. This change would address my concerns.

> I think the best move might be to change " Accordingly, IKE [RFC2409] / IKE2 [RFC7296] with preshared..." to just be " Accordingly, IKE2 [RFC7296] with preshared ..." and drop RFC 2409 altogether.
That's fine by me.

> For 1542, it really "extends" it since that document was silent about IPsec ... so we can remove this.
Ok, that will work.

> And, I wonder if we should even say it updates 3315 as that might imply it is "required" -- and we'll be updating draft-ietf-dhc-rfc3315bis already, as mentioned above. Thus I propose to just remov…
Ok, by "and in the text" I assume you meant the "The following text
replaces the text in RFC3315 ..." at the beginning of Section 3? If
that's the case, I'm fine with that.

> I'll wait a few days to see if anyone has any comments to this thread before publishing the -02 revision.

<With my co-chair hat on>
Assuming no significant objections are raised to those changes proposed
by Bernie, I plan to wrap up this WGLC next week, let's say Wednesday.
If anyone has any concerns, please raise them before that day.

Tomek

---

From: Timothy Carlin <[email-masked]>
Date: Fri, 9 Dec 2016 12:03:56 -0500

Hello all,

I have done a brief review of this draft and I have some additional
thoughts.

Regarding the use of Manual Keys, ipsecme is currently having a discussion
about phasing out the use of Manual Keys.  See this thread for full context
(Subject: [IPsec] RFC4301, rfc7321bis and Manual keys):
https://mailarchive.ietf.org/arch/search/?email_list=ipsec&gbt=1&index=cMBLIx_ZzQVWP7lX1l-clgGdtvU

The document also recommends combined mode algorithms, such as AES-GCM, or
AES-GMAC.  These algorithms, and similar, generally disallow the use of
manual keys for security purposes.  For example, according to RFC4543,
Section 2, implementations MUST use automated key management (e.g. IKEv2),
as manual keying does not guarantee that a nonce and key is not reused and
therefore makes these algorithms insecure.

Best Regards,
Tim Carlin, UNH-IOL

On Fri, Dec 9, 2016 at 11:27 AM, Bernie Volz (volz) <[email-masked]> wrote:

> - We will move the existing (non-normative language) into
> draft-ietf-dhc-rfc3315bis as it is best we don't require (but recommend)
> IPsec for DHCPv6. This would also correct the open issue we have in the
> draft-ietf-dhc-rfc3315bis document regarding the algorithms to use.
> - We will reword this draft (in the 02) to use the normative (i.e., MUST)
> language. That way, if a vendor claims to be in compliance with this
> (future) RFC, they would have to fully support IPsec for the relay to
> server communication.
>
> it was obsoleted by RFC4306.
>
> I could be wrong, but my understanding is that RFC 2409 documents IKEv1.
> This was indeed obsoleted by IKEv2 (which is actually specified in RFC 7296
> now -- 4306 was obsoleted by 5996 which was obsoleted by 7296). The reason
> we have both here is that we are referencing IKEv1 and IKEv2. I'm not so
> sure if there is any value in specifying IKEv1 anymore given that this us
> now almost 20 years old. I think the best move might be to change "
> Accordingly, IKE [RFC2409] / IKE2 [RFC7296] with preshared..." to just be "
> Accordingly, IKE2 [RFC7296] with preshared ..." and drop RFC 2409
> altogether.
>
> 21.1), but it's blurry regarding RFC1542 update. Is there any specific text
> that is being updated? If there is, please clearly state so. If there
> isn't, maybe this draft doesn't update RFC1542?
>
> And, I wonder if we should even say it updates 3315 as that might imply it
> is "required" -- and we'll be updating draft-ietf-dhc-rfc3315bis already,
> as mentioned above. Thus I propose to just remove that (in the meta data
> and in the text).
>
> There are my review of the draft. Apologies for sending it up so late, but
> I was travelling a lot recently. Finally got back home and catching up on
> my IETF duties.
>
> standards track document, so why not normative language? I would very much
> prefer to have a normative text. When a vendor claims "my solution supports
> this RFC", what would it mean in its current form? The text is not
> normative, so technically someone could claim compliance and not do any of
> the IPsec at all.
>
> recommended" and the next sentence says "must". This should be consistent.
> My preferred way would be to go with "implementations conformant to this
> document MUST ...". This wording does not enforce vendors to implement it,
> but if they want to claim compliance, they really need to be able to do
> IPsec.
>
> idnits report some issues with references. The text cites RFC2409, but it
> was obsoleted by RFC4306. If you have specific reasons why you reference
> the old text, please state it in the text explicitly.
> 21.1), but it's blurry regarding RFC1542 update. Is there any specific text
> that is being updated? If there is, please clearly state so. If there
> isn't, maybe this draft doesn't update RFC1542?
>
> Other than the normative text clarification and 1542 update clarification,
> I think the draft is in very good shape. With my co-chair hat off, I
> support this work. With one more rev it should be ready to go.
>
> Tomek
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 9 Dec 2016 17:50:52 +0000

Hi Tim:

Thanks for the comments … and for looking at the document!

The document does say “manually configured key management may suffice, but does not provide defense against replayed messages. Accordingly, IKE …”. I think we’d change this may to MAY using normative language and we describe the limitations. As to the discussion about obsoleting, there are some cases where manual keys could still be desired (debugging, when using multicast – as is possible for relay to relay/server communication). So, I’m not sure we need a change?

But, if you have specific text changes you would like to see made, please provide them!

-          Bernie

From: Timothy Carlin [mailto:[email-masked]]
Sent: Friday, December 09, 2016 12:04 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: Tomek Mrugalski <[email-masked]>; [email-masked]; Yogendra Pal (yogpal) <[email-masked]>
Subject: Re: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01

Hello all,

I have done a brief review of this draft and I have some additional thoughts.

Regarding the use of Manual Keys, ipsecme is currently having a discussion about phasing out the use of Manual Keys.  See this thread for full context (Subject: [IPsec] RFC4301, rfc7321bis and Manual keys): https://mailarchive.ietf.org/arch/search/?email_list=ipsec&gbt=1&index=cMBLIx_ZzQVWP7lX1l-clgGdtvU

The document also recommends combined mode algorithms, such as AES-GCM, or AES-GMAC.  These algorithms, and similar, generally disallow the use of manual keys for security purposes.  For example, according to RFC4543, Section 2, implementations MUST use automated key management (e.g. IKEv2), as manual keying does not guarantee that a nonce and key is not reused and therefore makes these algorithms insecure.

Best Regards,
Tim Carlin, UNH-IOL

On Fri, Dec 9, 2016 at 11:27 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
I discussed some of these issues with Tomek a bit.

Correct.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tomek Mrugalski
Sent: Friday, December 09, 2016 9:58 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01

Hi,

Tomek

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 14 Dec 2016 22:05:30 +0100

Hi,
Bernie is a co-author of this draft, so I was the person responsible for
determining consensus on this one. I was travelling recently, so it took
longer than usual. Sorry about that.

Anyway, this draft received several voices of support. Nobody objected
the draft moving forward. This topic was presented during two IETF
meetings (95 and 96) and got favourable reception in the room. The
response to this WGLC was smaller than usual, but this is a fairly
straight-forward draft. This draft is also addressing a specific issue
raised by IESG while reviewing another draft.

Given all of the above, I determined that the consensus is to move
forward with this draft once the comments raised during WGLC are
addressed. Authors, please publish updated rev when ready and confirm
with people who commented that their issues were addressed. I'll start
working on my shepherd write-up as soon as the new rev is published.

Tomek