Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

From: 神明達哉 <[email-masked]>
Date: Wed, 8 Feb 2017 13:38:00 -0800

At Mon, 16 Jan 2017 17:10:26 +0800,
Lishan Li <[email-masked]> wrote:

> We have submitted a new version of secure DHCPv6. Thanks a lot for Bernie's
> valuable comment.

I apologize for having been inactive on this draft, especially despite
being listed as a coauthor.  I've finally found time to take a closer
look at it.  I see the 20 version has been improved a lot; it's much
more readable than (some of the) older versions and many of the
technical questions I raised before seem to be addressed.  I
personally think we still need to discuss and address some more
technical details, but IMO this version is now much closer to WGLC.

...with one big reservation: I'd very much like to see at least one
attempt of implementing the spec.  This is a quite complicated
protocol specification, and no matter how hard we review the paper
spec, I'm quite sure that an actual implementation attempt will find
many more unclear points or protocol defects.  Although I understand
that's not a requirement for a WGLC or even for an RFC (the spirit of
"believing in running code" has been the thing of past at the IETF,
sadly) but I still hope we won't end up shipping a protocol spec with
full of defects mainly because there is not even an attempt of
implementing it before publishing it.

Specific comments on the 20 version follow.  There is one thing that I
guess needs broader attention, so I'm noting it here: I think we need
more discussion on the meaning and justification of "Non-SigAlg" and
"Non-EncryAlg" (especially the latter).  See below for more details.

- general: it's still not clear to me how we use this mechanism for
  Reconfigure.

- Section 1

   [...]  Such communications are already protected using the
   mechanism described in section 21.1 in [RFC3315].

  Perhaps a better reference today would be
  draft-ietf-dhc-relay-server-security.

- Section 1

   [...] The
   Algorithm, Certificate, Signature, and Increasing-number options are
   used for authentication.  The Encryption-Query message, Encryption-
   Response message, Encrypted-message option and Encryption-Key-Tag
   option are used for encryption.

  I suspect this is not 100% accurate.  Except for the signature
  option, everything can also be used for (or related to) encryption.

- Section 5.3

   [...]  The same client and server SHOULD use the
   same algorithm in a single communication session.

  Shouldn't this be a MUST?  Especially now that the client and the
  server negotiate and fix a specific set of algorithms initially, I
  don't see any possibility for an exception to this requirement.

- Section 5.3

   The sender can
   offer a set of algorithms, and then the receiver selects one
   algorithm for the future communication.

  s/sender/client/ and s/receiver/server/.  Only the client offers an
  algorithm set using the algorithm option.

- Section 5.5: s/The One/One/

   The One feasible environment in
   an early deployment stage would be enterprise networks.

- Section 5.5

   In
   enterprise networks, the client is manually pre-configured with the
   trusted servers' public key and the server is also manually pre-
   configured with the trusted clients' public keys.

  I suggest s/is (also) manually/can (also) be manually/ since manual
  configuration wouldn't be the absolute only option.

- Section 6

   And then the client first checks acknowledged hash, signature and
   encryption algorithms that the server supports.  If the hash
   algorithm field is zero, then it indicates that the hash algorithm is
   fixed according to the corresponding signature algorithm.  The client
   also uses the acknowledged algorithms in the return messages.

  It's not clear to me from this text how the client checks the
  algorithms.  By examining the certification option for the
  signature/encryption algorithms and examining the signature option
  for the hash ID?  If so, I think it should be clearly described.

  I'd note that the signature ID in the certificate must be equal to
  the signature ID of the signature option.  And, generalizing this,
  what if the client doesn't support these algorithms? (This shouldn't
  happen as long as the server handles the algorithm option correctly,
  so this is basically a bug of the server implementation).

  The description of zero hash algorithm field seems to suggest the
  signature and hash algorithms are tightly related in practice.  So
  it may be better to define the algorithm option so that
  signature/hash algorithms are listed as pairs.

- Section 6: s/return/subsequent/

   [...] The client
   also uses the acknowledged algorithms in the return messages.

- Section 6

   The first DHCPv6 message sent from the client to the server, such as
   Solicit message, MUST contain the Certificate option, Signature
   option and Increasing-number option for client authentication.[...]
   [...]  One and only one Increasing-number option SHOULD be
   contained,

  Isn't there a MUST vs SHOULD conflict here?

- Section 6

   [...] In this document, it is assumed
   that the client uses only one certificate for the encrypted DHCPv6
   configuration.  So, the corresponding private key is used for
   decryption.

  I'm not sure if this is okay.  And, in fact, Section 11 talks about
  a case where multiple key pairs (so multiple certificates) are used:

   If the client tries more than one cert for client authentication, the
   server can easily get a client that implements this to enumerate its
   entire cert list and probably learn a lot about a client that way.

 Perhaps this is intended to handle encrypted Reconfigure?  If that's
 the only reason for this limitation, I think we should address the
 reconfigure case in some other way and keep the general specification
 more flexible.

- Section 7

   [...] If it is the target server, according to
   the Encryption-Key-Tag option, the server identifies the used public/
   private key pair and decrypts the Encrypted-message option using the
   corresponding private key.

  The key tag is not necessarily unique for different public keys (so
  different key pairs), even if it should normally be unique in
  practice.  If multiple public keys share the same tag value, the
  server MUST try all corresponding key pairs.

  Also, since the key tag option isn't covered by a signature, it may
  have been forged by an intermediate attacker.  We may want to
  describe what the server should do in such a case (just discarding
  it is probably okay as it's forged anyway, but the server could also
  try all possible keys just in case the key tag is the only forged
  field).

- Section 7

   The server validates the client's certificate through the local pre-
   configured trusted certificates list.

  I'm not sure if this paragraph covers the "opportunistic encryption"
  mode, i.e, when the server doesn't know the certificate but chooses
  to use it for encryption only.  (I'm assuming our intent is to
  support such mode, right?).

- Section 7

   To provide
   the replay protection, the Increasing-number option can be contained
   in the encrypted DHCPv6 message.

  Shouldn't this be either SHOULD or MUST to be consistent with other
  part of this spec?  (see also the possible SHOULD vs MUST conflict
  commented above).

- Section 9.1

   [...]  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.

  I'm not sure if I understand it and I'm not sure if it's okay
  whatever it means...does this mean the server can (or always does?)
  reset the increasing number to 0 for messages it sends to the server
  at the beginning of a new DHCPv6 session?  Doesn't it lead to an
  easy replay attack?  Or is the assumption that the server first
  sends an error and the client will resend the message with an
  adjusted increasing number?

- Section 10.1.1

               The mandatory encryption
               algorithms MUST be included.

  Which algorithm is it?

- Section 10.1.2

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_CERTIFICATE       |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              EA-id            |            SA-id              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                           Certificate                         .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  This seems to assume a single certificate (which I assume means a
  single public key) can be used for both encryption and signature.
  Is my understanding correct?  If so, can we always assume that?

- Section 10.1.2

   It should be noticed that the scenario where the values of EA-id and
   SA-id are both 0 makes no sense and the client MUST discard a message
   with such values.

  The 0 EA-id/SA-id values are not described earlier in this
  document.  I think it should explicitly define its semantics before
  this text (perhaps in Section 10.1.1).

  And, from the description of Section 12:

         Non-SigAlg      |   0x00  | this document
           Non-EncryAlg  |   0x00  | this document

  I guess it means the signature is (effectively) not provided and the
  message is (effectively) not encrypted, respectively.  If my
  understanding is correct, is it okay to allow that, especially about
  encryption?  I vaguely recall a discussion about someone hoping to
  introduce a non-encryption mode, but I thought we rejected the idea
  because it would be against the "always encrypt" consensus.

- Section 10.1.5

   encryption key tag  A variable length field containing the encryption
      key tag sent from the client to server to identify the used
      public/private key pair.  The encryption key tag is calculated
      from the public key data, like fingerprint of a specific public
      key.  How to generate the encryption key tag adopts the method
      define in Appendix B in [RFC4034] and section 5.5 in [RFC6840].
      The data of the public key is used as input of the generation
      function.

  If we derive the tag calculation from RFC4034, the length is not
  variable: it's fixed to 16 bits.

  Also, I don't think we have to mention RFC6840 section 5.5.  We'd
  only use the method described in Appendix B of RFC4034 for
  algorithms other than type 1.

  And, although it may be quite straightforward, I don't think this
  description is enough to actually calculate the tag value for a
  given public key.  We should provide some more specific here.

- Section 11

   [RFC6273] has analyzed possible threats to the hash algorithms used
   in SEND.  Since Secure DHCPv6 defined in this document uses the same
   hash algorithms in similar way to SEND, analysis results could be
   applied as well: [...]

  Does this matter even when the hash value is in an encrypted
  message?

- Section 11

  I think we should also discuss a few more security issues in this
  section:
  - Since the algorithm option isn't protected by a signature, the
    list can be forged without detection, which can lead to a
    downgrade attack.
  - Likewise, since the Encryption-Key-Tag Option isn't protected, an
    attacker that can intercept the message can forge the value
    without detection (see also the relevant comment on Section 7).

- Section 12

   Hash Algorithm for Secure DHCPv6.  The values in this table are 8-bit
   unsigned integers.

  Shouldn't this be 16-bit?  It's defined as an 16-bit value for the
  HA-id field of various options.  Same for the signature algorithm
  and encryption algorithm.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 10 Feb 2017 22:46:58 +0000

Hi, I have not reviewed this latest version of the draft but in my understanding
from past discussions is that this mechanism always encrypts and there is no
longer an "authentication-only" mode. That being the case, if this work is to go
forward the WG must first resurrect the Relay Agent Assignment Notification
(RAAN) draft:

https://www.ietf.org/mail-archive/web/dhcwg/current/msg17651.html

Otherwise, sedhcpv6 would be incompatible with Relays that must glean route
information during DHCPv6 PD exchanges.

Chairs - what do we need to do to make RAAN a working group item?

Thanks - Fred

> -----Original Message-----
> From: dhcwg [mailto:[email-masked]] On Behalf Of ????
> Sent: Wednesday, February 08, 2017 1:38 PM
> To: Lishan Li <[email-masked]>
> Cc: dhcwg <[email-masked]>
> Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Lishan Li <[email-masked]>
Date: Mon, 13 Feb 2017 23:28:41 +0800

> technical details, but IMO this version is now much closer to WGLC.
[LS]: Thanks a lot for your comments. As a coauthor, you have contributed
a lot and gave many valuable comments.

> - general: it's still not clear to me how we use this mechanism for
[LS]: According to my understanding:
1. The server sends the encrypted Reconfigure message to the client;
2. If the Reconfigure option indicates the Renew message, then the client
sends the encrypted Renew message to the server. For this Encrypted-Query
message, it includes the server identifier option.
3. If the Reconfigure option indicates the Information-request message,
then
the client send the encrypted Information-request message to the server.
For this Encrypted-Query message, it does not include the server identifier
option. In this way, the Information message is received by all the servers
which
share the same certificate. If the client does not obtain the proper
parameters,
the client can choose other servers and sends the encrypted
information-request
message.

>   for the hash ID?  If so, I think it should be clearly described.
[LS]: Yes. The signature and encryption algorithms are checked through
the certificate option. And the signature and hash algorithms are checked
through the signature option. And the signature algorithms id in the two
options must be equal. Will describe it more clearly.

>   so this is basically a bug of the server implementation).
[LS]: For this error, then the client drops the Reply message.

>   signature/hash algorithms are listed as pairs.
[LS]: Yes. In some cases, the signature and hash algorithm are tightly
related and cannot be separate. Sorry that I don't understand that
"it may be better to define the algorithm option so that signature/hash
algorithms are listed as pairs", Could you please explain it more clearly?

>   Isn't there a MUST vs SHOULD conflict here?
[LS]: The increasing-number option is optional, not must be contained.
In the before version of secure DHCPv6 without encryption, the timestamp
option is optional. But in fact, I don't know why it is optional.

>  reconfigure case in some other way and keep the general specification
[LS]: So we deletes the description in section 11.

>   server MUST try all corresponding key pairs.
[LS]: Got it. Will modify the related sentences.

>   try all possible keys just in case the key tag is the only forged
[LS]: If the server then tries all the possible keys, then it is easy to
cause the attack to the server. So I think it is better to just drop it,
like
the action of decryption fail.
So we need to add the following text for this case.
If the server cannot find the corresponding private key of the key tag
or the corresponding private key of the key tag is invalid for decryption,
then the server drops the Encrypted-Query message

>   support such mode, right?).
[LS]: Yes, will add some description about it.

>   part of this spec?  (see also the possible SHOULD vs MUST conflict
[LS]: The increasing-number option is optional.

>   adjusted increasing number?
[LS]: For the first received increasing-number option, the client cannot
check it and just need to change the local increasing number into the
received number. So for this purpose, i add the above statement.
Looking forward to your further guidance.

>                algorithms MUST be included.
[LS]: The mandatory encryption algorithm is RSA. How about the following
text:
The mandatory encryption algorithm, such as RSA, MUST be included.

> - Section 10.1.2
[LS]: Yes, it means a single certificate and a single public key.
If EA-id = 0 & SA-id !=0, then the public key is used for signature.
If EA-id != 0 & SA-id =0, then the public key is used for encryption.
If EA-id != 0 & SA-id !=0, then the public key is used for signature and
encryption.

>   this text (perhaps in Section 10.1.1).
[LS]: Agree, will add some description before it.

>   because it would be against the "always encrypt" consensus.
[LS]: Sorry for the not clear expression.
In the before part, if the EA-id is set to zero, then the certificate is
not used
for encryption. If the SA-id is set to zero, then the certificate is not
used for
signature.

>   variable: it's fixed to 16 bits.
[LS]: Will modify it to 16 bits

>   algorithms other than type 1.
[LS]: Got it.

>   given public key.  We should provide some more specific here.
[LS]: Add some more specific text about how to compute it?
In the before, I prepared some text about it.
 Key Tag Calculation

The Encryption Key Tag in the Encrypted-Query message provides a mechanism
for selecting
the corresponding private key for decryption. In most cases, the encryption
key tag
can efficiently identify a private key record. The Encryption Key Tag
option can
be used to help select the corresponding private key when more than one
candidate
private key is available.

However, it is essential to note that the encryption key tag is not a
unique identifier.
It is theoretically possible for two different public keys to share one
common encryption
key tag. The encryption key tag is used to limit the possible candidate
keys, bu it
does not uniquely identify a public/private key pair. Implements MUST NOT
assume that
the key tag uniquelly identifier a public/private key pair.

The encryption key tag is the same for all encryption algorithm types
except algorithm
1 (please see Appendix A.1 for the defination of the key tag for algorithm
1). The key
tag generation algorithm is the sum of the public key data broken into 2
octet groups.
First, the public key date is treated as a series of 2 octet groups. These
groups are
then added together.

A reference implementation of the key tag algorithm is as the below
function, with the
data of the public key is used as input. It is not necessary to use the
following
reference code verbatim, but the numerical value fo teh encryption key tag
MUST be
identical to what the referencr implementation would generate for the same
input.

The following reference implementation calculates the value of the
encryption key tag.
This reference implementation applies to all algorithm types except
algorithm 1 (see
Appendix A.1). The input is the data of the public key. The code is written
for clarity,
not efficiency.

/*
    * Assumes that int is at least 16 bits.
    * First octet of the key tag is the most significant 8 bits of the
    * return value;
    * Second octet of the key tag is the least significant 8 bits of the
    * return value.
    */

   unsigned int
   keytag (
           unsigned char key[],  /* the RDATA part of the DNSKEY RR */
           unsigned int keysize  /* the RDLENGTH */
          )
   {
           unsigned long ac;     /* assumed to be 32 bits or larger */
           int i;                /* loop index */

           for ( ac = 0, i = 0; i < keysize; ++i )
                   ac += (i & 1) ? key[i] : key[i] << 8;
           ac += (ac >> 16) & 0xFFFF;
           return ac & 0xFFFF;
   }

   A.1.  Key Tag for Algorithm 1 (RSA/MD5)

   The encryption key tag for algorithm 1 (RSA/MD5) is defined differently
from
   the encryption key tag for all other algorithms, for historical
reasons.  For a
   public key with algorithm 1, the encryption key tag is defined to be the
most
   significant 16 bits of the least significant 24 bits in the public key
modulus
   (in other words, the 4th to last and 3rd to last octets of the public
key modulus).

>   Does this matter even when the hash value is in an encrypted
[LS]: Got it. Will delete it.

>     without detection (see also the relevant comment on Section 7).
[LS]: Agree. Will add it.

>   and encryption algorithm.
[LS]: Will modify it.

Thanks again,
Lishan

---

From: 神明達哉 <[email-masked]>
Date: Tue, 14 Feb 2017 13:20:23 -0800

At Mon, 13 Feb 2017 23:28:41 +0800,

> 1. The server sends the encrypted Reconfigure message to the client;

Encapsulated in an Encrypted-Response message?  If so, with setting
transaction-id to 0 (like Reconfigure itself)?  And is the client
supposed to try to decrypt it when transaction-id is 0 even if it
doesn't match any outstanding Encrypted-Query it has sent?  And in
that case which private key should the client use?  (For the last
question, see also the comment on the assumption of the number of
client certificate described in Section 6).

I think these questions and issues can be addressed relatively easily,
but I believe these should be clearly and explicitly described.

> algorithms are listed as pairs", Could you please explain it more clearly?

For example, instead of listing SA-id List and HA-id List separately,
we might have unified SA-id List:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_ALGORITHM         |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                          EA-id List                           .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                          SA-id List                           .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(no "HA-id List" in this level)

and each entry of SA-id List has two sub fields: signature algorithm
ID and hash algorithm ID:

|           SA-len              |            SA-id[1]           |
|           HA-id[1]            |            SA-id[2]           |
|           HA-id[2]            | ...
|           SA-id[n]            |            SA-id[n]           |

and each pair of (SA-id[i], HA-id[i]) will be considered to specify a
specific signature method.

> option is optional. But in fact, I don't know why it is optional.

This doesn't address my question...

> [LS]: So we deletes the description in section 11.

I don't understand how this addresses the comment...

> Looking forward to your further guidance.

I'd suggest consulting Ted here, as I guess the introduction of
increasing-number option was originally his idea.

> The mandatory encryption algorithm, such as RSA, MUST be included.

I don' know why "such as".  I'd consider a particular algorithm(s)
mandatory at the time of this document, and it/they should be
explicitly defined here.

> If EA-id != 0 & SA-id !=0, then the public key is used for signature and

Ah, so if we want to use different algorithms and/or keys for
signature and encryption, we have two certificate options, each
setting EA-id or SA-id to 0?  If so, I suggest explaining it
explicitly.

> In the before, I prepared some text about it.

I've not read the entire text, but it looked like a bit too verbose.
I'll see if I can offer some specific text.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Wed, 15 Feb 2017 19:46:27 +0800

> but I believe these should be clearly and explicitly described.
[LS]: How about the following method:
The transaction-id of the Encrypted-Reponse message MUST be equal with the
transaction-id of the received Encrypted-Query message and cannot be zero.
In this way, the client will try to decrypt it.

> we might have unified SA-id List:
[LS]: So, for every SA-id, there is a corresponding HA-id or multiple
HA-id(s).
SA-id and HA-id are set to a pair. Right?

> This doesn't address my question...
[LS]: Sorry. Will correct it.

> > >   a case where multiple key pairs (so multiple certificates) are used:
[LS]: We have discussed this issues before.
In most cases, a client will not uses multiple certificate(s) for the
encrypted DHCPv6 configuration process in the same time. Please see the
following reasons:
After the client authentication, the client will use the public key in the
certificate option for encryption. The server only knows one client's
public key for encryption. And the client will also only uses one private
key for decryption. So there is no cases that the client will use one key
pair for the encryption of some DHCPv6 messages and use another key pair
for the encryption of another DHCPv6 messages.

> > >  Perhaps this is intended to handle encrypted Reconfigure?

[LS]: No, this is not designed for the encrypted Reconfigure. This is
different from the above issue.
We consider the scenario where the client has multiple certs. In the
authentication process, if one cert of the client fails, the client may
send another cert for authentication. But once the authentication
successes, then the client and server will only uses the authenticated
public key for encryption.

> If that's

> increasing-number option was originally his idea.
[LS]: Will send another email to Ted for his comment.

[LS]: Got it.

> setting EA-id or SA-id to 0?  If so, I suggest explaining it
[LS]: Yes. Will explain it more clearly.

> I'll see if I can offer some specific text.
[LS]: Agree. Looking forward to your contributed text.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 15 Feb 2017 09:51:37 -0800

At Fri, 10 Feb 2017 22:46:58 +0000,

> information during DHCPv6 PD exchanges.

I've realized I misunderstood the meaning of zero IA-id (it doesn't
mean skipping encryption).  So, yes, it's incompatible with such
peeking relays.  It's probably better to describe the issue in
sedhcpv6 with a reference to the RAAN draft as a possible future
solution to it if and when it's adopted and standardized.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 15 Feb 2017 18:07:29 +0000

Hi Jinmei-san,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
> Sent: Wednesday, February 15, 2017 9:52 AM
> To: Templin, Fred L <[email-masked]>
> Cc: Lishan Li <[email-masked]>; dhcwg <[email-masked]>
> peeking relays.

Thanks for confirming.

> It's probably better to describe the issue in

If sedhcpv6 will not support an authentication-only mode, then it
can' t go forward until RAAN is adopted as a wg item. Otherwise,
an encryption-only sedhcpv6 w/o RAAN would break DHCPv6 PD.

Thanks - Fred
[email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Wed, 15 Feb 2017 10:32:56 -0800

At Wed, 15 Feb 2017 18:07:29 +0000,

> an encryption-only sedhcpv6 w/o RAAN would break DHCPv6 PD.

I personally don't think it a blocking issue for sedhcpv6, but, of
course, the wg should decide it.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Feb 2017 13:49:25 -0500

> course, the wg should decide it.

It definitely isn't a blocking issue, but Fred is right that if we are going ahead with encryption-only, which I agree is the right move, we need to do this work as well.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 15 Feb 2017 18:51:26 +0000

Hi Jinmei-san,

> Sent: Wednesday, February 15, 2017 10:33 AM

Some uses of DHCPv6 PD require a secure exchange between the client and
server supported by an LDRA [RFC6221] that is in the same physical stack as
the server. The LDRA needs to peek into the server's Reply in order to discover
the delegated prefixes for the purpose of configuring routes. This all needs to
work with a standards-compliant DHCPv6 server that implements both
sedhcpv6 and RAAN. Meaning that sedhcpv6 and RAAN would need to be
advanced together as standards.

Maybe better yet would be to bring the RAAN option into the sedhcpv6
spec itself?

Thanks - Fred

---

From: 神明達哉 <[email-masked]>
Date: Wed, 15 Feb 2017 11:27:07 -0800

At Wed, 15 Feb 2017 19:46:27 +0800,

> In this way, the client will try to decrypt it.

Assuming the Reconfigure is encapsulated in an Encrypted-Response
message: it won't work since in case of Reconfigure there's no
corresponding message from the client to the server that would be
encapsulated in the Encrypted-Query message in the first place.

> > we might have unified SA-id List:
[...]
> SA-id and HA-id are set to a pair. Right?

In this example, yes.  But I'm not necessarily insisting on this
particular example itself.  My concern with the currently described
way is how to address cases like:

- the client includes SA0, SA1, HA0, HA1 in the algorithm option.  It
  supports the combinations of (SA0, HA0) and (SA1, HA1), but not (SA0,
  HA1) or (SA1, HA0)
- the server returns a certificate with the combination of (SA0, HA1)
  or (SA1, HA0)

So the higher level question is whether and how to address this
concern.  The above example approach could be one solution to it, but
it can make the algorithm option unnecessarily larger.

> for the encryption of another DHCPv6 messages.

This is fine, but I was wondering what if the client has multiple
DHCPv6 sessions with different DHCPv6 servers using different key
pairs.  It's probably very rare in practice, so I can live with saying
such an operation is outside the scope of this spec.  But I'd like to
see wg consensus on this, and if we reach it I'd like it to be
explicitly documented.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 15 Feb 2017 11:42:29 -0800

At Wed, 15 Feb 2017 18:51:26 +0000,

> the delegated prefixes for the purpose of configuring routes. This all needs to

Where in RFC6221 is that need described?  From a quick re-read of the
RFC I can't find it.  But in any case,

> advanced together as standards.

I don't follow the logic of the final sentence.  I see this means
sedhcpv6 at least initially wouldn't work for a particular scenario
without RAAN.  But I don't think it automatically means sedhcpv6 can't
be standardized with that limitation.  It would depend on how this
incompatibility is critical for the overall purpose of sedhcpv6, and
it doesn't seem to be that substantial - we can eventually standardize
RAAN, and then update sedhcpv6 to fill the incompatibility.  I
understand you have a different opinion, but to me it's a matter of
opinion, not an only possible interpretation of this situation.  I'm
not insisting my opinion should win, of course, and that's why I said
the wg should decide it.

> Maybe better yet would be to bring the RAAN option into the sedhcpv6

For the same reason I don't think so, but, again, it should be up to
the wg.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 15 Feb 2017 11:46:16 -0800

At Wed, 15 Feb 2017 13:49:25 -0500,
Ted Lemon <[email-masked]> wrote:

> [...], but Fred is right that if we
> are going ahead with encryption-only, which I agree is the right
> move, we need to do this work as well.

Yes, I agree on that point.

--
JINMEI, Tatuya

---

From: Lishan Li <[email-masked]>
Date: Thu, 16 Feb 2017 14:48:59 +0800

> encapsulated in the Encrypted-Query message in the first place.
[LS]: Yes. It is also the reason why the transaction-id of Reconfigure
message is set to zero. Right?
In this way, if the transaction-id of the Encrypted-Response is set to
zero.
Then in the client behavior part, we should states that: If the
transaction-id is 0, the client also try to decrypt it.
And in the server behavior part, we add the states that: If the DHCPv6
message is Reconfigure message, then the server set the transaction-id of
the Encrypted-Response message to 0.

> it can make the algorithm option unnecessarily larger.
[LS]: Agree.

> see wg consensus on this, and if we reach it I'd like it to be
[LS]: Agree. It is necessary to be explicitly documented.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 16 Feb 2017 19:01:05 +0000

Hi Jinmei-san,

> Sent: Wednesday, February 15, 2017 11:42 AM

There is at least one use case where an RFC6221 LDRA resides in lower levels of
the stack that supports the DHCPv6 server and manages routing information
based on DHCPv6 PDs issued by the server. Because an unmodified DHCPv6
server cannot reach across the layers to manipulate the routing information,
it relies on the LDRA to do so. So, when sedhcpv6 is applied, there is a
requirement for RAAN options to allow the server to pass information to
 the LDRA.

> For the same reason I don't think so, but, again, it should be up to

There is another example where a security-specific solution published
general-purpose options potentially useful for other purposes. In RFC3971
(the SEND spec) the Timestamp and Nonce options are defined. The assigned
numbers for these options occupy IPv6 ND Option Type values, and they are
therefore presumably applicable for IPv6 ND messaging even when SEND is
not in effect.

In the same fashion, if the RAAN option were incorporated into the
sedhcpv6 spec, it could be applied for other purposes even when
sedhcpv6 is not in effect. And, there would no longer be concerns for
a synchronized publication of multiple documents since both sedhcpv6
and RAAN would go forward together in a single package.

Thanks - Fred

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Feb 2017 22:38:55 +0000

I presented about resurrecting draft-ietf-dhc-dhcpv6-agentopt-delegate at IETF-97 (see https://www.ietf.org/proceedings/97/slides/slides-97-dhc-resurrect-draft-ietf-dhc-dhcpv6-agentopt-delegate-00.pdf).

And the conclusion then was (see https://www.ietf.org/proceedings/97/minutes/minutes-97-dhc-00.txt):

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

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Wednesday, February 15, 2017 1:49 PM
To: 神明達哉 <[email-masked]>
Cc: dhcwg <[email-masked]>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

On Feb 15, 2017, at 1:32 PM, 神明達哉 <[email-masked]<mailto:[email-masked]>> wrote:
I personally don't think it a blocking issue for sedhcpv6, but, of
course, the wg should decide it.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 17 Feb 2017 22:34:49 +0000

Bernie,

This does not make sense to me; sedhcpv6 is the very reason that RAAN is important.
Just like RFC3971 did with IPv6 ND Timestamp and Nonce options, sedhcpv6 could
define the RAAN operation and have everything over and done with in one pass.
And, I have already identified a use case where RAAN is absolutely necessary.
Also, I was unable to attend  IETF97, where I certainly would have stood up and
voiced my position.

Thanks - Fred

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Thursday, February 16, 2017 2:39 PM
To: Ted Lemon <[email-masked]>; 神明達哉 <[email-masked]>
Cc: dhcwg <[email-masked]>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Wednesday, February 15, 2017 1:49 PM
To: 神明達哉 <[email-masked]<mailto:[email-masked]>>
Cc: dhcwg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 17 Feb 2017 23:00:21 +0000

I think the plan here makes some sense … seDHCPv6 has had several attempts and been kicked back to the WG. So, I think the WG wants to go slowly and not develop a solution until seDHCPv6 is likely to advance in the IESG (encryption was only added fairly “recently”).

And, it isn’t like the day after seDHCPv6 is “approved” that every client (and server) will support this. It will take time to roll out. And, hopefully we can get the RAAN work out in a fairly short time.

In your networks, if you can’t support seDHCPv6 until you have something to so solve the RAAN issues, you obviously can’t deploy seDHCPv6. But there may be plenty of other networks where this isn’t an issue and it could start to be deployed (coffee shops and enterprises).

-          Bernie

From: Templin, Fred L [mailto:[email-masked]]
Sent: Friday, February 17, 2017 5:35 PM
To: Bernie Volz (volz) <[email-masked]>; Ted Lemon <[email-masked]>; 神明達哉 <[email-masked]>
Cc: dhcwg <[email-masked]>
Subject: RE: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

Bernie,

Thanks - Fred

To: Ted Lemon <[email-masked]<mailto:[email-masked]>>; 神明達哉 <[email-masked]<mailto:[email-masked]>>

-          Bernie

---

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 18 Feb 2017 16:28:03 +0000

Hi Bernie,

My understanding  is that sedhcpv6 is intended to be a product of the IETF,
so I therefore assume that it is intended to be a product of engineering. It
has been shown that sedhcpv6 has an omission that will limit its applicability,
and that that omission can be rather easily remedied prior to publication. It
therefore makes good engineering sense to fix the omission now.

The proposal again is to have sedhcpv6 specify the RAAN option as part of
the base document.

Thanks - Fred

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Friday, February 17, 2017 3:00 PM
To: Templin, Fred L <[email-masked]>; Ted Lemon <[email-masked]>; 神明達哉 <[email-masked]>
Cc: dhcwg <[email-masked]>
Subject: RE: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

-          Bernie

To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>; Ted Lemon <[email-masked]<mailto:[email-masked]>>; 神明達哉 <[email-masked]<mailto:[email-masked]>>

Bernie,

Thanks - Fred

-          Bernie

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Feb 2017 12:17:10 -0500

Fred, I think we all agree that this problem needs to be solved. We don't
agree that work on the security draft must stop until the raan draft is
done. It's just not that hard.

On Feb 18, 2017 11:28 AM, "Templin, Fred L" <[email-masked]>
wrote:

Hi Bernie,

has been shown that sedhcpv6 has an omission that will limit its
applicability,

and that that omission can be rather easily remedied prior to publication.
It

the base document.

Thanks - Fred

*From:* Bernie Volz (volz) [mailto:[email-masked]]
*Sent:* Friday, February 17, 2017 3:00 PM
*To:* Templin, Fred L <[email-masked]>; Ted Lemon <
[email-masked]>; 神明達哉 <[email-masked]>

*Cc:* dhcwg <[email-masked]>
*Subject:* RE: [dhcwg] Fwd: New Version Notification for
draft-ietf-dhc-sedhcpv6-20.txt

I think the plan here makes some sense … seDHCPv6 has had several attempts
and been kicked back to the WG. So, I think the WG wants to go slowly and
not develop a solution until seDHCPv6 is likely to advance in the IESG
(encryption was only added fairly “recently”).

And, it isn’t like the day after seDHCPv6 is “approved” that every client
(and server) will support this. It will take time to roll out. And,
hopefully we can get the RAAN work out in a fairly short time.

In your networks, if you can’t support seDHCPv6 until you have something to
so solve the RAAN issues, you obviously can’t deploy seDHCPv6. But there
may be plenty of other networks where this isn’t an issue and it could
start to be deployed (coffee shops and enterprises).

-          Bernie

*From:* Templin, Fred L [mailto:[email-masked]
<[email-masked]>]
*Sent:* Friday, February 17, 2017 5:35 PM
*To:* Bernie Volz (volz) <[email-masked]>; Ted Lemon <[email-masked]>;
神明達哉 <[email-masked]>
*Cc:* dhcwg <[email-masked]>
*Subject:* RE: [dhcwg] Fwd: New Version Notification for
draft-ietf-dhc-sedhcpv6-20.txt

Bernie,

This does not make sense to me; sedhcpv6 is the very reason that RAAN is
important.

Just like RFC3971 did with IPv6 ND Timestamp and Nonce options, sedhcpv6
could

define the RAAN operation and have everything over and done with in one
pass.

And, I have already identified a use case where RAAN is absolutely
necessary.

Also, I was unable to attend  IETF97, where I certainly would have stood up
and

voiced my position.

Thanks - Fred

*From:* dhcwg [mailto:[email-masked] <[email-masked]>] *On
Behalf Of *Bernie Volz (volz)
*Sent:* Thursday, February 16, 2017 2:39 PM
*To:* Ted Lemon <[email-masked]>; 神明達哉 <[email-masked]>
*Cc:* dhcwg <[email-masked]>
*Subject:* Re: [dhcwg] Fwd: New Version Notification for
draft-ietf-dhc-sedhcpv6-20.txt

I presented about resurrecting draft-ietf-dhc-dhcpv6-agentopt-delegate at
IETF-97 (see https://www.ietf.org/proceedings/97/slides/slides-
97-dhc-resurrect-draft-ietf-dhc-dhcpv6-agentopt-delegate-00.pdf).

And the conclusion then was (see https://www.ietf.org/
proceedings/97/minutes/minutes-97-dhc-00.txt):

-          Bernie

*From:* dhcwg [mailto:[email-masked] <[email-masked]>] *On
Behalf Of *Ted Lemon
*Sent:* Wednesday, February 15, 2017 1:49 PM
*To:* 神明達哉 <[email-masked]>
*Cc:* dhcwg <[email-masked]>
*Subject:* Re: [dhcwg] Fwd: New Version Notification for
draft-ietf-dhc-sedhcpv6-20.txt

It definitely isn't a blocking issue, but Fred is right that if we are
going ahead with encryption-only, which I agree is the right move, we need
to do this work as well.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Feb 2017 20:17:00 +0000

Hi Ted,

Just getting back to this after being away for the past week:

Ø  Fred, I think we all agree that this problem needs to be solved.

I still think it would be cleanest and most consistent with past works if the base
sedhcpv6 specification were to include the RAAN option itself. But, if that would
not be possible and if (as you say) there is agreement that this problem needs
to be solved, then we should adopt the RAAN draft as a dhcwg working group
item now.

Ø  We don't agree that work on the security draft must stop until the raan draft is done.

I never said or meant to imply that the security draft must stop until RAAN is done.
To the contrary, the two documents could run in parallel with both being dhcwg WG
items now and with no interdependencies. By adopting RAAN as a WG item now,
implementers would be more likely to implement RAAN in parallel with sedhcpv6
rather than defer it to some (much) later time.

Ø  It's just not that hard.

Definitely agree.

Thanks - Fred

From: Ted Lemon [mailto:[email-masked]]
Sent: Saturday, February 18, 2017 9:17 AM
To: Templin, Fred L <[email-masked]>
Cc: dhcwg <[email-masked]>; 神明達哉 <[email-masked]>; Bernie Volz (volz) <[email-masked]>
Subject: RE: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

Fred, I think we all agree that this problem needs to be solved. We don't agree that work on the security draft must stop until the raan draft is done. It's just not that hard.

On Feb 18, 2017 11:28 AM, "Templin, Fred L" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bernie,

Thanks - Fred

From: Bernie Volz (volz) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, February 17, 2017 3:00 PM
To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>; Ted Lemon <[email-masked]<mailto:[email-masked]>>; 神明達哉 <[email-masked]<mailto:[email-masked]>>

-          Bernie

Bernie,

Thanks - Fred

-          Bernie

---

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Feb 2017 15:21:31 -0500

Bernie - a long time ago, if I recall correctly, you asked me if I had XML source for the earlier RAAN document.  I searched around, but can't seem to find that file.  Is the text in that earlier doc at all useful for this instantiation of RAAN?

- Ralph

> On Feb 27, 2017, at 3:17 PM, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Ted,
>  
> On Feb 18, 2017 11:28 AM, "Templin, Fred L" <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Bernie,
>  
> From: Bernie Volz (volz) [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Templin, Fred L <[email-masked] <mailto:[email-masked]>>; Ted Lemon <[email-masked] <mailto:[email-masked]>>;神明達哉 <[email-masked] <mailto:[email-masked]>>
> 
> Cc: dhcwg <[email-masked] <mailto:[email-masked]>>
> From: Templin, Fred L [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>>; Ted Lemon <[email-masked] <mailto:[email-masked]>>; 神明達哉<[email-masked] <mailto:[email-masked]>>
> Cc: dhcwg <[email-masked] <mailto:[email-masked]>>
> From: dhcwg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Bernie Volz (volz)
> To: Ted Lemon <[email-masked] <mailto:[email-masked]>>; 神明達哉 <[email-masked] <mailto:[email-masked]>>
> Cc: dhcwg <[email-masked] <mailto:[email-masked]>>
> I presented about resurrecting draft-ietf-dhc-dhcpv6-agentopt-delegate at IETF-97 (seehttps://www.ietf.org/proceedings/97/slides/slides-97-dhc-resurrect-draft-ietf-dhc-dhcpv6-agentopt-delegate-00.pdf <https://www.ietf.org/proceedings/97/slides/slides-97-dhc-resurrect-draft-ietf-dhc-dhcpv6-agentopt-delegate-00.pdf>).
>  
> And the conclusion then was (see https://www.ietf.org/proceedings/97/minutes/minutes-97-dhc-00.txt <https://www.ietf.org/proceedings/97/minutes/minutes-97-dhc-00.txt>):
>  
> From: dhcwg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Ted Lemon
> To: 神明達哉 <[email-masked] <mailto:[email-masked]>>
> Cc: dhcwg <[email-masked] <mailto:[email-masked]>>
> On Feb 15, 2017, at 1:32 PM, 神明達哉 <[email-masked] <mailto:[email-masked]>> wrote:

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 27 Feb 2017 20:33:32 +0000

Hi:

I would think we would start with the current RAAN document (I think we can easily create the XML from the TXT; would have been easier not to have to do that if XML was available).

We haven’t discussed it seriously in the WG yet, and no one has requested time to discuss further at IETF-98 (Chicago). Though of course we can do it here on the ML.

My hope would be that we can restart this work perhaps between Chicago and Prague, as hopefully seDHCPv6 will go to WGLC sometime soon. But of course, seDHCPv6 has been there before and it was in the IESG that it was bounced back to the WG – though hopefully third time will be the charm?

When it is time, I was just planning to do the conversion and resubmit it as the next version of the RAAN document (perhaps with minor edits). I guess though there is the question of whether we should “restart” as an individual submission or whether the WG just agrees to resume work on this document as a WG document. Anyway, we can debate that on the list before publication.

Of course, also need to also check with the co-authors (you and Ole) to see how best to proceed. I had assumed you both would stay on …

At present, the only one really pushing for this to start now is Fred T.

-          Bernie

From: Ralph Droms [mailto:[email-masked]]
Sent: Monday, February 27, 2017 3:22 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: Ted Lemon <[email-masked]>; dhcwg <[email-masked]>; 神明達哉 <[email-masked]>; Templin, Fred L <[email-masked]>
Subject: Re: [dhcwg] New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

- Ralph

On Feb 27, 2017, at 3:17 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ted,

Just getting back to this after being away for the past week:

>  Fred, I think we all agree that this problem needs to be solved.

>  We don't agree that work on the security draft must stop until the raan draft is done.

>  It's just not that hard.

Definitely agree.

Thanks - Fred

From: Ted Lemon [mailto:[email-masked]]
Sent: Saturday, February 18, 2017 9:17 AM
To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>
Cc: dhcwg <[email-masked]<mailto:[email-masked]>>; 神明達哉 <[email-masked]<mailto:[email-masked]>>; Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

Thanks - Fred

From: Bernie Volz (volz) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, February 17, 2017 3:00 PM
To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>; Ted Lemon <[email-masked]<mailto:[email-masked]>>;神明達哉 <[email-masked]<mailto:[email-masked]>>

-          Bernie

To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>; Ted Lemon <[email-masked]<mailto:[email-masked]>>; 神明達哉<[email-masked]<mailto:[email-masked]>>

Bernie,

Thanks - Fred

I presented about resurrecting draft-ietf-dhc-dhcpv6-agentopt-delegate at IETF-97 (seehttps://www.ietf.org/proceedings/97/slides/slides-97-dhc-resurrect-draft-ietf-dhc-dhcpv6-agentopt-delegate-00.pdf).

-          Bernie

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Feb 2017 16:55:40 +0000

Hi Bernie and Ralph,

Yes, I am interested in seeing the RAAN work resume. But, it shouldn’t be seen
as just me pushing for it, but rather that a need has been identified that would
be in the best interest of the working group as a whole to address.

Thanks - Fred

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Monday, February 27, 2017 12:34 PM
To: Ralph Droms <[email-masked]>
Cc: Ted Lemon <[email-masked]>; dhcwg <[email-masked]>; Templin, Fred L <[email-masked]>
Subject: RE: [dhcwg] New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

Hi:

-          Bernie

From: Ralph Droms [mailto:[email-masked]]
Sent: Monday, February 27, 2017 3:22 PM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Cc: Ted Lemon <[email-masked]<mailto:[email-masked]>>; dhcwg <[email-masked]<mailto:[email-masked]>>; 神明達哉 <[email-masked]<mailto:[email-masked]>>; Templin, Fred L <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

- Ralph

Hi Ted,

Definitely agree.

Thanks - Fred

Thanks - Fred

-          Bernie

Bernie,

Thanks - Fred

-          Bernie

---

From: Ralph Droms <[email-masked]>
Date: Tue, 28 Feb 2017 14:33:21 -0500

Bernie - thanks for the status update on doc WG interest in RAAN.

Converting the existing document to XML is probably a good place to start.  A discussion on the list about restarting as an individual document or picking back up again as a WG document would likely also give you a sense of who might be interested in seeing the standard developed and published.  I don't have a sense of the intersection of deployments of seDHCP with really agent snooping, so I don't have a good way to judge potential interest.

I'll be happy to stay on as a co-author.

- Ralph

> On Feb 27, 2017, at 3:33 PM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Hi:
>  
> From: Ralph Droms [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>>
> Cc: Ted Lemon <[email-masked] <mailto:[email-masked]>>; dhcwg <[email-masked] <mailto:[email-masked]>>; 神明達哉<[email-masked] <mailto:[email-masked]>>; Templin, Fred L <[email-masked] <mailto:[email-masked]>>
> On Feb 27, 2017, at 3:17 PM, Templin, Fred L <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Ted,
>  
> From: Ted Lemon [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Templin, Fred L <[email-masked] <mailto:[email-masked]>>
> Cc: dhcwg <[email-masked] <mailto:[email-masked]>>; 神明達哉 <[email-masked] <mailto:[email-masked]>>; Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>