Subject: [6lo] AP-ND 22

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 24 Apr 2020 13:54:03 +0000

Hello Benjamin (and 6lo)

We are soliciting your help on AP ND for hopefully the last time, about the last step, that was supposed to be the IANA section that was missing for JOSE and Crypto Type 2.

Rene worked quite a bit with Jim and the conclusion that I made from that is that the formats that we already discussed in appendix B (SEC1) were better suited than JOSE (or COSE) and avoided both the registry issue and gaps in the existing specifications.

We had a conversation yesterday with our AD (Erik) and Shepherd (Shwetha) and we agreed to give a try at using those formats for -22. The conclusion that it looked OK but we need a validation that the new key and signature formats do not alter the security of the spec.

So there we go; 20 being the version that made it through IESG, and 21 the increments that you already reviewed and provides encoding agility, please find the proposed 22 attached and the diff between the proposed 22 and either 20 or 21.

The main diffs from 21 are
 - the removal of JWK,
 - a discussion on brown field that basically indicates that a back level 6LR constitutes a breach in the perimeter, meaning that all 6LRs need to be upgraded.
 - the J flag from 21 is gone, since we dropped JWK and dismissed the idea of operating AP ND in a brown field.

Can you please have a look and validate that we did OK?

Many, many thanks for all your help throughout!

Pascal, Rene and Mohit

Pascal Thubert
PRINCIPAL ENGINEER.ENGINEERING
[email-masked]<mailto:[email-masked]>
Tel: +33 49 723 2634
 cisco.com
Cisco Systems, Inc.
45 All Des Ormes Regus Centre
BP1200
06250 MOUGINS CEDEX
France
Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
Please click here<http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html> for Company Registration Information.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 24 Apr 2020 14:25:01 +0000

On the side, It appears that the key representations are typically of length 8n +1. Considering that IPv6 ND aligns its options at 8n bytes, it would make sense to start a byte ahead like this, don't you think?

        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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |Reserved1|  Public Key Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Crypto-Type  | Modifier      |  EARO Length  |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
      |                                                               |
      .                                                               .
      .                  Public Key (variable length)                 .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                           Padding                             .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: Crypto-ID Parameters Option

From: Pascal Thubert (pthubert)
Sent: vendredi 24 avril 2020 15:54
To: 'Benjamin Kaduk' <[email-masked]>; Rene Struik <[email-masked]>; Mohit Sethi <[email-masked]>
Cc: [email-masked]; Shwetha Bhandari (shwethab) <[email-masked]>; Jim Schaad <[email-masked]>; Erik Kline <[email-masked]>; [email-masked]
Subject: AP-ND 22

Hello Benjamin (and 6lo)

Pascal, Rene and Mohit

Pascal Thubert

---

From: Michael Richardson <[email-masked]>
Date: Sat, 25 Apr 2020 18:43:01 -0400

Pascal Thubert \(pthubert\) <pthubert=[email-masked]> wrote:
    > On the side, It appears that the key representations are typically of
    > length 8n +1. Considering that IPv6 ND aligns its options at 8n bytes,
    > it would make sense to start a byte ahead like this, don't you think?

I think it's a good idea if the content would otherwise be padding.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 26 Apr 2020 09:10:33 +0200

The draft should indicated on top first page that it updates RFC6775,
7400, and 8505, it only shows updating RFC8505.

On Fri, Apr 24, 2020 at 3:54 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> Hello Benjamin (and 6lo)
>
>
>
> We are soliciting your help on AP ND for hopefully the last time, about
> the last step, that was supposed to be the IANA section that was missing
> for JOSE and Crypto Type 2.
>
>
>
> Rene worked quite a bit with Jim and the conclusion that I made from that
> is that the formats that we already discussed in appendix B (SEC1) were
> better suited than JOSE (or COSE) and avoided both the registry issue and
> gaps in the existing specifications.
>
>
>
> We had a conversation yesterday with our AD (Erik) and Shepherd (Shwetha)
> and we agreed to give a try at using those formats for -22. The conclusion
> that it looked OK but we need a validation that the new key and signature
> formats do not alter the security of the spec.
>

IMHO it can be more clear to define in options a security policy name
defined by the 6LR, so the security cases of this draft can be attached to
per policy.

On Fri, Apr 24, 2020 at 4:26 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> length 8n +1. Considering that IPv6 ND aligns its options at 8n bytes, it
> would make sense to start a byte ahead like this, don’t you think?
>

Yes makes sense when the reserved1 is not fully used or zeros, but if used
then having another reserved is ok also,

Best regards,
AB

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 26 Apr 2020 20:52:34 -0700

> 7400, and 8505, it only shows updating RFC8505.

The 6775 case was discussed extensively during IESG Evaluation.
Note that 8505 itself Updates 6775, and the changes in this document affect
only what 8505 does (IIRC).  I'm not sure why you want this document to
update 7400 -- it seems to just be allocating some bits from the "6LoWPAN
capability Bits" registry established by 7400.  (Well, it would be if the
IANA considerations were updated to state that, at least.)  Allocating bits
from a registry is usually not seen to need an Updates relationship.

-Ben

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 Apr 2020 06:10:54 +0000

Ok I’ll keep that.

Many thanks Michael!

Regards,

Pascal

> Le 26 avr. 2020 à 00:43, Michael Richardson <[email-masked]> a écrit :
> 
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 27 Apr 2020 14:00:28 +0200

On Mon, Apr 27, 2020 at 5:52 AM Benjamin Kaduk <[email-masked]> wrote:

> capability Bits" registry established by 7400.

IMO it updates section 3.4 in RFC7400, it is not only adding bits, it is
adding the way of using 6CIO, we would not add bits only to add tasks in
protocols,

> (Well, it would be if the

yes IMO it should include also the IANA considerations

best regards

AB

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 Apr 2020 12:32:36 +0000

Hello Abdussalam:

I added the suggested IANA https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-22#section-8.4 .
I trust the IESG on the meaning of updating.

Stay safe,

Pascal

From: 6lo <[email-masked]> On Behalf Of Abdussalam Baryun
Sent: lundi 27 avril 2020 14:00
To: Benjamin Kaduk <[email-masked]>
Cc: [email-masked]; Pascal Thubert (pthubert) <pthubert=[email-masked]>; Mohit Sethi <[email-masked]>; Rene Struik <[email-masked]>; Shwetha Bhandari (shwethab) <[email-masked]>; [email-masked]; Erik Kline <[email-masked]>; Jim Schaad <[email-masked]>
Subject: Re: [6lo] AP-ND 22

On Mon, Apr 27, 2020 at 5:52 AM Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:

IMO it updates section 3.4 in RFC7400, it is not only adding bits, it is adding the way of using 6CIO, we would not add bits only to add tasks in protocols,

best regards

AB

-Ben

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 27 Apr 2020 15:08:36 +0200

On Mon, Apr 27, 2020 at 5:52 AM Benjamin Kaduk <[email-masked]> wrote:

> only what 8505 does (IIRC).

some new options added by this specification are discovery options and not
for registrations,

this draft says in the abstract that it updates 6775 and 8505, so if it is
in the abstract it is mostly updating in ietf-doc relations.

Best Regards
AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 27 Apr 2020 15:11:51 +0200

Hello Pascal,

usually when I read RFCs I like to see the updates and to remind the
readers/users of standards relationships,
I would not like to always have to go to IANA registrations to see their
updates, I want to see IETF updates of their docs.

On Mon, Apr 27, 2020 at 2:32 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Abdussalam:
>
>
>
> I added the suggested IANA
> https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-22#section-8.4 .
>

We all do trust them but just we may give reminders,

> Stay safe,

you too,

best regards

AB

>
>
> Pascal
>
>
>
> *From:* 6lo <[email-masked]> *On Behalf Of *Abdussalam Baryun
> *Sent:* lundi 27 avril 2020 14:00
> *To:* Benjamin Kaduk <[email-masked]>
> *Cc:* [email-masked]; Pascal Thubert (pthubert) <pthubert=
> [email-masked]>; Mohit Sethi <[email-masked]>;
> Rene Struik <[email-masked]>; Shwetha Bhandari (shwethab) <
> [email-masked]>; [email-masked]; Erik Kline <[email-masked]>; Jim Schaad <
> [email-masked]>
> *Subject:* Re: [6lo] AP-ND 22
>
>
>
>
>
>
>