Subject: [OPSEC] Filtering advice for RPI option in draft-ietf-opsec-ipv6-eh-filtering-04

From: "C. M. Heard" <[email-masked]>
Date: Mon, 27 Nov 2017 13:36:16 -0800

Greetings,

It seems to me that the option description and filtering advice given in

https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-04#section-4.3.4

is not consistent with the revised definition of the RPI option in

https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-19

which is now in WG last call in ROLL. I have cc:'d the authors of
useofrplinfo.

Thanks & regards,

Mike Heard

---

From: Ines Robles <[email-masked]>
Date: Tue, 28 Nov 2017 02:32:37 +0200

Thank you very much Mike!

Yes, we propose to update RFC 6553 from 0x63 to 0x23 based on:

"....[RFC6553] states  that in the Option Type field of
    the RPL Option header, the two high order bits MUST be set to '01'
    and the third bit is equal to '1'.  The first two bits indicate that
    the IPv6 node MUST discard the packet if it doesn't recognize the
    option type, and the third bit indicates that the Option Data may
    change en route.  The remaining bits serve as the option type.

Recent changes in [RFC8200] (section 4, page 8), states: "it is now
    expected that nodes along a packet's delivery path only examine and
    process the Hop-by-Hop Options header if explicitly configured to do
    so".  Processing of the Hop-by-Hop Options header (by IPv6
    intermediate nodes) is now optional, but if they are configured to
    process the header, and if such nodes encounter an option with the
    first two bits set to 01, they will drop the packet (if they conform
    to [RFC8200]).  Host systems should do the same, irrespective of the
    configuration.

    Based on That, if an IPv6 (intermediate) node (RPL-not-capable)
    receives a packet with an RPL Option, it should ignore the HBH RPL
    option (skip over this option and continue processing the header).

    Thus, this document updates the Option Type field to: the two high
    order bits MUST be set to '00' and the third bit is equal to '1'.
    The first two bits indicate that the IPv6 node MUST skip over this
    option and continue processing the header ([RFC8200] Section 4.2) if
    it doesn't recognize the option type, and the third bit continues to
be set to indicate that the Option Data may change en route.  The
    remaining bits serve as the option type and remain as 0x3. This
    ensures that a packet that leaves the RPL domain of an LLN (or that
    leaves the LLN entirely) will not be discarded when it contains the
    [RFC6553] RPL Hop-by-Hop option known as RPI...." 
[https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-19#section-3.1]

Thanks,

Ines

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 Nov 2017 10:43:31 -0500

> https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-04#section-4.3.4

a) it only coverts 0x63, and we are changing to 0x23.
b) yes, the advice to drop is not good.

I'm unclear from a quick read if this the black-list advice, or the
white-list advice.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 Nov 2017 16:00:39 +0000

Hello Michael:

Clarifiation would be that dropping 0x63 is OK but dropping 0x23 or whatever it is that IANA assigns (as Brian said) for us is not.
It would be simpler that we just remove the HbH Hdr at the egress of the RPL network systematically; this overrides a rule in RFC 8200 but still makes sense in the particular case.

Cheers,

Pascal
-----Original Message-----
From: Michael Richardson [mailto:[email-masked]] 
Sent: mardi 28 novembre 2017 16:44
To: C. M. Heard <[email-masked]>
Cc: OPSEC <[email-masked]>; Ines Robles <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
Subject: Re: Filtering advice for RPI option in draft-ietf-opsec-ipv6-eh-filtering-04

I'm unclear from a quick read if this the black-list advice, or the white-list advice.

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

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 28 Nov 2017 16:13:04 -0800

Removing the HbH header should not be necessary once the new RPI code point
is in use, if it is possible to prevail on
draft-ietf-opsec-ipv6-eh-filtering to give the right advice and to prevail
upon operators to follow said advice.

The advice now in draft-ietf-opsec-ipv6-eh-filtering is just plain wrong
for 0x23 (or whatever new code point is chosen), since the explicit intent
of useofrplino is to allow packets leaving the RPL domain to be processed
normally by RPL-unaware nodes without stripping the option. That after all
was the whole point of changing to a code point that allows nodes that
don't recognize it to ignore it.

--cmh

On Tue, Nov 28, 2017 at 8:00 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Michael:
>
> Clarifiation would be that dropping 0x63 is OK but dropping 0x23 or
> whatever it is that IANA assigns (as Brian said) for us is not.
> It would be simpler that we just remove the HbH Hdr at the egress of the
> RPL network systematically; this overrides a rule in RFC 8200 but still
> makes sense in the particular case.
>
> Cheers,
>
> Pascal
> Cc: OPSEC <[email-masked]>; Ines Robles <[email-masked]>;
> Pascal Thubert (pthubert) <[email-masked]>