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

From: Fernando Gont <[email-masked]>
Date: Wed, 28 Feb 2018 05:24:35 -0300

On 11/28/2017 12:43 PM, Michael Richardson wrote:
> 
> C. M. Heard <[email-masked]> wrote:
>     > 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
> 
> 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.

This is meant to be black-list advice. The current advice in our
document is to drop packets with this option at non-RPL routers. Isn't
this advice aligned with the fact that the option type bits note that
nodes that do not support this option should drop the corresponding packets?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 28 Feb 2018 08:29:05 -0800

On Wed, Feb 28, 2018 at 12:24 AM, Fernando Gont wrote:
>>    > It seems to me that the option description and filtering advice given in
>> a) it only covers 0x63, and we are changing to 0x23.

The option type is being changed from 0x63 to 0x23 precisely so
that non-RPL routers will NOT drop packets with that option.
See https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-21,
which has recently been submitted to the IESG for publication.

Thanks

Mike Heard

---

From: Fernando Gont <[email-masked]>
Date: Wed, 28 Feb 2018 13:39:35 -0300

> which has recently been submitted to the IESG for publication.

It would seem that such decision has been a response to publication of
RFC8200... but I don't follow.

What's the reason for which 0x63 was required to be dropped, but 0x23 is
required not to?

Am I missing something, or is the motivation of the change to "comply
with RFC8200"?  -- f so, such change is not really required.

Thoughts?

Thanks!

Best regards,

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 28 Feb 2018 19:04:31 -0800

> RFC8200... but I don't follow.

The wording of the draft can certainly give that impression, but that is not
the case. The change was made to prevent packets with the RPI option that
exit from an RPL domain from being discarded by a non-RPL node.

> What's the reason for which 0x63 was required to be dropped, but 0x23 is

Because 0x63 has the upper two bits that say "discard the packet" if the
option is unrecognized, which would be the case for a non-RPL aware
node, while 0x23 has the upper two bits that say "skip over this option
and continue processing the header."

> with RFC8200"?  -- [i]f so, such change is not really required.

The motivation is not to comply with RFC 8200, but rather to make it possible
for an RPL-aware end node to send an IPv6 datagram to a non-RPL aware
node on  the general Internet without the need for IP-in-IP encapsulation.
See the example in Section 6.2.1 of the above-referenced draft. If a
firewall were to (un)helpfully filter packets with the RPI option, then
that objective could not be realized.

Mike Heard