Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th

From: 神明達哉 <[email-masked]>
Date: Wed, 5 Apr 2017 09:53:11 -0700

At Thu, 30 Mar 2017 14:37:44 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> Regarding RFC5652, you will need to work with others to determine
> what pieces are applicable - perhaps check in with Stephen to get
> more clarity on what he intended? Perhaps Jinmei or Francis Dupont
> has some suggestions?

I have no clue on this.  BTW, I guess this echoes my high-level
concern: I suspect the current spec still has some points that are
critically unclear, which you would immediately notice once you tried
to implement it.  If we're lucky some reviewers may be able to
identify these points, but it's much less reliable than findings from
actual attempts of implementing it.  IMO we shouldn't try to publish a
spec for which even none of the coauthors ever tried to write a
prototype implementation (and I know I'm also guilty in that sense).

--
JINMEI, Tatuya

---

From: Timothy Carlin <[email-masked]>
Date: Wed, 5 Apr 2017 13:13:38 -0400

I apologize for the late email, I have read the document and have some
thoughts.

It's not completely clear which part of the messages are encrypted and
integrity protected, or if there are parts that are only integrity
protected.  The Increasing-number Option is contained in the encrypted
DHCPv6 messages, which may be a concern.

An attacker can transmit replayed packets and the server must attempt to
decrypt the packet to determine if it is a replayed (or otherwise invalid)
packet and an attack.  The decryption process is an expensive one, so this
could be a denial-of-service vector.

I have two possible suggestions.  The first is to move the
Increasing-number Option to an integrity protected (but not encrypted)
portion of the packet.  This allows for a preliminary check of the sequence
number, prior to any decryption or integrity processing.  This is similar
to ESP's sequence number check (https://tools.ietf.org/html/
rfc4303#section-3.4.3).

The second option is to document the potential attack in the Security
Considerations.  Additionally, including text to limit the rate at which
encrypted messages may be sent by a client and subsequently processed.

I'm also wondering about using RSA for encryption, as the data size (and
thus message size) is limited to the key size that the client or server
provides.  This could cause problems with large DHCP messages.  Could a
symmetric key algorithm (e.g. AES) be used?  The keys for this would have
to be negotiated during the initial Information-request/Reply.

Tim Carlin
UNH-IOL

On Thu, Mar 30, 2017 at 2:00 PM, Tomek Mrugalski <[email-masked]
> wrote:

> I have reviewed the draft and in my opinion -21 is in great overall
> shape. The text reads so much better, the concept is clearly explained
> early and the whole text fits together well. I do have many comments,
> but great majority of them are clarifications and editorial corrections.
> Good work, authors!
>
> Ok, let's start with easy ones.
>
> idnits. There are a number of idnits errors and warnings: 3 errors (**),
> 0 flaws (~~), 8 warnings (==), 5 comments (--).. Please fix them. Ping
> me off the list if you need a little help with idnits tool.
>
> This draft defines a set of recommendations for secure environment. It
> is not expected to be used by all DHCP implementations is every
> deployment, just those who are interested in improved security. In
> certain way it is very similar to anonymity profile. Anonymity profile
> defined set or rules that are not expected to be used by all DHCP
> implementations in every deployment, just those who are interested in
> improved privacy. So maybe it should be called Security Profile for
> DHCPv6? I think this approach does not change anything from technical
> perspective, but simply frames the solution better. Described that way
> it may also be easier to accept to people who may afraid we want to
> force everyone to encrypt everything everywhere. It's just a suggestion
> to consider, I don't insist on it if authors or the WG disagree.
>
> I like section 5, especially 5.1 and 5.2 a lot. It's a great two-page
> intro to the concept.
>
> Section 5.3
> nit: mainly a algorithm => mainly an algorithm
>
> Section 5.4 should also discuss the problem with Confirm message
> mentioned earlier by Jinmei.
>
> Section 5.5
> nit: In some scenario => In some scenarios
>
> Section 6
> nit: is a Increasing-number option => is an Increasing-number option
>
> Section 6: Is Advertise protected as well? I think it definitely should
> be to the maximum extent possible. Once the initial info-request/reply
> is completed, the next step for the client is to send Solicit wrapped in
> Encryption-Query. The server will reply with Advertise wrapped in
> Encryption-Response. At this stage the received Advertise can be
> validated. Maybe not all of the checks are possible yet for Advertise,
> because of not all necessary information is available yet (e.g. there's
> not possible to do the increasing number check as this is the first
> packet coming back and the client doesn't have previous value to check
> it against), but some checks are definitely applicable (e.g. drop
> because signature is missing, multiple signatures or certificate missing).
>
> Unless there's a good reason to not do it, the rules described in on
> page 9 should apply to both Advertise and Reply.
>
> "beat out a busy "real" server" => "beat out a busy legitimate server"
>
> There is this text: "The Certificate option MUST be constructed as
> explained in Section 10.1.2.", but I don't see any "client MUST send
> Certificate option". It's also not shown on Figure 1. Yet, the server
> section says that incoming messages without Certificate option are to be
> dropped. This should be clarified.
>
> It's a matter of preference, but I think Section 6 is too long and
> should be split into several sub-sections. When someone references it
> ("see Section 6"), it's difficult to find what specific parts of the
> text is being pointed out to.
>
> "the subsequent encrypted DHCPv6 message sent from the client can also
> contain the Increasing-number option to defend against replay attack.".
> Is there a reason why "can" is used, not SHOULD or even MUST?
>
> "If the transaction-id is 0, the client also try to decrypt it." Two
> comments about this. First, what is the client supposed to decrypt - the
> transaction-id field or the whole message? Second, what should the
> client do if it's not 0?
>
> "In this document, it is assumed that the client will not have multiple
> DHCPv6 sessions with different DHCPv6 servers using different key pairs
> and only one key pair is used for the encrypted DHCPv6 configuration
> process." That's a good text, but it doesn't belong in the place where
> it is now. It should be moved to separate paragraph or even separate
> section. You may also consider adding something like "Secure DHCPv6 can
> maintain multiple DHCPv6 sessions, but such scenario is not considered
> here for clarity reasons."
>
> "The encryption text SHOULD...". What is encryption text? Did you mean
> encrypted message or the message to be encrypted?
>
> nit: "as explain in [RFC5652]" => "as explained in [RFC5652]"
>
> "After the decryption, it handles the message as per 3315". I'm not a
> security expert by any stretch of that word, so excuse my naive
> question. Anyway, can you always detect that the decryption was a
> success or failure? Some decryption techniques will produce output, even
> when the key is incorrect, but the output will be an almost random
> garbage. Can the mechanism defined in RFC5652 always reliably conclude
> the decoding operation was success/failure? If not, I'm afraid that
> asking clients and server to decode random garbage will break some
> implementations.
>
> If the decryption algorithm cannot give definite success/fail answer,
> there's a solution I have in mind. You may add a magic cookie (a well
> known value of perhaps 4 bytes) at the beginning before encrypting the
> actual message and encrypt (cookie,message) tuple. Then the first check
> after decryption the receiver would do is to check if the first 4 bytes
> match the cookie value. If not, then throw away the whole packet without
> trying to parse any of it. I discussed the concept with Bernie and he's
> in favour of it. Also discussed with Jinmei and he's against it. Sten
> posted his comment against it, but I'm not sure if Bernie's description
> of the concept was accurate enough. Any other thoughts on this?
>
> "switch to other DHCPv6 server if it has another one." => "switch to
> other DHCPv6 server if available."
>
> The text uses "one and only one" several times. You may consider
> replacing it with "exactly one". It reads easier that way, but I admit
> it's a matter of preference, so it's just a suggestion.
>
> "The DHCPv6 server drops the message that is not for it, thus not paying
> cost to decrypt messages."
> => "The DHCPv6 server drops the message if the value of Server
> Identifier option does not match its own, thus not paying the cost of
> message decryption."
>
> "If the server cannot find the corresponding private key of the key tag
> or the corresponding private key of the key tag is invalid for
> decryption, then the server drops the received message." Shouldn't the
> server send back AuthenticationFail status? The benefit is that the
> client could try again and use a different certificate.
>
> "For the signature failure, the server SHOULD send an encrypted Reply
> message with an UnspecFail (value 1, [RFC3315]) error status code to
> the client." Why use UnspecFail, if there's SingatureFail code for it?
>
> General comment: "cert" should be replaced with "certificate". Even
> though everyone understands this jargon, it should be avoided in formal
> documents.
>
> Section 9.1:
> nit: "The server should keep a record of the increasing number forever."
> Nothing is eternal, so I don't like the word forever. It would be better
> to say the server must be able to retain the increasing number across
> restarts.
>
> Remove "And " at the beginning of two sentences in first paragraph.
>
> Section 9.2:
> Thanks a lot for including the code. It's very helpful. However, please
> update the comments that mention RDATA, DNSKEY RR and RDLENGTH. That way
> fewer people will realized where it was borrowed from :)
>
> Nit: some of the values to be assigned by IANA are boilerplated as
> TBD[number] and some as TBA[number]. Typically it's TBD[number].
>
> Section 10.1.1
>
> The text describing EA-id List could use an update. First, it's not
> clear what EA stands for (it is explained further down, but requires a
> bit of hopping around the text). I would replace "EA-id: The format of
> the EA-id List field is shown in Figure 3." with "EA-id List: Contains a
> list of supported Encryption Algorithm identifiers. The format of the
> EA-id List field is shown in Figure 3." Similar text should be added for
> SHA-id List ("Contains a list of supported Signature/Hash Algorithm
> pairs.").
>
> Nit: I'm not sure, but it looks like you put the whole description of
> EA-id into the Figure 3. It's better to have it as text outside of
> Figure. That's probably also one of the reasons why idnits is unhappy.
>
> 10.1.2
> "The Certificate option carries the certificate of the client/server,
> which is contained in the Reply message." This is confusing. I could
> easily misinterpret this as "server is supposed to send client
> certificate in Reply message" or even "Client can send Reply message
> with a certificate". It would be better to say "The Certificate option
> carries the certificate of the sender. It can be included by the client
> (see Section 6) and by the server (see Section 7)." Also, see my earlier
> comment about Section 6 not explicitly saying if/when the Certificate
> option is to be sent.
>
> Sections 10.1.*
> As a convenience to the reader, I would add a text similar to "The
> Algorithm option is sent by the client, as described in Section 6.".
> Similar texts should be added in other sections that describe the
> options. It can be confusing to understand who sends what, so such
> pointers are useful in my opinion. This applies to all sections that
> describe options.
>
> Section 10.2
> "share the following format:" => "share the standard format of DHCPv6
> messages:".
>
> Section 11
> "There are some mandatory algorithm for encryption algorithm in this
> document.  It may be at some point that the mandatory algorithm is no
> longer safe to use." => "There are some mandatory algorithms specified
> in this document.  It may be at some point that the mandatory algorithm
> is no longer safe to use. To mitigate this problem, an extension
> mechanism was defined that allows usage of new encryption, signing and
> hash algorithms."
>
> Another problem that should be mentioned is that secure traffic cannot
> be snooped by the relay agents. This is of crucial importance for
> networks that use PD and use relay snooping. It would be even more
> appropriate to create separate section called Deployment Considerations
> for it. If the RAAN draft is resurrected before sedhcpv6 reaches IESG
> (it should), adding text similar to "This issue will be addressed in
> future IETF work and add reference to
> draft-ietf-dhc-dhcpv6-agentopt-delegate).
>
> Another possible topic for discussion in deployment considerations would
> be how to do Rebind. My understanding is that it would work as long as
> both servers would use the same certificates. This explanation is buried
> deep in section 5.4, but it's probably useful to mention it explicitly
> (or have a pointer to 5.4) if you decide to create deployment
> considerations section.
>
> Section 12
> Do you (that's a broad question to the WG, not just authors) think it
> would be useful to add extra column to the new registries, specifying
> whether the protocol is mandatory, optional or deprecated? We would
> start with one mandatory in each registry and all other entries being
> optional. When new protocols are defined in the future and flaws in
> existing ones are discovered, we could publish short documents to easily
> update the current state of affairs. It would also correlate well with
> the text you have in section 11.
>
> I agree with Jinmei-san that the Confirm message problem is something
> that should be tackled. I don't have any ready to use solution for you,
> but going in the direction that Jinmei suggested (doing separate
> inf-request/reply to discover available servers) seems the best way.
>
> Finally, to answer my own question I think dhc-dhcpv6-agentopt-delegate
> should be resurrected right now, so sedhcpv6 could reference to it, when
> it discusses the issue with snooping. This is something I hope to
> discuss in couple hours during meeting.
>
> Ok, that's it.
> Tomek
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 5 Apr 2017 21:06:36 +0200

It took a little bit more than planned, but the extra time gave us a
couple more comments.

We did receive a number of in depth reviews with technical comments. In
general, several people praised the significantly improved quality and
clarity of the document. Nobody said that is opposed to this work. So
from that perspective this last call is a success.

However, both chair and at least one co-author feel that an important
concern has not been addressed yet. There currently are no known
implementations or prototypes of this draft. For a typical DHCP draft
that adds an option or two that would probably be fine, but for this
particular draft it is not. For two reasons: First, we feel that this is
an essential piece of the whole DHCPv6 ecosystem and as such require
much more scrutiny then an average draft. Second, security is a complex
matter and any unclear aspects would gravely damage the
interoperability. Jinmei had put it well: "I suspect the current spec
still has some points that are critically unclear, which you would
immediately notice once you tried to implement it."

Given that, we declare that more effort is needed before this work is
deemed ready for IESG. At the same time, chairs would like to strongly
applaud authors' efforts to improve this work. This version is
significantly better than its predecessors. Thank you for your hard
work. You are doing excellent work. Please continue.

Also, to address the concern of missing implementations, chairs would
like to announce a DHCP hackathon in Prague. Details are TBD, but the
primary goal will be to have at least two independent implementations of
that draft. The hackathon will take place the weekend before IETF
meeting (that's July 15-16). A separate announcement will be sent soon.

That is well over 3 months away. Authors and supporters of this work,
please seriously consider dedicating some of your time implementing
prototypes and attending the hackathon, if you can. If you can't we will
organize some means for participating remotely.

Thank you to the authors and to everyone who commented.

Bernie & Tomek

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Apr 2017 13:41:40 +0000

Hi,

RFC7513 seems to suggest DHCP snooping, i.e., some L2 device on the link from
the DHCP server or relay to the client examines the contents of DHCP messages.
Unfortunately, sedhcpv6 mandates encryption making snooping impossible.

Does it mean that Secure DHCPv6 will be incompatible with SAVI?

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
> Sent: Wednesday, April 05, 2017 12:07 PM
> To: dhcwg <[email-masked]>
> Cc: draft-ietf-dhc-sedhcpv6 authors <[email-masked]>
> Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary
>

---

From: Lishan Li <[email-masked]>
Date: Wed, 19 Apr 2017 21:45:56 +0800

Hi,

I have considered this problem. Yes, secure DHCPv6 is incompatible with
SAVI.
If secure DHCPv6 is implemented, SAVI cannot work well and have to be
updated.

Best Regards,
Lishan

在 2017年4月19日，下午9:41，Templin, Fred L <[email-masked]> 写道：

Hi,

RFC7513 seems to suggest DHCP snooping, i.e., some L2 device on the link
from
the DHCP server or relay to the client examines the contents of DHCP
messages.
Unfortunately, sedhcpv6 mandates encryption making snooping impossible.

Thanks - Fred

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Wednesday, April 05, 2017 12:07 PM
To: dhcwg <[email-masked]>
Cc: draft-ietf-dhc-sedhcpv6 authors <[email-masked]>
Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary

Bernie & Tomek

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Apr 2017 13:51:52 +0000

Ø  I have considered this problem. Yes, secure DHCPv6 is incompatible with SAVI.

Ø  If secure DHCPv6 is implemented, SAVI cannot work well and have to be updated.

OK, so you knew this but has it been discussed already on the lists or is
this the first time it has come up for discussion? Because this seems like
a rather significant incompatibility to me. And, when you say SAVI has
to be updated, how do you see that happening? Must the encryption keys
held by the client and/or server be shared with the L2 snooping device?

Thanks - Fred

From: Lishan Li [mailto:[email-masked]]
Sent: Wednesday, April 19, 2017 6:46 AM
To: Templin, Fred L <[email-masked]>
Cc: Tomek Mrugalski <[email-masked]>; dhcwg <[email-masked]>; draft-ietf-dhc-sedhcpv6 authors <[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary

Hi,

I have considered this problem. Yes, secure DHCPv6 is incompatible with SAVI.
If secure DHCPv6 is implemented, SAVI cannot work well and have to be updated.

Best Regards,
Lishan
在 2017年4月19日，下午9:41，Templin, Fred L <[email-masked]<mailto:[email-masked]>> 写道：

Hi,

Thanks - Fred
[email-masked]<mailto:[email-masked]>

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tomek Mrugalski
Sent: Wednesday, April 05, 2017 12:07 PM
To: dhcwg <[email-masked]<mailto:[email-masked]>>
Cc: draft-ietf-dhc-sedhcpv6 authors <[email-masked]<mailto:[email-masked]>>
Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary

Bernie & Tomek

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

---

From: Lishan Li <[email-masked]>
Date: Wed, 19 Apr 2017 22:06:00 +0800

It is the first time to be discussed.
In fact, I have no idea to update it. I just think that: The client's
private key and server's
private key is owned by themself and cannot be shared with L2 snooping
device.

However, this incompatibility cannot be the reason to stop this work.
Firstly, we can
think out some update method for SAVI. Secondly, in some scenario where
SAVI is
not deployed but DHCPv6 security needs to be protected, secure DHCPv6 can
work.

Best Regards,
Lishan

2017-04-19 21:51 GMT+08:00 Templin, Fred L <[email-masked]>:

> *From:* Lishan Li [mailto:[email-masked]]
> *Sent:* Wednesday, April 19, 2017 6:46 AM
> *To:* Templin, Fred L <[email-masked]>
> *Cc:* Tomek Mrugalski <[email-masked]>; dhcwg <[email-masked]>;
> draft-ietf-dhc-sedhcpv6 authors <[email-masked]>
> *Subject:* Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary
>
>
>
> Hi,
>
>
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Apr 2017 10:46:59 -0400

It might be worth evaluating how commonly SAVI is deployed in practice before becoming concerned about this.   Also, since SAVI actually solves some of the same problems as sedhcpv6, it seems reasonable to think that the availability of two incompatible solutions may still result in more overall win.   A way to address this in the document would be to simply say that at present, the two approaches solve related problems but are mutually incompatible, so the choice must be made between one and the other.

This is also not a very serious problem in the sense that RFC 7513 proposes a DHCPv6-only address configuration model, which is not very common in practice.   In practice, SAVI First Come First Served (RFC 6620) should be compatible with secure DHCPv6, and will generally produce better results.

For sites that want absolute control over address assignment through a DHCP server, the options are either to not use Secure DHCPv6, or to implement an updated SAVI that would have to be written up that takes the assigned IP address out of the un-signed wrapper, or else uses layer 2 relay in combination with putting the IP address in the relay wrapper, as you've been advocating, Fred.

---

From: Lishan Li <[email-masked]>
Date: Fri, 21 Apr 2017 16:26:16 +0800

Hi, Tomek,

Thanks a lot for the valuable comments. Sorry for the late reply. For some
general issue, I will start a new session for discussion. For the other
easy issues, please see inline.

Best Regards,
Lishan

> I like section 5, especially 5.1 and 5.2 a lot. It's a great two-page
[Lishan]: Ted rewrite the text of Section 5.1 and 5.2. So it is clear
and easy to read.

> because signature is missing, multiple signatures or certificate missing).
[LS]: The increasing-number option is first sent by the Reply message.
And the client checks it. If the client does not store it, then we assume
that the initial value is zero, then the check will success.

> dropped. This should be clarified.
[LS]: Will clarify it.

> text is being pointed out to.
[LS]: Agree.

> Is there a reason why "can" is used, not SHOULD or even MUST?
[LS]: Increasing-number is optional. change "can" to "SHOULD".

> transaction-id field or the whole message? Second, what should the
[LS]: The client will not check the transaction-id. For all the
transaction-id,
the client will try to decrypt it.

> here for clarity reasons."
[LS]: Agree.

> encrypted message or the message to be encrypted?
[LS]: I mean the encrypted text. Will explain it more clear.

> asking clients and server to decode random garbage will break some
[LS]: I also don't know much about it. For the general security issues,
will consult Randy Bush or Stephen Farrall for their guidance.

> of the concept was accurate enough. Any other thoughts on this?
[LS]: I think it is a general secure issue. And we can consult some
security
expert.

> client could try again and use a different certificate.
[LS]: In these scenarios, decryption fails. In this way, the server cannot
recognize which client. And it is difficult for the server to send the
AuthenticationFail
status code.

> [LS]: Bernie has given the same comments. Will modify it.

> draft-ietf-dhc-dhcpv6-agentopt-delegate).
[LS]: After the IETF meeting, we will add the reference of it.

> (or have a pointer to 5.4) if you decide to create deployment
[LS]: Will have a pointer to 5.4

> the text you have in section 11.
[LS]: Agree.

> inf-request/reply to discover available servers) seems the best way.
[LS]: Will discuss it in another session.

> Thanks again,
Lishan