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

From: Ines Robles <[email-masked]>
Date: Thu, 1 Mar 2018 19:37:27 +0200

Thank you very much Mike for addressing this topic :) , and thank you 
Fernando for bringing this up. :)

We added a clarification related to this issue in the just submitted new 
version , https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-22

Cheers,

Ines.

On 01.03.2018 05:04, C. M. Heard wrote:
> On Wed, Feb 28, 2018 at 8:39 AM, Fernando Gont <[email-masked]> wrote:
>> On 02/28/2018 01:29 PM, C. M. Heard wrote:
>>> 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.
>> It would seem that such decision has been a response to publication of
>> 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
>> required not to?
> 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."
>
>> Am I missing something, or is the motivation of the change to "comply
>> 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

---

From: Fernando Gont <[email-masked]>
Date: Sat, 3 Mar 2018 10:34:43 -0300

On 11/28/2017 01:00 PM, Pascal Thubert (pthubert) 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.

Will do.

Thanks!

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