Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt

[Ines Robles]

I agree with you Fernando,
thanks,
ines

On Mar 6, 2018 15:11, "Fernando Gont"  wrote:

On 03/06/2018 05:47 AM, Ines Robles wrote:
> Hi Fer,
>
>
> On 06.03.2018 10:36, Fernando Gont wrote:
>> [RFC] represents this document.
>>
>>Hex Value  Binary Value
>>   act  chg  rest Description  Reference
>>-  ---  ---  ---  -   --
>> 0x23  001   00011   RPL Option[RFC]
>> 0x63  011   00011   RPL Option(DEPRECATED) [RFC6553][RFC]
>>
>>
>> SO, while you don't say that elsewhere, it would seem to me that you
>> *are* deprecating it?
> Ah Ok, I understand, so yes, we deprecated the value of 0x63, but not
> the option, so what about to say:
>
> Something like: "
>
>  This option was originally specified in [RFC6553 <
https://tools.ietf.org/html/rfc6553>]. [I-D.ietf-roll-useofrplinfo
> <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-
filtering-05#ref-I-D.ietf-roll-useofrplinfo>] updates the registration made
in [RFC6553 <https://tools.ietf.org/html/rfc6553>] Destination
>Options and Hop-by-Hop Options registry from 0x63 to 0x23."
>
> or
>
> " This option was originally specified in [RFC6553 <
https://tools.ietf.org/html/rfc6553>].  The value of 0x63 has been
>deprecated by [I-D.ietf-roll-useofrplinfo
> <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-
filtering-05#ref-I-D.ietf-roll-useofrplinfo>], which proposes a new value
(0x23) for the RPL Option."

I like this second option. But will say "specifies" (rather than
"proposes"), since by the time this doc is published,
I-D.ietf-roll-useofrplinfo whould have been published already.

Thoughts?

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt

[Ines Robles]

Hi Fer,


On 06.03.2018 10:36, Fernando Gont wrote:

[RFC] represents this document.

Hex Value  Binary Value
   act  chg  rest Description  Reference
-  ---  ---  ---  -   --
 0x23  001   00011   RPL Option[RFC]
 0x63  011   00011   RPL Option(DEPRECATED) [RFC6553][RFC]


SO, while you don't say that elsewhere, it would seem to me that you
*are* deprecating it?
Ah Ok, I understand, so yes, we deprecated the value of 0x63, but not 
the option, so what about to say:


Something like: "

 This option was originally specified in [RFC6553 ]. [I-D.ietf-roll-useofrplinfo 
] updates the registration made in [RFC6553 ] Destination

   Options and Hop-by-Hop Options registry from 0x63 to 0x23."

or

" This option was originally specified in [RFC6553 
].  The value of 0x63 has been
   deprecated by [I-D.ietf-roll-useofrplinfo 
], which proposes a new value (0x23) for the RPL Option."


What do you think?

Thanks,

Ines.




Thanks!

Best regards,


___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-05.txt

[Ines Robles]

Hi Fernando,

Thank you very much for the updated document. It looks good to me,

Just a comment:

where states  "...This option was originally specified in [RFC6553 
]. It has been deprecated by 
[I-D.ietf-roll-useofrplinfo 
]."


I would replace "deprecated" by "updated", since the roll-I-D updates 
the RPL Option with a new value. What do you think?


Thanks,

Ines.


On 06.03.2018 03:22, Fernando Gont wrote:

Folks,

This rev is meant to address your feedback regarding opt 0x23
(draft-ietf-roll-useofrplinfo).

Please do let us know if your concerns have been addressed.

Thanks!

Cheers,
Fernando




On 03/05/2018 08:31 PM, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operational Security Capabilities for IP 
Network Infrastructure WG of the IETF.

 Title   : Recommendations on the Filtering of IPv6 Packets 
Containing IPv6 Extension Headers
 Authors : Fernando Gont
   Will(Shucheng) Liu
Filename: draft-ietf-opsec-ipv6-eh-filtering-05.txt
Pages   : 35
Date: 2018-03-05

Abstract:
It is common operator practice to mitigate security risks by
enforcing appropriate packet filtering.  This document analyzes both
the general security implications of IPv6 Extension Headers and the
specific security implications of each Extension Header and Option
type.  Additionally, it discusses the operational and
interoperability implications of discarding packets based on the IPv6
Extension Headers and IPv6 options they contain.  Finally, it
provides advice on the filtering of such IPv6 packets at transit
routers for traffic *not* directed to them, for those cases in which
such filtering is deemed as necessary.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-05
https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-eh-filtering-05


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/

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec





___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Ines Robles]

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


___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

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

[Ines Robles]

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


On 27.11.2017 23:36, C. M. Heard wrote:

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


___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec