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

"Bernie Volz (volz)" <volz@cisco.com> Thu, 30 March 2017 14:37 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B1412950B; Thu, 30 Mar 2017 07:37:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3km9uOFtWTc; Thu, 30 Mar 2017 07:37:47 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E691129501; Thu, 30 Mar 2017 07:37:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61642; q=dns/txt; s=iport; t=1490884667; x=1492094267; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TMMqdPcAo9K7zKI5MVW232FTZ20OfNtXm8aeJgYL/ME=; b=lr+7j9D360aV2ZhsF+SFVLqcsv101D3r/JLpeRhxj2os4Jl3v1RFkYMX wJ77nenUDJE/p+0Yx9wh5HnKoTxRDj9xcwgMbrSob9urTp/2nM7zy8tSw 5IN9/lpwnbEC1k5QI0eMv8up5+IBSlVN71TLCFYPE3fVeeb8dshQWNNnD U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AbAQDtFt1Y/5xdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgm49K2GBC41zkTIfiBmNN4ILAx8BCoV4AoMzPxgBAgEBAQEBAQFrKIUVAQEBAQMBARgBDEQDCwwEAgEIEAEDAQEBIQEGByEGCxQJCAIEDgWJcwMVDq9oOiuGfQ2DHwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFiFMIgVmBCYE8gRWBbQI0DAqCfoIxBYZvgiuIGYRlhhc7AYZ8gyqDJ0qEOIF8hSqKEYpyiHoBHzhLOlsVGCkRAYQONgMNEIFjdQGGVwEkB4IQAQEB
X-IronPort-AV: E=Sophos;i="5.36,246,1486425600"; d="scan'208,217";a="401311146"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Mar 2017 14:37:45 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2UEbjld010571 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Mar 2017 14:37:45 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Mar 2017 09:37:44 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 30 Mar 2017 09:37:44 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Lishan Li <lilishan48@gmail.com>
CC: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, dhcwg <dhcwg@ietf.org>, draft-ietf-dhc-sedhcpv6 authors <draft-ietf-dhc-sedhcpv6@ietf.org>
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th
Thread-Index: AQHSmBEofEj8/aGJckKkKaGWH1j71aGmX41wgAIqkgCAAF2FgIAEoQ2AgAANjyw=
Date: Thu, 30 Mar 2017 14:37:44 +0000
Message-ID: <FBDB0F68-0087-4488-863F-E5F0D45281BF@cisco.com>
References: <e08be0f6-f1b4-4f57-6cdf-ddd546f8b793@gmail.com> <7db55e6f55e34408a1816887c22e28d3@XCH-ALN-003.cisco.com> <CAJ3w4NdN2jqJpQCeSgHLtHFkK3CLatN+BYFVGaFY=s5Qd_y6Gg@mail.gmail.com> <369C97B6-B6E7-46CE-B42E-18559BFB1E78@cisco.com>, <CAJ3w4Nf_gVtiO2KeCPaNT=b30mK8uQ0Tri2=0Nq5m_WLRU1aoQ@mail.gmail.com>
In-Reply-To: <CAJ3w4Nf_gVtiO2KeCPaNT=b30mK8uQ0Tri2=0Nq5m_WLRU1aoQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_FBDB0F6800874488863FE5F0D45281BFciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/lDbvXF4HA2ndpdH63HvIJteZZZI>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 14:37:59 -0000

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?

- Bernie (from iPhone)

On Mar 30, 2017, at 3:49 AM, Lishan Li <lilishan48@gmail.com<mailto:lilishan48@gmail.com>> wrote:

2017-03-27 22:07 GMT+08:00 Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>>:
Hi:

The sentence: "The encryption text SHOULD be formatted as explain in [RFC5652]." Isn't clear. RFC5652 doesn't use "text" except to mean actual wording in the RFC. Could "encryption text" be clarified? Is this the client's message? Or what exactly is this and which part of RFC 5652 has this "format"? I am not following what this sentence means and what I should do (if I were implementing this).

Note: This same text is also in Section 7 (last paragraph) and needs similar attention.
[LS]: Sorry for the unclear expression. How about the following text?
The DHCPv6 message sent from the client is encrypted and then encapsulated into the encrypted DHCPv6 message field according to the Encrypted-Data content syntax defined in the RFC5652.


BV> I assume this reference is to section 8 of RFC 5652. But now the question is whether anything further needs to be defined – for example, what (optional) attributes should be included? Perhaps as I’m not a security expert or have carefully reviewed RFC5652 and am taking a few things “out of content” when looking at it, but I think some clarity here may help in make sure this is easy to implement (especially for some of us that may not be experts in cryptography). This is a bit more complex than just taking the bytes of the client’s unencrypted message and the private key to encrypt (and placing that into the Encrypted-message Option), and taking the encrypted client’s message bytes (from a received Encrypted-message Option) and decrypting with the public key? You may want to think about whether perhaps specifying the details appropriate to DHCPv6 usage is appropriate – perhaps even in an appendix? RFC5652 talks about:

And there’s a lot about ASN.1 and OIDs in RFC5652, so are you pulling in all of this?

   The following object identifier identifies the encrypted-data content
   type:

      id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

   The encrypted-data content type shall have ASN.1 type EncryptedData:

      EncryptedData ::= SEQUENCE {
        version CMSVersion,
        encryptedContentInfo EncryptedContentInfo,
        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

   The fields of type EncryptedData have the following meanings:

      version is the syntax version number.  If unprotectedAttrs is
      present, then the version MUST be 2.  If unprotectedAttrs is
      absent, then version MUST be 0.

      encryptedContentInfo is the encrypted content information, as
      defined in Section 6.1<https://tools.ietf.org/html/rfc5652#section-6.1>.

      unprotectedAttrs is a collection of attributes that are not
      encrypted.  The field is optional.  Useful attribute types are
      defined in Section 11<https://tools.ietf.org/html/rfc5652#section-11>.

Probably section 6.1 is most applicable and there we have (eventually):


    EncryptedContent ::= OCTET STRING

Which may be all we really need?

And, if so, what is the value in referencing this RFC?

Again, I’m just trying to understand this more completely – what exactly is inside the Encrypted-message option?


[LS]: Yes, the reference is section 8 of RFC5652.
In the before version, Stephen suggested us to illustrate the format of the encrypted message data. He suggested to add the reference of RFC5652 for it.
But in fact, I don't know much about details of the draft.

[LS]: Yes, the server just need to keep one set for all clients.
How about the following modified text?
For client, it MUST remember about its own increasing number, which is stored in the NUM.STO and sent to the server. And the client also MUST remember about a server's increasing number, which is received from the server and stored in the NUM.REC. And the client keeps a record of the increasing number during the DHCPv6 configuration process with the DHCPv6 server.  And the client can forget the increasing number information after the transaction is finished.  The client's initial locally stored increasing number is set to zero.

For server, it MUST remember about its own increasing number, which is stored in the NUM.STO and sent to the client. And the server also MUST remember about a client's increasing number, which is received from the client and stored in the Num.REC. The server just need to keep one increasing number set for all clients.

BV> Here again, please be careful:

1.       If client always starts at 0, how does that help in preventing replay? And, this isn’t consistent with the server’s behavior above?

[LS]: For the first time that the client receives the increasing number, the client cannot compare it with the local number, and just to store it.

2.       If client doesn’t persist this, what happens if server has a lease for the client (and has retained the replay numbers) but the client released (or otherwise deleted the lease). Now when the client Solicits (encrypted), the server would report that this is a potential replay attach? I don’t think dropping this information “after the transaction is finished” is possible.

[LS]: Yes, it is better for the client to retain the number it last used with a server. For the devices without the persistent storage, the initial value of the increasing number is zero. After checking the increasing number in the Reply message, the NUM.STO is set to the NUM.REC. When sending the Solicit message, the increasing number is larger than the NUM.STO. So, the server will not report that this is a potential replay attack.

3.       For “The server just need to keep one increasing number set for all clients” – shouldn’t that be after the first sentence as this applies to NUM.STO; not NUM.REC?
Thus, I think the client must retain the number it last used with a server. This seems to be an issue for devices without persistent storage, so may require some further thought – or those devices cannot use increasing number?
[LS]: Agree, the client MUST retain the increasing number it last used with a server.

And, I think both having to retain this forever would be a bad idea. I think one could provide for both clients and servers to “forget” any stored information after a period of time (perhaps this can be a fixed number, 30 days, or should be some multiple of the lease lifetime)?
[LS]: So we can recommend a lifetime of the increasing number for the client and server, such as 30 days. Could you please check my understanding correct?


   Likewise, since the Encryption-Key-Tag Option isn't protected, an
   attacker that can intercept the message can forge the value without
   detection.

Isn't this generally useless? As the message is encrypted, the validation will fail?
[LS]: If the encryption-key-tag is forged, then the server may cannot decrypt it and drop the message.

BV> Right, but isn’t that exactly what we would want? So, how is this bad?


BV> Re Security Considerations - A new comment from a conversation with Tomek (Tomek will hopefully comment more). I mentioned that I was concerned with the possibility of clients and servers getting “junk” is a security concern as someone could generate bad packets with encrypted data and send them to clients and servers in the hope to crash the either when they try to decrypt and then process junk. Tomek suggested we might want to think about whether to add some magic value to the first few bytes of a message before encrypting it and then the decrypter can check those first few bytes to see if they are value and discard the message if not. Perhaps the encoding from RFC5652 would accomplish this if we are using more than just the encryptedContent? Anyway, something to think about.
[LS]: Agree. Perhaps the encoding from RFC5652 solves this problem.
I think that it may be a general problem for all encryption protocol.


Again, thanks for your continued efforts on this document!

[LS]: As the author of the draft, I have the responsibility to work on it. Thanks a lot for your continued guidance on this.

Best Regards,
Lishan
From: Lishan Li <lilishan48@gmail.com<mailto:lilishan48@gmail.com>>
Date: Monday, March 27, 2017 at 12:33 AM
To: Bernie Volz <volz@cisco.com<mailto:volz@cisco.com>>
Cc: Tomek Mrugalski <tomasz.mrugalski@gmail.com<mailto:tomasz.mrugalski@gmail.com>>, "dhcwg@ietf.org<mailto:dhcwg@ietf.org>" <dhcwg@ietf.org<mailto:dhcwg@ietf.org>>, draft-ietf-dhc-sedhcpv6 authors <draft-ietf-dhc-sedhcpv6@ietf.org<mailto:draft-ietf-dhc-sedhcpv6@ietf.org>>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th

Hi, Bernie,

Thanks a lot for your valuable comments. For the details, please see inline.

Best Regards,
Lishan

2017-03-26 10:05 GMT+08:00 Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>>:
Hi:

I have reviewed the draft and support it moving forward. However, I do have some issues I think need to be addressed but they are mostly fairly small.

I do want to thank the authors for addressing my earlier issues. I think the document is in MUCH better shape now!!

So here goes ...

Section 6:
The sentence: "The encryption text SHOULD be formatted as explain in [RFC5652]." Isn't clear. RFC5652 doesn't use "text" except to mean actual wording in the RFC. Could "encryption text" be clarified? Is this the client's message? Or what exactly is this and which part of RFC 5652 has this "format"? I am not following what this sentence means and what I should do (if I were implementing this).

Note: This same text is also in Section 7 (last paragraph) and needs similar attention.
[LS]: Sorry for the unclear expression. How about the following text?
The DHCPv6 message sent from the client is encrypted and then encapsulated into the encrypted DHCPv6 message field according to the Encrypted-Data content syntax defined in the RFC5652.


Section 7:

   option.  Then, the server checks the Server Identifier option.  The
   DHCPv6 server drops the message that is not for it, thus not paying
   cost to decrypt messages.  If it is the target server, according to

I think here you also want the server to proceed if there is NO Server Identifier option? It should only ignore it if there is a Server Identifier option and it does not match this server's identifier?
[LS]: Yes. Will modify it.

Section 8

   those present in the innermost encapsulated messages from the client
   or server.

I think messages should just be message as there is only one message?
[LS]: Agree. Will modify it.

Section 9.1:

Might be better to split out requirements for a client and server into separate paragraphs (1st paragraph)? Might also be best to be clear that you address:
1. What a client must remember about its own increasing number (i.e., what it sends to the server).
2. What a client must remember about the server's increasing number (i.e., what it receives from server).
3. What a server must remember about a client's increasing number (i.e., what it receives from client).
4. What a server must remember about its own increasing number (i.e., what it sends to clients). I assume a server does NOT need to keep a unique increasing number set for each client it communicates with - a server can use one set for all clients?
Please also be clear about how each of these 4 (2 numbers on client, 2 on server) are handled. The text presently is not very clear -- for example a client can't forget what it sent if the server remembers it.
[LS]: Yes, the server just need to keep one set for all clients.
How about the following modified text?
For client, it MUST remember about its own increasing number, which is stored in the NUM.STO and sent to the server. And the client also MUST remember about a server's increasing number, which is received from the server and stored in the NUM.REC. And the client keeps a record of the increasing number during the DHCPv6 configuration process with the DHCPv6 server.  And the client can forget the increasing number information after the transaction is finished.  The client's initial locally stored increasing number is set to zero.

For server, it MUST remember about its own increasing number, which is stored in the NUM.STO and sent to the client. And the server also MUST remember about a client's increasing number, which is received from the client and stored in the Num.REC. The server just need to keep one increasing number set for all clients.

Later, be clear that this is modulo 2^64 math:

   The Increasing-number option in the received message passes the
   increasing number check if NUM.REC is more than NUM.STO.  And then,
   the value of NUM.STO is changed into the value of NUM.REC.

   The increasing number check fails if NUM.REC is equal with or less
   than NUM.STO.

"More" here is in the modulo arithmetic "more" -- perhaps use "more (modulo 2^64)" and "or less (modulo 2^64)"?
[LS]: Agree, will modify it.

Section 9.2:

I wonder if you should revise the code to make it more appropriate for this document? RDATA/RDLENGTH aren't really appropriate?
[LS]: Got it. Will modify it.

Section 10

There are now only three (not six) status codes.
[LS]: Will correct it.

Section 10.2

   msg-type        Identifier of the message type.  It can be either
                   Encrypted-Query (TBA7) or DHCPv6-Response (TBA8).

Change DHCPv6-Response to Encrypted-Response.
[LS]: Will correct it.


Section 11

   There are some mandatory algorithm for encryption algorithm in this

Change (first) algorithm to algorithms? Or, change "are some" to "is a"
[LS]: Will change it.


   Likewise, since the Encryption-Key-Tag Option isn't protected, an
   attacker that can intercept the message can forge the value without
   detection.

Isn't this generally useless? As the message is encrypted, the validation will fail?
[LS]: If the encryption-key-tag is forged, then the server may cannot decrypt it and drop the message.


Some even more MINOR comments (these would perhaps improve readability but would likely be addressed by the RFC editor):
[LS]: Sorry for the poor expression. And thanks a lot your throughout check. Will correct it in the next version.

Section 6:

Perhaps replace "contained" and "contain" with "included" and "include" in the sentences later in that same paragraph (with the "The encryption text...").


   For the received Encrypted-Response message, the client MUST drop the
   Encrypted-Response message if other DHCPv6 option except Encrypted-
   message option is contained.

How about:

   For the received Encrypted-Response message, the client MUST drop the
   Encrypted-Response message if it contains any option other than a single
   Encrypted-message option.

Note: There are some other odd uses of contain (when at least I think the text should use include). But it may not be worth trying to change these (the usage is tricky - you can google for "english contain vs include" if you like). We will leave it to the RFC editor to perhaps clean these up if appropriate.


      The client MAY use the AuthenticationFail as a hint and switch
      to other DHCPv6 server if it has another one.

Change to "to another DHCP server if it has one"?

Section 7:

   Upon the receipt of Encrypted-Query message, the server MUST drop the
   message if the other DHCPv6 option is contained except Server

Here "the other" should change to "another".

Note: There are several other places where contained/contain would (at least in my mind) be more "standard" if the text used included/include. Same goes for use of "other" (-> another).

Last paragraph of section 7, "then the server set the". Set should be sets.

Section 10.1.1

For EA-len, might be good to add "(must be a multiple of 2)"
For SHA-len, might be good to add "(must be a multiple of 4)"

Also, I think you should change all "2-octets value" to "2-octet value".

Section 11

   For this security item, It is RECOMMENDED that client certificates
   could be tied to specific server certificates by configuration.

Lower case "It"?


General

There are uses of "cert" and "certs" and "certificate(s)". Are these one in the same? Shouldn't we just use "certificate" throughout? Or perhaps you should add "cert(s)" to terminology section?


- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org<mailto:dhcwg-bounces@ietf.org>] On Behalf Of Tomek Mrugalski
Sent: Wednesday, March 08, 2017 8:37 AM
To: dhcwg <dhcwg@ietf.org<mailto:dhcwg@ietf.org>>
Cc: draft-ietf-dhc-sedhcpv6 authors <draft-ietf-dhc-sedhcpv6@ietf.org<mailto:draft-ietf-dhc-sedhcpv6@ietf.org>>
Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th
Hi,
draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key cryptography to provide end-to-end security between DHCPv6 clients and servers. The mechanism provides encryption in all cases, and can be used for authentication based on pre-sharing of authorized certificates. This draft has started in 2013, but the whole DHCPv6 security saga is much longer and begins in 2008. This draft was submitted to IESG in mid-2015.
The guidance received was clear that  substantial changes are needed. As a result, "encrypt everywhere, authenticate if you can" approach was used.

Authors believe this draft to be ready for working group last call.

Please send your substantial comments to the mailing list and express your opinion whether this draft is ready for publication. Feel free to send nitpicks and minor corrections to the authors directly. This is a complex draft, so the chairs believe 3 weeks WGLC is in order. Please send your comments no later than March 29th. Bernie and I will determine consensus and will discuss during Chicago meeting as needed.

To initiate the discussion, I have two related questions. The chairs would love to hear your opinions on those.

1. The "encrypt everywhere" paradigm means that in deployments that do snooping on relay will break down. To solve this problem, we need a assignment notification mechanism, similar to the one described in draft-ietf-dhc-dhcpv6-agentopt-delegate-04. That draft expired many years ago. This matter was discussed in Seoul and the minutes describe the conclusion as:

  The discussion gravitated towards not resurrecting until the sedhcpv6
  I-D progresses further. We will reevaluate this once sedhcpv6 is done.

Do you want the WG to resurrect agentopt-delegate a) now, b) when
sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we need a completely new draft and I'm volunteering to work on it.

2. One of the authors suggested that this protocol is quite complex and having a feedback from an implementation (or ideally two interoperating) would be very important and would likely result in some changes to the draft. It's probably too late for Chicago, but we can organize a
sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE and Kea, as those two are open source and have an old version of the draft partially implemented. Do you think such a hackathon would be useful? Are you willing to participate?

Title: Secure DHCPv6
Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang
Filename: draft-ietf-dhc-sedhcpv6-21
Pages: 31
Date: 2017-02-21
Link: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/

Responses by March 29th are appreciated.

Thanks,
Bernie and Tomek
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org<mailto:dhcwg@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg