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

["Bernie Volz (volz)" <[e-mail]>]

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:[e-mail]] 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

>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

>- Ralph
>
>>
>> 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:[e-mail]] 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg