Re: [6lo] AP-ND 22

[Abdussalam Baryun]

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) <
pthub...@cisco.com> wrote:

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

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

>
>
> Stay safe,
>

you too,

best regards

AB



>
>
> Pascal
>
>
>
> *From:* 6lo <6lo-boun...@ietf.org> *On Behalf Of *Abdussalam Baryun
> *Sent:* lundi 27 avril 2020 14:00
> *To:* Benjamin Kaduk 
> *Cc:* 6lo-cha...@ietf.org; Pascal Thubert (pthubert)  40cisco@dmarc.ietf.org>; Mohit Sethi ;
> Rene Struik ; Shwetha Bhandari (shwethab) <
> shwet...@cisco.com>; 6lo@ietf.org; Erik Kline ; Jim Schaad <
> i...@augustcellars.com>
> *Subject:* Re: [6lo] AP-ND 22
>
>
>
>
>
>
>
> On Mon, Apr 27, 2020 at 5:52 AM Benjamin Kaduk  wrote:
>
> On Sun, Apr 26, 2020 at 09:10:33AM +0200, Abdussalam Baryun wrote:
> >   The draft should indicated on top first page that it updates RFC6775,
> > 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.
>
>
>
> 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
> IANA considerations were updated to state that, at least.)  Allocating bits
> from a registry is usually not seen to need an Updates relationship.
>
>
>
> yes IMO it should include also the IANA considerations
>
>
>
> best regards
>
>
>
> AB
>
>
>
>
> -Ben
>
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] AP-ND 22

[Abdussalam Baryun]

On Mon, Apr 27, 2020 at 5:52 AM Benjamin Kaduk  wrote:

> On Sun, Apr 26, 2020 at 09:10:33AM +0200, Abdussalam Baryun wrote:
> >   The draft should indicated on top first page that it updates RFC6775,
> > 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).


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
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] AP-ND 22

[Pascal Thubert (pthubert)]

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 <6lo-boun...@ietf.org> On Behalf Of Abdussalam Baryun
Sent: lundi 27 avril 2020 14:00
To: Benjamin Kaduk 
Cc: 6lo-cha...@ietf.org; Pascal Thubert (pthubert) 
; Mohit Sethi 
; Rene Struik ; Shwetha 
Bhandari (shwethab) ; 6lo@ietf.org; Erik Kline 
; Jim Schaad 
Subject: Re: [6lo] AP-ND 22



On Mon, Apr 27, 2020 at 5:52 AM Benjamin Kaduk 
mailto:ka...@mit.edu>> wrote:
On Sun, Apr 26, 2020 at 09:10:33AM +0200, Abdussalam Baryun wrote:
>   The draft should indicated on top first page that it updates RFC6775,
> 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.

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
IANA considerations were updated to state that, at least.)  Allocating bits
from a registry is usually not seen to need an Updates relationship.

yes IMO it should include also the IANA considerations

best regards

AB


-Ben
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] AP-ND 22

[Abdussalam Baryun]

On Mon, Apr 27, 2020 at 5:52 AM Benjamin Kaduk  wrote:

> On Sun, Apr 26, 2020 at 09:10:33AM +0200, Abdussalam Baryun wrote:
> >   The draft should indicated on top first page that it updates RFC6775,
> > 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.


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
> IANA considerations were updated to state that, at least.)  Allocating bits
> from a registry is usually not seen to need an Updates relationship.
>

yes IMO it should include also the IANA considerations

best regards

AB


> -Ben
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] I-D Action: draft-ietf-6lo-ap-nd-22.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over Networks of Resource-constrained 
Nodes WG of the IETF.

Title   : Address Protected Neighbor Discovery for Low-power 
and Lossy Networks
Authors : Pascal Thubert
  Behcet Sarikaya
  Mohit Sethi
  Rene Struik
Filename: draft-ietf-6lo-ap-nd-22.txt
Pages   : 32
Date: 2020-04-27

Abstract:
   This document updates the 6LoWPAN Neighbor Discovery (ND) protocol
   defined in RFC 6775 and RFC 8505.  The new extension is called
   Address Protected Neighbor Discovery (AP-ND) and it protects the
   owner of an address against address theft and impersonation attacks
   in a low-power and lossy network (LLN).  Nodes supporting this
   extension compute a cryptographic identifier (Crypto-ID) and use it
   with one or more of their Registered Addresses.  The Crypto-ID
   identifies the owner of the Registered Address and can be used to
   provide proof of ownership of the Registered Addresses.  Once an
   address is registered with the Crypto-ID and a proof-of-ownership is
   provided, only the owner of that address can modify the registration
   information, thereby enforcing Source Address Validation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-22
https://datatracker.ietf.org/doc/html/draft-ietf-6lo-ap-nd-22

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-22


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] AP-ND 22

[Pascal Thubert (pthubert)]

Ok I’ll keep that.

Many thanks Michael!


Regards,

Pascal

> Le 26 avr. 2020 à 00:43, Michael Richardson  a écrit :
> 
> 
> Pascal Thubert \(pthubert\)  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 , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] AP-ND 22

[Benjamin Kaduk]

On Sun, Apr 26, 2020 at 09:10:33AM +0200, Abdussalam Baryun wrote:
>   The draft should indicated on top first page that it updates RFC6775,
> 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

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] AP-ND 22

[Abdussalam Baryun]

  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)  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)  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?
>

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
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] AP-ND 22

[Michael Richardson]

Pascal Thubert \(pthubert\)  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 , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] AP-ND 22

[Pascal Thubert (pthubert)]

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' ; Rene Struik ; 
Mohit Sethi 
Cc: 6lo-cha...@ietf.org; Shwetha Bhandari (shwethab) ; Jim 
Schaad ; Erik Kline ; 6lo@ietf.org
Subject: AP-ND 22

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


[cid:image001.png@01D61A53.AE322D20]
Pascal Thubert
PRINCIPAL ENGINEER.ENGINEERING
pthub...@cisco.com
Tel: +33 49 723 2634
 cisco.com
Cisco Systems, Inc.
45 All Des Ormes Regus Centre
BP1200
06250 MOUGINS CEDEX
France
[cid:image002.gif@01D61A53.AE322D20]
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
 for Company Registration Information.


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo