Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 2 May 2014 12:33:53 +0000

Jinmei:

Thanks for your review and feedback.

Regarding your first point, there's probably nothing (except the option length limitations, though RFC 3396 handles that) that would prevent this from being adopted for DHCPv4. But it is indeed a question of whether advancing DHCPv4 is as important as advancing DHCPv6. Also, the DHC WG charter is focused on DHCPv6.

If this work does advance, and there's sufficient interest, I could well see someone proposing the same for DHCPv4.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of ????
Sent: Wednesday, April 30, 2014 1:30 PM
To: Tomek Mrugalski
Cc: dhcwg
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

At Tue, 29 Apr 2014 20:21:33 +0200,
Tomek Mrugalski <[email-masked]> wrote:

> Since we have upcoming holiday on May 1st (which happens to be a 
> reason for extended weekend in many parts of Europe) and the topic in 
> question is not trivial, this WGLC is a bit longer than usual.
>
> Please send your comments by May 18th 2014. If you do not feel this 
> document should advance, please state your reasons why.

I've read the document.  I don't have a particular opinion on whether it should advance, mainly because I'm not a security expert.  I have some comments that may hopefully be useful, though:

Some higher level points
- (maybe already discussed before but) the concept of using public key
  authentication in DHCP makes some sense to me, but I wonder why we
  are discussing this specifically for DHCPv6.  As far as I know
  there's no such counterpart in DHCPv4 (the only related thing I can
  google is draft-gupta-dhcp-auth-02.txt, which expired long ago), am
  I correct?  If so, is that because *v4 is just too legacy and isn't
  worth improvements anymore?  Or does that reflect some DHCP specific
  points that make public key authentication not so viable?  If it's
  the latter, doesn't it also apply to this proposal?

- The description of the draft is a bit vague (which may have to be
  clarified anyway), but if I understand it correctly, it assumes that
  both clients (each of them) and servers maintain their pair of
  public-private keys, and a client offers and uses its own key to
  authenticate messages from the client to servers.  Is that correct?
  If so, does this make sense?  My general understanding is that
  authenticating DHCP messages from clients to server is not that
  critical, and it's quite unlikely that servers maintain public keys
  of all possible clients so the servers would have to rely on the
  leap-of-faith model.  They then may have to worry about the
  "resource exhaustion attacks" (although I'm not sure if this is a
  big issue, see below).

Other non editorial comments on the draft:
- Section 5.1:
   Public Key     A variable-length field containing public key. The
                  key MUST be represented as a lower-case hexadecimal
                  string with the most significant octet of the key
                  first. Typically, the length of a 2048-bit RSA

  Is there any specific reason it's represented as a string?  Not
  necessarily bad, but I thought more common practice here is to
  simply use the binary value of the key.  DHCP options in wire format
  are not expected to be human readable anyway, so I don't see the
  point for using a string here.

- In Section 6.2:

   On the recipient that supports the leap of faith model, the number of
   cached public keys or unverifiable certificates MUST be limited in
   order to protect against resource exhaustion attacks.  If the

  This is mainly concerned about servers, correct?  If so, I'm not
  sure how severe this "attacks" are; DHCP servers generally need to
  maintain some state for each client (unless that's stateless only
  server) and would naturally already have some limitation on that
  resource.  Shouldn't the general defense be enough for this
  particular resource, too?  (But I was also not sure if it makes
  sense to use (public key) authentication for messages from clients
  in the first place; see higher-level discussions above)

- Related, it seems some part of Section 6.2 is more specific for
  clients and some other part is more specific to servers.  So it may
  be helpful if we have separate subsections focusing on these
  particular cases.  Just a suggestion.

Editorial nits:
- Section 4.3
   they may fall back the unsecure model, if both client and server
  s/fall back the/fall back to the/
  (I found the missing 'to' of this kind in several other places in
  the draft)

- Section 4.3
   whether to accept the messages.  If the client accept the unsecure
   messages from the DHCPv6 server.  The subsequent exchanges will be in
   unsecure model.
  s/server.  The/server, the/

- Section 4.3
   on the server policy.  If the server mandidates the authentication,
  s/mandidates/mandates/

- Section 6.1
   messages, MUST contain either a the Public Key or Certificate option,
  s/a the/the/ (?)

- Section 6.2
   error status code, defined in Section 5.4, back to the client..
  s/.././

--
JINMEI, Tatuya

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

---

From: Ralph Droms <[email-masked]>
Date: Fri, 2 May 2014 09:18:11 -0400

On May 2, 2014, at 8:33 AM 5/2/14, Bernie Volz (volz) <[email-masked]> wrote:

> Regarding your first point, there's probably nothing (except the option length limitations, though RFC 3396 handles that) that would prevent this from being adopted for DHCPv4.

If I recall correctly, similar protocols have been considered in the past for DHCPv4.  Those protocols were not developed because of concerns about the length of individual options and the total length of all of the options (certs can get big) combined with concerns about whether deployed DHCPv4 infrastructure (relay agents) would correctly handle large DHCPv4 messages.

> But it is indeed a question of whether advancing DHCPv4 is as important as advancing DHCPv6. Also, the DHC WG charter is focused on DHCPv6.

Yup.

I would like to see some consideration of the total length of DHCPv6 messages that use this security protocol included in the document.

- Ralph

---

From: 神明達哉 <[email-masked]>
Date: Fri, 2 May 2014 09:43:17 -0700

At Fri, 2 May 2014 09:18:11 -0400,

--
JINMEI, Tatuya

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 6 May 2014 03:54:31 +0000

Hi all,

I support advancing this draft.

Best regards,
Bing

> From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek
> Mrugalski
> Sent: Wednesday, April 30, 2014 2:22 AM
> To: dhcwg
> Subject: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18
> 
> Hi all,
> 
> This message starts DHC working group last call about advancing Secure
> DHCPv6 with Public Key document as a Standards Track RFC. The authors
> believe that this version addressed all the issues raised and is ready.
> 
> The draft is available here:
> http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-02
> 
> Since we have upcoming holiday on May 1st (which happens to be a reason
> for extended weekend in many parts of Europe) and the topic in question is
> not trivial, this WGLC is a bit longer than usual.
> 
> There are no IPR claims reported at this time.
> 
> Tomek Mrugalski is the document shepherd.
> 
> Bernie & Tomek
>

---

From: Declan Ma <[email-masked]>
Date: Tue, 6 May 2014 14:04:54 +0800

Over the years, rogue DHCP servers have been gripping the security of access network a lot.

By employing PKI, sedhcpv6 is going to offer a widely applicable method, with which DHCPv6 service can be provided securely.

I am in favor of advancing this document.

Declan Ma
Internet Domain Name System Beijing Engineering Research Centre (ZDNS)

在 2014年4月30日，上午2:21，Tomek Mrugalski <[email-masked]> 写道：

> for extended weekend in many parts of Europe) and the topic in question
> is not trivial, this WGLC is a bit longer than usual.
>

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 6 May 2014 06:33:14 +0000

Hi, Jinmei & Bernie,

We do have a plan to extend this to DHCPv4. We are going to submit an individual 00 version before the next IETF meeting. However, the secure DHCPv6 is in our priority for now. :)

Best regards,

Sheng + Dacheng

>From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
>Sent: Friday, May 02, 2014 8:34 PM
>To: 神明達哉; Tomek Mrugalski
>Cc: dhcwg
>Regarding your first point, there's probably nothing (except the option length
>limitations, though RFC 3396 handles that) that would prevent this from being
>adopted for DHCPv4. But it is indeed a question of whether advancing
>DHCPv4 is as important as advancing DHCPv6. Also, the DHC WG charter is
>focused on DHCPv6.
>
>I've read the document.  I don't have a particular opinion on whether it
>should advance, mainly because I'm not a security expert.  I have some
>comments that may hopefully be useful, though:
>
>Some higher level points

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 6 May 2014 07:00:19 +0000

>I would like to see some consideration of the total length of DHCPv6
>messages that use this security protocol included in the document.

Hi, Ralph,

We could give consideration of the total length of DHCPv6 messages in the current draft. The message length are variable because there are few variable field in the message, such as public key/certificate & signature, etc. We expect the length of the message should not exceed the maximum length of UDP packet.

However, we do NOT see reasons why this would be a problem. Could please you share your concerns with us? So that, we can better address the consideration.

Regards,

Sheng + Dacheng

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 6 May 2014 07:36:34 +0000

Hi, Jinmei,

Thanks for your email. Replies in lines.

>  the latter, doesn't it also apply to this proposal?

Replied in another email, too. We do have a plan to extend in DHCPv4. However, it would be in lower priority for us and for WG.

>  point for using a string here.

We borrow the ideas from multiple other security mechanisms such as rfc 7210. But your concern makes sense. We will change this according to your point.

>  particular resource, too?  

The "MUST" here seems not proper. Let us replace is with "MAY". It makes this point optional and should address your concern.

>Editorial nits:

Editorial nits will be fixed. :)

Best regards,

Sheng + Dacheng

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 6 May 2014 11:24:18 +0000

I suspect some of the issues here are:
1. Because socket interfaces are typically used, how large a buffer should clients, relays, and servers support? (Yes, it is possible to ask the socket layer about how large a received packet is, but that requires two socket calls and I suspect is rarely done.) 
2. If packets do exceed the MTU of the interface, fragmentation is required. As this is link-local (at least for first hop), probably not a big issue but does require fragmentation support (again, probably not a big issue except if it was perhaps boot prom code - but why that would be using sedhcpv6 is unclear). Fragmentation for relay to server communication MIGHT be an issue if the traffic traverses firewalls?
3. As PMTU is harder with UDP traffic, it isn't clear how the fragmentation MTU can easily be found. This may require clients, relays, and servers to support PMTU and be prepared for failures. Remember that with IPv6, fragmentation is done by the end points - not the intermediate hops.

These issues aren't new, but they are more likely when sedhcpv6 is being used because we expect some of these options could be rather large (i.e., carrying certificates) and thus more likely require fragmentation.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Sheng Jiang
Sent: Tuesday, May 06, 2014 3:00 AM
To: Ralph Droms; Bernie Volz (volz)
Cc: dhcwg; 神明達哉
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

Hi, Ralph,

Regards,

Sheng + Dacheng

>- Ralph
>
>>
>> If this work does advance, and there's sufficient interest, I could 
>> well see
>someone proposing the same for DHCPv4.
>>
>> - Bernie
>>
>>> reason for extended weekend in many parts of Europe) and the topic 
>>> in question is not trivial, this WGLC is a bit longer than usual.
>>>
>> - (maybe already discussed before but) the concept of using public 
>> key  authentication in DHCP makes some sense to me, but I wonder why 
>> we  are discussing this specifically for DHCPv6.  As far as I know  
>> s/fall back the/fall back to the/  (I found the missing 'to' of this 
>> kind in several other places in  the draft)
>>
>> - Section 4.3
>>   messages, MUST contain either a the Public Key or Certificate 
>> option,  s/a the/the/ (?)
>>
>> - Section 6.2

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 May 2014 07:25:54 -0500

> The "MUST" here seems not proper. Let us replace is with "MAY". It makes this point optional and should address your concern.

This is really implementation advice, so perhaps it doesn't need to be normative.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 6 May 2014 10:15:41 -0400

Sheng, Dacheng - Sorry, I missed you earlier response.

There is no fundamental reason that fragmenting DHCPv6 traffic won't work, but, historically, DHCP fragmentation has been avoided and fragmentation is usually avoided in IPv6 traffic.

I think Bernie has the right set of issues.  There may be more.

- Ralph

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 7 May 2014 01:15:23 +0000

Hi, Bernie & Ralph,

We did realize the issues you mentioned. However, we thought they were not relevant. For three reasons, A, as protocol designing, there is no much we can do to shorten the DHCP message; B, most of issues are relevant with specific under-layer transmit mechanism, which is not specific for DHCPv6 protocol. It should be the implementation of under-layer transmit to make it work. C, most of issues exist in some specific deployment scenarios. They may not be the majority. They are deployment issues, rather than protocol design level issues.

For us, there is no much we could or should do in the document. It seems reasonable to give some deployment consideration in the document by just saying: SeDHCPv6 message is commonly large. IP fragments are highly possible. Hence, deployment of SeDHCPv6 should also consider the issues of IP fragment, PMTU, etc.

Regards,

Sheng

>From: Ralph Droms [mailto:[email-masked]]
>Sent: Tuesday, May 06, 2014 10:16 PM
>To: Sheng Jiang; Bernie Volz (volz)
>Cc: dhcwg; 神明達哉
>There is no fundamental reason that fragmenting DHCPv6 traffic won't work,
>but, historically, DHCP fragmentation has been avoided and fragmentation is
>usually avoided in IPv6 traffic.
>
>> 1. Because socket interfaces are typically used, how large a buffer should
>clients, relays, and servers support? (Yes, it is possible to ask the socket layer
>about how large a received packet is, but that requires two socket calls and I
>suspect is rarely done.)
>> 2. If packets do exceed the MTU of the interface, fragmentation is required.
>As this is link-local (at least for first hop), probably not a big issue but does
>require fragmentation support (again, probably not a big issue except if it was
>perhaps boot prom code - but why that would be using sedhcpv6 is unclear).
>Fragmentation for relay to server communication MIGHT be an issue if the
>traffic traverses firewalls?
>> 3. As PMTU is harder with UDP traffic, it isn't clear how the fragmentation
>MTU can easily be found. This may require clients, relays, and servers to
>support PMTU and be prepared for failures. Remember that with IPv6,
>fragmentation is done by the end points - not the intermediate hops.
>>
>> These issues aren't new, but they are more likely when sedhcpv6 is being
>used because we expect some of these options could be rather large (i.e.,
>carrying certificates) and thus more likely require fragmentation.
>>
>> - Bernie
>>
>> We could give consideration of the total length of DHCPv6 messages in the
>current draft. The message length are variable because there are few variable
>field in the message, such as public key/certificate & signature, etc. We
>expect the length of the message should not exceed the maximum length of
>UDP packet.
>>
>> However, we do NOT see reasons why this would be a problem. Could
>please you share your concerns with us? So that, we can better address the
>consideration.
>>
>> Regards,
>>
>> Sheng + Dacheng
>>
>>> - Ralph
>>>
>>>>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 7 May 2014 07:23:20 -0400

Zheng, Dacheng - I don't think any changes to the protocol are required.

However, this extension to DHCPv6 may result in DHCPv6 messages that are much larger than current messages (and are much larger than the original designers of DHCP generally anticipated).  It may require the use of IPv6 fragmentation, which is not widely used and which introduces some potential problems with UDP transport.  Therefore, I think it would be prudent to add some explicit analysis and notice to implementors and deployers of this extension about the issues around large DHCPv6 messages.

- Ralph

> On May 6, 2014, at 9:15 PM, Sheng Jiang <[email-masked]> wrote:
> 
> Hi, Bernie & Ralph,
>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 7 May 2014 08:35:14 -0700

At Tue, 6 May 2014 07:36:34 +0000,

> The "MUST" here seems not proper. Let us replace is with "MAY". It makes this point optional and should address your concern.

I don't think my main point is MUST vs MAY.  It's about a more
general point of authenticating messages from clients to servers:

- whether we really need (public key) authentication in that
  direction, and if we do, why

- also if we do, what's the commonly expected model of "trust anchor":
  leap of faith or use of CA or something else, and if it's more
  likely to be a weaker model like leap of faith (I suspect so, for
  the direction of clients to servers), whether the motivation (1st
  bullet) is worth the weaker security

- and, if it's more likely to rely on leap of faith, what kind of
  consideration is needed

The discussion on caching the public keys is just a part of the third
bullet.  What I'm missing in the current draft is more comprehensive
and higher level discussions on all of these points.  It's far from
obvious to me compared to authenticating messages from servers to
clients.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 7 May 2014 08:57:26 -0700

At Wed, 7 May 2014 07:23:20 -0400,

> However, this extension to DHCPv6 may result in DHCPv6 messages that are much larger than current messages (and are much larger than the original designers of DHCP generally anticipated).  It may r…

I agree.

One specific point: newer DHCPv6 implementations that support this
protocol would have to use the IPV6_USE_MIN_MTU socket option (or
something equivalent to it), for exact the same kind of reason why all
modern DNS server implementations use it on UDP sockets.  I've quickly
checked a few open source implementations, and found none of them use
this option right now.  I'm not sure whether this draft should be as
specific as to mention that particular socket option, but at least
some higher level notes to implementors would be very helpful to avoid
surprise beforehand.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 7 May 2014 16:05:55 +0000

I agree with Jinmei and Ralph that this packet size should be mentioned in the document.

I think explicitly mentioning IPV6_USE_MIN_MTU socket option as an EXAMPLE (i.e., e.g.) would be a good idea. Makes it easier for all to find this particular feature (and possibly map it to whatever stack they are using).

At least from the one description of this that I found it looks to be exactly what you want:

"A value of 1 enables this option for unicast and multicast destinations. All packets are sent without using path MTU discovery information, using the minimum MTU size, unless a direct route is available to the destination."

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Wednesday, May 07, 2014 11:57 AM
To: Ralph Droms
Cc: Sheng Jiang; dhcwg; Bernie Volz (volz)
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

I agree.

One specific point: newer DHCPv6 implementations that support this protocol would have to use the IPV6_USE_MIN_MTU socket option (or something equivalent to it), for exact the same kind of reason why all modern DNS server implementations use it on UDP sockets.  I've quickly checked a few open source implementations, and found none of them use this option right now.  I'm not sure whether this draft should be as specific as to mention that particular socket option, but at least some higher level notes to implementors would be very helpful to avoid surprise beforehand.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 May 2014 11:25:08 -0500

On May 7, 2014, at 10:57 AM, 神明達哉 <[email-masked]> wrote:
> modern DNS server implementations use it on UDP sockets.

What reason is that?

---

From: 神明達哉 <[email-masked]>
Date: Wed, 7 May 2014 09:49:13 -0700

At Wed, 7 May 2014 11:25:08 -0500,

> > modern DNS server implementations use it on UDP sockets.

To avoid packet drop (+ ICMPv6 too big, which would normally be
ignored for UDP) at an intermediate router when you send a large DNS
(or DHCPv6) message.  In case of DNS, DNSSEC made it more critical.
In case of DHCPv6, sedhcpv6 would make it more critical.  But, on
thinking it in more detail, I realized I made the discussion too simplified
(maybe you were trying to point it out?).  For DHCPv6 we'll need to
discuss some more details:

- If the client only multicasts a message (to servers or relays), at
  least the client does not have this issue (but see the third bullet)
- So it's more about between servers and relays in practice.  In
  particular, since relays are not expected to be aware of sedhcpv6
  options, the implication will be less obvious for them and would be
  worth documenting explicitly.
- Even a client could unicast messages directly to a server after
  receiving the Server Unicast option, so it would still matter for
  clients in some rare cases.
- Regarding the similarity between DNS and DHCPv6, there's one
  important difference between them: in the case of DHCPv6 links (and
  MTUs) over which packets go would be less heterogeneous, so the risk
  of the drop due to this would be much smaller in practice (but that
  doesn't mean we can ignore it completely, so I think it's still
  worth discussing).

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 7 May 2014 17:11:26 +0000

Also, don't forget that unicast is possible for DHCPv6 (at the server's discretion) :).

Do we see any harm in using IPV6_USE_MIN_MTU?

If there is hop-by-hop communication (i.e., "direct route"), at least per the documentation I found the MTU of the interface is used (i.e., "direct route"). I guess if relay <-> server or relay <-> relay communication requires intermediate router hops, PMTU could apply as there are likely few end-points involved in the communication (just not sure how well PMTU works for UDP).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Wednesday, May 07, 2014 12:49 PM
To: Ted Lemon
Cc: dhcwg; Ralph Droms; Bernie Volz (volz)
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

At Wed, 7 May 2014 11:25:08 -0500,
Ted Lemon <[email-masked]> wrote:

> > something equivalent to it), for exact the same kind of reason why 
> > all modern DNS server implementations use it on UDP sockets.
>
> What reason is that?

To avoid packet drop (+ ICMPv6 too big, which would normally be ignored for UDP) at an intermediate router when you send a large DNS (or DHCPv6) message.  In case of DNS, DNSSEC made it more critical.
In case of DHCPv6, sedhcpv6 would make it more critical.  But, on thinking it in more detail, I realized I made the discussion too simplified (maybe you were trying to point it out?).  For DHCPv6 we'll need to discuss some more details:

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 May 2014 13:45:13 -0500

> Do we see any harm in using IPV6_USE_MIN_MTU?

I would like to hear a description of the actual benefit it would confer.   I suspect there is none.   I can't find any documentation for the option using google, and the only discussion I find about it is in relation to BIND 10.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 7 May 2014 18:51:16 +0000

Here's some documentation from IBM (google found this - 2nd in list when searching for IPV6_USE_MIN_MTU):

http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.hale001%2Fipv6d0151000614.htm

There are plenty of other links -- About 10,100 results (0.25 seconds).

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 May 2014 14:07:58 -0500

> Here's some documentation from IBM (google found this - 2nd in list when searching for IPV6_USE_MIN_MTU):

Ah, thanks.   That took so long to load when I tried it that I gave up, but I waited this time and got the info.

I think this option is not only unnecessary, but harmful, when used with DHCP, because it sets the maximum DHCP message size to 1280 when in nearly every conceivable circumstance, the path MTU will be at least 1500.

The reason why you might want to enable this option for DNS is that you really care about latency on DNS queries, and waiting for PMTU discovery increases latency.   No such problem exists for DHCP: the initial packet is _always_ multicast by the client, and that's the only one where we care about latency.   There's no latency for the client because it knows the path MTU--it's the link MTU.   There may be occasional latency on the relay agent, but it is amortized over many clients, and hence not really a problem.   It's unlikely that the same client will pay the latency tax twice.

Unicast queries only happen at renewal time.   At renewal time, latency is immaterial: you already have a configuration―you're just refreshing it, so nothing is blocked waiting on the response.

So I see no beneficial use case for this, and many harmful use cases.   We should be advising implementors _not_ to use this option, not advising them _to_ use it.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 7 May 2014 19:14:35 +0000

Ted:

1. There is client unicast. Though not sure how much it is used.
2. From my understanding (at least from the IBM documentation), if the destination is local to link (i.e. client multicast), the link's MTU is used (not the min MTU). So this still benefits client multicast and most of the communication in DHCPv6 to use the FULL link's MTU.

So the only case is when the next hop (again, either relay<->relay or relay<->server or client/server unicast cases where the next-hop isn't local to the link), will the 1280 MTU be used and result in fragmentation.

I don't know who well PMTU works these days for UDP and how widely it is implemented in the common stacks. If it works great, then maybe this option is unnecessary (as the components must likely to need them are probably on 'good' stacks - relays and servers that implement PMTU).

I am taking a sample of one (the IBM documentation) and perhaps there is other information that says this option doesn't work well.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 May 2014 14:28:38 -0500

> 1. There is client unicast. Though not sure how much it is used.

You may have missed the point in my message where I addressed that.   Since unicast _only_ happens on renewal, there is no latency issue.

> 2. From my understanding (at least from the IBM documentation), if the destination is local to link (i.e. client multicast), the link's MTU is used (not the min MTU). So this still benefits client…

Sure, but in that case it just doesn't matter.

> I don't know who well PMTU works these days for UDP and how widely it is implemented in the common stacks. If it works great, then maybe this option is unnecessary (as the components must likely to…

PMTU discovery is necessary for IPv6.   If the host stack doesn't support it, it's broken and needs fixed.   I have not heard of any cases of this.   Middlebox brokenness is an issue when packets cross networks that are not controlled by the operator.   That's not the case for DHCP.   So I don't think we need to be concerned about this.   This is another difference between DHCP and DNS.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 7 May 2014 19:36:53 +0000

I wasn't concerned with latency itself - except for the big one ... being able to get the packets through at all.

If PMTU for UDPv6 is always done and works great - then there is no issue as PMTU should work it out.

> Middlebox brokenness is an issue when packets cross networks that are not controlled by the operator.   

If that is the case, then PMTU or using MIN MTU does not help us. We must assume that this is not the case (if we are to use larger packets).

Or, perhaps we need a relay to relay <-> relay / server TCP (STCP, ...) packet delivery capability :).

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 May 2014 14:41:50 -0500

There are two ways to do PMTU discovery.   One is to just send the packet, and if we get an ICMP Packet Too Big packet back, we set the path MTU to the reported size and try again.   The other is to detect it in the application layer protocol.   In this case, that would be DHCP, probably the DHCP relay agent and server.   This would be necessary in the case of a firewall that drops ICMP Packet Too Big messages.

I think it would make sense to add a recommendation in 3315bis that operators configure their firewalls to pass ICMP Packet Too Big messages.   I don't think we should go any further than that.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 7 May 2014 19:52:37 +0000

It is interesting that Jinmei raised this issue given the following presentation he gave:

http://www.v6.wide.ad.jp/Presentations/ietf49-udpapp.pdf

"- But ... At least every BSD kernel always performs PMTU discovery.
 - not necessary if we can always rely on the kernel’s behavior."

I do agree that the DNS problem is different because (a) there may not be many attempts per 'transaction' so working out the PMTU can be difficult and (b) there could be LOTS of end-points and that may exceed the kernel's cache by the time a request comes around again.

So, I guess best to just rely on the Kernel PMTU support.

Getting back to this draft, I think pointing out that this can result in large packets and that for some communication (relay <-> relay/server, client/server unicast), PMTU support is critical. And, that where packets are larger than the v6 min mtu (1280), firewalls in the DHCPv6 communication path that drop fragments must not be used.

We can consider your request in 3315bis - I created http://trac.tools.ietf.org/group/dhcpv6bis/ticket/92.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 May 2014 14:59:24 -0500

Yup.

Yup.

> We can consider your request in 3315bis - I created http://trac.tools.ietf.org/group/dhcpv6bis/ticket/92.

Thanks.

BTW, reading Jinmei's excellent presentation, he does say one thing that contradicts what I said, and I would assume that he is correct and I am wrong: if you send a UDP Packet and get an ICMP too big back, the kernel doesn't retransmit.   So this would result in a retransmission on the DHCP side.   DHCP does retransmit, so this is okay, but it's worth being clear about it.

We _could_ consider defining a PMTU discovery mechanism at the application layer for DHCPv6, but I think we should wait until someone comes to us and says "we are having a problem" before doing so.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 7 May 2014 13:25:58 -0700

At Wed, 7 May 2014 14:07:58 -0500,
Ted Lemon <[email-masked]> wrote:

> I think this option is not only unnecessary, but harmful, when used with DHCP, because it sets the maximum DHCP message size to 1280

why?  This option just makes the message (however big it is) to be
fragmented at 1280 bytes.

> The reason why you might want to enable this option for DNS is that
> you really care about latency on DNS queries, and waiting for PMTU
> discovery increases latency.   No such problem exists for DHCP

Hmm, I thought many kernel implementations don't trust an incoming too
big message unless it has a corresponding connected socket to avoid
resource exhaustion DoS and PMTU discovery didn't work well for non
connected sockets (often the case for UDP applications).  But more
recent implementations seem to be smarter than that, allowing such
messages with some limitation.  So, in the end, it seems I was wrong:
as you said this option won't be necessary for DHCPv6 (still not sure
if it's "harmful" though as stated above, but that's not important at
this point).

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 May 2014 15:33:42 -0500

On May 7, 2014, at 3:25 PM, 神明達哉 <[email-masked]> wrote:
> So, in the end, it seems I was wrong:

I may have overstated the point.   Fragmentation is messy and presents an attack surface, so I suspect it's considered even less safe to pass through firewalls than ICMP Packet Too Big messages.   But you're right that it's not quite at the level of "harmful" to rely on it.

In any case, thanks for raising this.   I think it's a useful discussion.

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 8 May 2014 01:16:24 +0000

>> Getting back to this draft, I think pointing out that this can result in large
>packets and that for some communication (relay <-> relay/server,
>client/server unicast), PMTU support is critical. And, that where packets are
>larger than the v6 min mtu (1280), firewalls in the DHCPv6 communication
>path that drop fragments must not be used.
>
>Yup.

Missed the discussion process due to the different of time zones. I agree the conclusion that got by the discussion. For us, there is no much we could do in protocol design aspect. But, clearly pointing out the sedhcpv6 packets are large would be very helpful for implementers and deployment. We will add some text among with other comments we received during WGLC.

Regards,

Sheng + Dacheng

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 8 May 2014 08:56:59 +0000

Hi, Jinmei,

In the common scenario that we expect, the leap of faith model is not deployed independent. In the deployment of secure DHCPv6 server, the server serves three types of clients: 1) full authenticated clients, 2) clients trusted by leap of faith model, 3) un-authenticated clients. Hence, the clients are in different class for limited resource assignment and access priority. It provides fine-grained client management.

Regards,

Sheng + Dacheng

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of 神明達哉
>Sent: Wednesday, May 07, 2014 11:35 PM
>To: Sheng Jiang
>Cc: Tomek Mrugalski; dhcwg
>> The "MUST" here seems not proper. Let us replace is with "MAY". It makes
>this point optional and should address your concern.
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 8 May 2014 09:24:23 -0700

At Thu, 8 May 2014 08:56:59 +0000,
Sheng Jiang <[email-masked]> wrote:

> In the common scenario that we expect, the leap of faith model is
> not deployed independent. In the deployment of secure DHCPv6 server,
> the server serves three types of clients: 1) full authenticated
> clients, 2) clients trusted by leap of faith model, 3)
> un-authenticated clients. Hence, the clients are in different class
> for limited resource assignment and access priority. It provides
> fine-grained client management.

I'm afraid we're on different pages...the above explanation doesn't

> >- and, if it's more likely to rely on leap of faith, what kind of

If this is because I was not clear enough, I have no idea how I can
clarify my questions further.  As I said in my very first comment on
the draft, I don't have a strong position on whether to advance the
draft, so I guess I should simply drop these points, especially if
others in the wg don't see these an issue.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 May 2014 13:30:01 -0500

>>> direction, and if we do, why

Public key authentication makes sense in both directions.   Servers may be configured to grant different access to clients that authenticate than to clients that don't.  Clients may have lists of servers that either are known to be legitimate, or that are known to have worked in the past (leap of faith).   Being able to discriminate between a good server and a rogue server using this mechanism is desirable.

>>> bullet) is worth the weaker security

This seems to be out of scope for the current document, which just specifies a mechanism for authenticating transactions given that a key is known.   It's possible that this needs to be stated more clearly.   The reason (IMHO) why it's out of scope is that there are a variety of mechanisms that might make sense and that could be implemented.   For instance, a DHCP server might give an unknown client an address in a walled garden where it could arrange to pay for service, and then its key would be known to the DHCP server and could be used to authenticate service in the future without requiring registration.

>>> - and, if it's more likely to rely on leap of faith, what kind of

You mean in terms of risk assessments?

---

From: "liuzilong8266"<[email-masked]>
Date: Fri, 9 May 2014 10:53:57 +0800

Hi,all
   I support advancing this document. And I also have some comments that may hopefully be useful, though:

-section 4
"In order to enable a DHCP client and a server mutually authenticate each other without previous key deployment"
   what does it mean by saying "without previous key deployment"? As is described in the draft, public/private key is pre-configured. This statement seems conflict against the pre-configuration of public/private key? 

"It is possible for the same public key to be used with different recipients in both modes."
 why different recipients can use same public key? Is it secure?

Thanks!

2014-05-09 

liuzilong8266 

发件人：Tomek Mrugalski <[email-masked]>
发送时间：2014-04-30 02:21
主题：[dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18
收件人："dhcwg"<[email-masked]>
抄送：

Hi all, 

Bernie & Tomek

---

From: 神明達哉 <[email-masked]>
Date: Fri, 9 May 2014 11:39:29 -0700

At Thu, 8 May 2014 13:30:01 -0500,
Ted Lemon <[email-masked]> wrote:

> Public key authentication makes sense in both directions.   Servers
> may be configured to grant different access to clients that
> authenticate than to clients that don't.  Clients may have lists of

Okay, I can see that usage.

> servers that either are known to be legitimate, or that are known to
> have worked in the past (leap of faith).   Being able to
> discriminate between a good server and a rogue server using this
> mechanism is desirable.

I have no problem with this either.

My main concern is the combination of authenticating clients with the
leap of faith model.  This model isn't suitable for the "grant
different access" usage, since anyone can pretend to be an
authenticated client with that model.

> This seems to be out of scope for the current document, which just specifies a mechanism for authenticating transactions given that a key is known.   It's possible that this needs to be stated more clearly.   The reason (IMHO) why it's out of scope is that there are a variety of mechanisms that might make sense and that could be implemented.

I'm okay with separating such discussions outside of this document.
But then I'd personally like to see a "threat analysis" document
first (covering these points), not the other way around.  As a
believer of the YAGNI principle, I personally cannot be so
enthusiastic about defining/implementing something that just *might*
make sense somewhere.  Especially so, if we need to worry about a
security impact as mentioned in the security considerations section of
the draft.

> For instance, a DHCP server might give an unknown client an address in a walled garden where it could arrange to pay for service, and then its key would be known to the DHCP server and could be used to authenticate service in the future without requiring registration.

I'm impressed with your imagination:-) Although I'm not sure if this
example is persuasive enough, I see we can come up with some
*possible* usage of client authentication with leap of faith.

> You mean in terms of risk assessments?

Considerations like the possibility of resource exhaustion attacks as
mentioned in Section 7 of the draft.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 May 2014 18:44:57 -0400

> authenticated client with that model.

You are right--I don't think there is a use case for leap-of-faith with clients.

> security impact as mentioned in the security considerations section of

We are in the awkward situation that lots of DHCP people already know what the threat models are, although I think you are correct that they have not been clearly articulated in a threat analysis document.   I think such a document would be a good idea.   However, I'm reluctant to delay this document on that basis.   It might make sense to do so, but I will leave that up to the working group to debate.

> *possible* usage of client authentication with leap of faith.

This is a pretty common use model, actually.   But nowadays we do it without authentication, using just the client identifier, or by forcing a captive portal login every session, which is really inconvenient.   I wouldn't describe this as leap-of-faith, however, since it relies on some out-of-band authentication mechanism to validate the client key before choosing to trust it.

> mentioned in Section 7 of the draft.

Leap-of-faith typically involves some kind of act of faith before trusting a key.   E.g., with ssh, that's the user saying "yes, go ahead."   I don't think you could do a resource exhaustion attack in this situation.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 12 May 2014 10:11:47 -0700

At Fri, 9 May 2014 18:44:57 -0400,
Ted Lemon <[email-masked]> wrote:

> > leap of faith model. [...]
>

Okay.

> > first (covering these points), not the other way around. [...]
>

I don't want to be a blocker for this document because of this,
either.  If the rest of the wg thinks this is sufficiently
substantial, that's fine; if not, but it's actually to be considered,
hopefully a security AD will raise a concern at the time the IESG
review; and if that's not even the case, presumably my point is not
really that important.  I'm okay with any of these possibilities.

With noting this, if I may make a specific suggestion for the draft:

- provide some specific common use cases of server authentication and
  client authentication
- provide considerations on the applicability of the leap of faith
  model for these cases.  in particular, note that there is no known
  use case for client authentication with leap of faith

These can go to the introduction or a small separate section.  And, I
believe these can be sufficiently concise to fit in the protocol
document without breaking its scope too much (and I think it's a
reasonable compromise if we don't want to delay this document for a
more formal threat analysis).

On top of these, I'd even say: client authentication with leap of
faith SHOULD NOT be used until a clear use case is identified.

And, for the security considerations section on the resource
exhaustion attacks I'd revise it so it will:

- note that as long as the above 'SHOULD NOT' is honored this should
  be less concerned because this "attack" is much less
  likely/realistic on clients.  (in other words, this is another
  reason why we should discourage the use of client authentication
  with leap of faith)

> Leap-of-faith typically involves some kind of act of faith before trusting a key.   E.g., with ssh, that's the user saying "yes, go ahead."   I don't think you could do a resource exhaustion attack…

True, but this type of "act of faith" is not very feasible for servers
since it requires human intervention (ssh itself is a proof of this).
In the case of DHCP servers, I'm actually still not sure if this is a
real threat (because they should already manage other types of
possibly stale client related resources), but if we still consider
this as a security matter, we need something else than the ssh kind of
"act of faith".  My suggestion above is one such thing.

--
JINMEI, Tatuya

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 13 May 2014 08:58:07 +0000

>> authenticated client with that model.
Ted Lemon>You are right--I don't think there is a use case for leap-of-faith with clients.

The purpose of authenticating clients with the leap of faith model is to protect the follow-up client-to-server messages, such as Confirm, Renew, Rebind, Decline, Release, Information-request messages, hence, more protection for clients.

When there is no security protection, an attacker can try to tamper the messages or generate bogus messages at the all the stages of the communication between a DHCP client and a server. For example, an attacker may send a bogus Release message, masquerading as a client, to the server. The network then deny the access from that IP address. It would actually affect the client.

After introducing leap of faith, the attack surface is narrowed. An attacker can only have changes to perform above mentioned attacks when the legal client or the legal DHCP server exchange their first pair of messages. After that, any bogus packets could be detected. So, the clients that use PK or unverifiable certificate would have more protection over legacy clients.

It has been realized that the leap of faith cannot prevent an attacker from impersonating legal clients to perform resource exhausting attacks against the DHCP server. In order to deal with this type of attack, certificate based mechanism needs to be provided. We also note that the leap of faith will consume additional memory resources of servers to remember the hash values of the public keys used by the clients. However, when using SHA-1 the length of the hash of a public key is no longer than an IPv6 address. So, we don’t think this will seriously affect the performance of the DHCP server.

Best regards,

Sheng + Dacheng

---

From: 神明達哉 <[email-masked]>
Date: Thu, 15 May 2014 10:36:47 -0700

At Tue, 13 May 2014 08:58:07 +0000,
Sheng Jiang <[email-masked]> wrote:

> The purpose of authenticating clients with the leap of faith model
> is to protect the follow-up client-to-server messages, such as
> Confirm, Renew, Rebind, Decline, Release, Information-request
> messages, hence, more protection for clients.
>
> When there is no security protection, an attacker can try to tamper
> the messages or generate bogus messages at the all the stages of the
> communication between a DHCP client and a server. For example, an
> attacker may send a bogus Release message, masquerading as a client,
> to the server. The network then deny the access from that IP
> address. It would actually affect the client.

I see what you're trying to say, and it makes some sense, but I'd like
to see more precise discussion, rather than just listing random
message types and obscuring details with a word like "such as".  For
example, I don't see (at least not immediately) what kind of
protection can be provided for Information-request in this context.
It's stateless by definition, so a forged Information-request from an
attacker doesn't break anything on other clients.

Also, I don't see the need for leap-of-faith in the case of forged
Release.  The server doesn't have to "leap" when it first sees a
client's public key since it's not for authenticating the client for
that particular request but for authenticating a possible subsequent
Release to confirm that is certainly from the client the server
originally responded to.  Also, for this purpose, the server only has
to remember the client's public key during that DHCPv6 session; it can
immediately forget the public key after that, so it doesn't have to
worry about "resource exhaustion attacks" at all.

I can see one possibility of client authentication + leap-of-faith
from the discussion so far, though: it may help prevent an attacker
from pretending to be a disconnected past client by sending a forged
Solicit (maybe with a forged public key).  If it was granted, there
might be confusion when the legitimate client comes back and tries to
establish another DHCPv6 session (I'm not sure if this inevitably
causes a security threat or could be just some confusion).  If the
server stores the original public key of the legitimate client, it can
reject the forged Solicit.  (Interesting, Solicit is not listed in the
message types you listed above).

> It has been realized that the leap of faith cannot prevent an
> attacker from impersonating legal clients to perform resource
> exhausting attacks against the DHCP server. In order to deal with
> this type of attack, certificate based mechanism needs to be
> provided. We also note that the leap of faith will consume
> additional memory resources of servers to remember the hash values
> of the public keys used by the clients. However, when using SHA-1
> the length of the hash of a public key is no longer than an IPv6
> address. So, we don’t think this will seriously affect the
> performance of the DHCP server.

Any trick to "mitigate" such a threat may be useful, but my main point
was at a more higher level: whether we should worry about this issue
in the first place: for clients this shouldn't be much concern in
practice; for sever, if we don't see the need for client authentication +
leap-of-faith, we don't have to worry about it (note that avoiding
forged Release doesn't require leap-of-faith as I noted above).  So,
only with an example like avoiding a forged Solicit explained above do
we need to worry about it.  But, right now, such a precise discussion
is totally missing in the draft and only some vague fear of a threat
is documented, which made me think whether this is really an issue or
not.  Discussions like specific "mitigation" such as the use of
fingerprint does not address this fundamental point.  I hope I'm clear
about my concern this time...

Now, with this latest understanding, I'd revise my previous specific
suggestion I described in
http://www.ietf.org/mail-archive/web/dhcwg/current/msg15524.html:

- provide a short "applicability considerations" section.  It includes
  some specific common use cases of server authentication and
  client authentication with key management:
  1. authenticating a server, mainly for clients to authenticate the
     information the server provides
  2. authenticating a client, so the server can selectively serve a
     specific client (or deny specific clients)
  3. authenticating a client, so the server can prevent an attacker
     from breaking an existing DHCPv6 session of a legitimate client.
  4. authenticating a client, so the server can prevent an attacker
     from establishing a new DHCPv6 session pretending to be a past
     legitimate client.

  For 1, both CA/preshared or leap-of-faith can be used.  The latter
  is weak in pure security point of view, but probably better than
  no protection by narrowing the attack scope.

  For 2, leap-of-faith cannot be used, since anyone can pretend to be
  a new legitimate client.

  For 3, leap-of-faith is not necessary, since the server uses the
  public key only to confirm that a subsequent message is sent from
  that client (rather than "trusting" the client in the initial
  solicit).

  For 4, both CA/preshared or leap-of-faith can be used, just like
  case 1.

And, for the security consideration on the "resource exhaustion
attacks", we'd note it matters only for cases like 4 in the
applicability categorization.  (With that clarification, we might or
might now want to mention possible mitigation, like the use of
footprint instead of full key information).

If this document is organized like this, I'll feel much more
comfortable.

--
JINMEI, Tatuya

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 30 May 2014 23:32:49 +0200

> believe that this version addressed all the issues raised and is ready.
Apologies that I didn't participate in the discussion and didn't
review this draft earlier.

<dhc co-chair hat off>
I read draft-ietf-dhc-sedhcpv6-02 and support this work. I think there's
significant value in this work. I agree with previous commenters that
the specific use cases could be described somewhere, perhaps in the
introduction section. One use case where it could be useful is a high
security network, like a military base or a R&D department that wants to
protect its secrets. This authentication could be mutual - legitimate
employers are provided with devices that have preconfigured keys and
this mechanism is an additional step in access control. On the other
hand, the employees want to make sure that they indeed connect to the
legitimate network, not a spoofed one. Another use case could be a paid
hotspot. Unknown clients are assigned a different set of
addresses/options that get them to the site where they can pay for the
service. Once the service is paid, the client becomes known and future
configuration will get him direct connection, thus bypassing annoying
login/pay portal. Having to go through the captive portal only one could
be a big advantage of this mechanism.

The server authentication could also be useful. Mobile clients can
store list of previously visited networks that are known to work.

I think it is important to add a section that enumerates those and
similar use cases. Otherwise you risk that this work will be stalled
and you'd be asked to write a separate problem statement document.

Section 1 claims that messages exchanged between relay agents and
servers are less vulnerable. That is usually true, but it is possible
for client to spoof a relay. Instead of sending plain messages,
it could send Relay-forward messages with spoofed options and
Solicit or Request inside it. I don't see any obvious attack vector
here, though.

Nitpick: I'm confused what the fourth paragraph is Section 3 is about.
It starts discussion about manual key distribution, but then explains
flaws of reconfigure key authentication. These are not really related
topics, so I think it would read better if the text was split into 2
paragraphs.

Section 4:
soltuion => solution
certificates are can be used => certificates can be used

Nitpick: The text mentions clients and DHCPv6 servers. It reads a bit
awkwardly. It should be either "DHCPv6 clients and DHCPv6 servers" or
"clients and servers". You may mention in Terminology section what
clients and servers mean and then use that shorter version throught
the text. It will just read easier.

Section 4.3 says "the DHCPv6 server (for most of known DHCPv6
implementations) would just omit or disregard unknown options and still
process the known options." Are you aware of any implementations that
do not follow this principle?

"If the client accept the unsecure messages from the DHCPv6 server.
The subsequent exchanges will be in unsecure model." Those two
sentences should be combined into one.

"If the server mandidates the authentication..." =>
"If the server's policy requires the authentication..."

Section 5.1: The Public key format is confusing. Should it be binary
data or hex? Second sentence suggests that it's hex string. 2048bit key
requires 256 bytes if sent as a binary. However, if you send it as
hex string, it requires 512 bytes. Obviously, better way is to send
it as binary, as it is size optimal.

+1 for having packet size discussion in the document. Here's my take
on it:

Section 5.2 says that the maxium certificate length is 65535 bytes.
There are other limits that would practically never allow you to put
that large option. The first soft limit is MTU of the interface, which
is typically 1500 bytes - IPv6 header size - UDP header - DHCPv6
header - size of mandatory options - size of certificate option
header. (Some may point out that the min. MTU for IPv6-capable links
is 1280, so the limit may be even lower than that). This is a "soft"
limit. If you cross it, DHCPv6 messages will get fragmented. There's
nothing in RFC3315 that forbid that, but I never saw fragmented DHCPv6
packets out in the wild and I expect that it may cause problems
(firewalls dropping fragments, simple clients not supporting
fragmentation etc.). You can get above that limit, but you'd be
walking on an increasingly exotic territory. The next limit is imposed
by Payload length in IPv6 header. Its max. value is 65535, so you need
to decrease it by mentioned UDP/DHCPv6/options headers. So even
max. UDP packet is not enough for storing the max size of the option
you propose. I'd be very interested in seeing how existing
implementations behave when they receive 64k packets. If you really
want to go above that, there are jumbograms (see RFC2675). Although I
haven't checked that, my gut feeling is that current implementations
will be puzzled when they get a jumbogram-wrapped DHCPv6 packet. Note
that the current text of section 5.2 implies that jumbograms are
required to deliver the biggest OPTION_CERT_PARAMETER option. I do not
know how big X.509 certificates can be. If they are approaching 1500
bytes, you should have a section discussing the issues I mentioned.

This document defines two mandatory algorithms: SHA-256 for hash and
RSASSA-PKCS1-v1_5 for signature. I'm not a security expert by any
means, so I'm not questioning those choices, but it would be useful if
you could include some background information why you chose those two.

Time stamp in section 3. You chose the timestamp to follow RFC5905
format (64 bit, starting 1 Jan 1900). DHCPv6 already defines a time
format (see section 9.2 in RFC3315), which unfortunately is only
32bits. NTP format has the advantage of being 64 bits, but
unnecessarily covers dates from 20th century. RFC3315 style on the
other hand begins 1 Jan 2000, but is only 32 bits. Perhaps it would
make sense to define a new format: 64 bit, starting in 2000? This is
just somthing to consider. I'm ok if you want to keep current format.

They last paragraph in 5.3 says that authentication option is not
covered. So it's unclear for me how should I calculate the digests
if both authentication and signature options are present.

Section 5.4 defines new value of status code called
NotSupportAlgorithm. The name sounds a bit awkward.
AlgorithmNotSupported sound better in my opinion. Also, its definition
says that the server does not support algorithms that the sender
(presumably the client) used. What is the opposite is true: client does
not support an algorithm that the server used? Up until now, client
never did send status codes. Is the case where client needs to
communicate this failure to the server described in the text? Also, I
think the status descriptions should be reworded to use either
server/client or sender/receiver.

Further in the same section: SignitureFail => SignatureFail. That
misspelling appears in multiple sections.

Section 6.1: which MUST contructed => which MUST be contructed

Section 6.1 "Upon receiving an AuthFailNotSupportLoF error status
code [...] the client MAY switch to other certificate or public
key if it has.  But it SHOULD NOT retry with the same certificate/
public-key." Why SHOULD NOT and not MUST NOT?

"Upon receiving a SignitureFail error status code, the client MAY
resend the message.". I have 2 issues with that. First, if the
receiver was unable to verify the signature first time, why would
retransmission fix anything? It is likely that the repeated
transmissions will also fail signature verification. Second, there
should be some clarification regarding retransmission not being
immiediate. Otherwise, you risk clients flooding the server. I think
some clarification like "upon receiving non-success status code, the
client follows normal retransmission routines defined in RFC3315"
would do the trick here.

Section 6.2: "In the failure cases, both DHCPv6 server and client
SHOULD NOT process received message, and the server SHOULD reply a
correspondent error status could, while the client does nothing."
Isn't this a configuration policy? I can imagine a case where clients
that failed authentication are still served, but they get a different
threatment (like a separate subnet with captive portal that explains
what they are supposed to do).

The paragraph that discusses leap of faith should say that specific
behavior depends on configured policy.

Section 6.4 rough synchronized clocks => roughly synchronized clocks

Section 7 "The clients may decline..." => "The clients may discard..."
('decline' has special meaning in DHCPv6 context).

Section 8: Why do you need reserved (0000) value in Hash algorithm
table?

I'd like to see a section describing key rollover. It doesn't have to
be long. Just a paragraph or two would suffice.

<co-chair hat on>
I'll chat with Bernie early next week and we'll wrap up this WGLC
shortly afterwards.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 May 2014 20:47:12 -0400

> and you'd be asked to write a separate problem statement document.

A use case can't be theoretical.   You should have an actual use for it.   So I think documenting use cases like a "high security network" is pointless.   The point of this mechanism is to authenticate DHCP transactions in both directions using public keys.   Why do we need a list of use cases for this?   This is something we've been asked for for over a decade.   Does someone seriously think there's a different way to do this that's more appropriate?   If so, please explain!   Does someone think that the actual uses documented in the draft won't work?   If so, please say why.

I certainly think that if people want to suggest ways of clarifying the document, that would be beneficial, but let's not get carried away throwing the kitchen sink into the document for no good reason.   That makes it slower to review and is as likely to generate controversy as quell it.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 30 May 2014 20:57:12 -0400

> A use case can't be theoretical.   You should have an actual use for it.   So I think documenting use cases like a "high security network" is pointless.   The point of this mechanism is to authenti…

In my opinion, there is a need in the document for an applicability statement that gives guidance about what this mechanism provides and in what situations it is useful.  I have come to this opinion because a precise understanding of exactly what the protocol will provide will be important to those considering its deployment.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 May 2014 20:58:52 -0400

> In my opinion, there is a need in the document for an applicability statement that gives guidance about what this mechanism provides and in what situations it is useful.  I have come to this opinio…

Isn't it applicable in any case where you want to authenticate the other endpoint that you are communicating with?   Are there use cases where you want that but this mechanism wouldn't be the right mechanism?

---

From: Ralph Droms <[email-masked]>
Date: Fri, 30 May 2014 21:09:55 -0400

> Isn't it applicable in any case where you want to authenticate the other endpoint that you are communicating with?   Are there use cases where you want that but this mechanism wouldn't be the right…
My concern is that the RFC should be clear that authenticating the other endpoint isn't always enough, or can't be used in some situations.  Authenticating messages from a malicious server doesn't do much good.  I don't see how this mechanism could be used in an open network situation like at your local coffee chain shop.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 May 2014 21:22:42 -0400

> My concern is that the RFC should be clear that authenticating the other endpoint isn't always enough, or can't be used in some situations.  Authenticating messages from a malicious server doesn't…

I don't think the working group is qualified to say under what circumstances this mechanism is useful.   I can think of scenarios where it makes perfect sense to use it in the local coffee shop, and also scenarios where it doesn't.   It's applicable when you have keys, or when you are willing to make a leap of faith, or when you want to verify that the thing you're talking to now is the same thing you talked to previously.   Going through "it makes sense in the enterprise but not the coffee shop" seems wrong-headed to me.