Subject: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-01.txt

From: Fernando Gont <[email-masked]>
Date: Sat, 16 Aug 2014 14:12:35 -0300

Folks,

This revision
(<http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-01.txt>)
of the I-D should address the comments that you have sent so far. Please
do let us know if this is the case.

Thanks!

Best regards,
Fernando (& co-authors)

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-opsec-ipv6-eh-filtering-01.txt
Date: Sat, 16 Aug 2014 10:07:31 -0700
From: [email-masked]
To: Will(Shucheng) Liu <[email-masked]>, Shucheng LIU (Will)
<[email-masked]>, Fernando Gont <[email-masked]>, Ron
Bonica <[email-masked]>, Fernando Gont <[email-masked]>,
Ronald P. Bonica <[email-masked]>

A new version of I-D, draft-gont-opsec-ipv6-eh-filtering-01.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-opsec-ipv6-eh-filtering
Revision:	01
Title:		Recommendations on Filtering of IPv6 Packets Containing IPv6
Extension Headers
Document date:	2014-08-16
Group:		Individual Submission
Pages:		28
URL:
http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-01.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-eh-filtering/
Htmlized:
http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gont-opsec-ipv6-eh-filtering-01

Abstract:
   This document provides advice on the filtering of IPv6 packets based
   on the IPv6 Extension Headers and the IPv6 options they contain.
   Additionally, it discusses the operational and interoperability
   implications of discarding packets based on the IPv6 Extension
   Headers and IPv6 options they contain.

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.

The IETF Secretariat

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 20 Aug 2014 12:20:40 -0700 (PDT)

Hello Fernando,

Thanks for addressing my previous comments about destination 
options.  I have a few comments on this new version.

Last paragraph of the introduction:

   Section 3 of this document discusses IPv6 extension headers and IPv6
   options, and provides advice in the area of filtering IPv6 packets
   that contain such IPv6 Extension Headers and/or options.

This needs a small editorial fix since Section 3 discusses extension 
headers and Section 4 discusses specific options.

Section 2.2:

   The advice provided in this document is only meant to guide an
   operator in configuring forwarding devices, and is *not* to be
   interpreted as advice regarding default configuration settings for
   network devices.  That is, this document provides advice with respect
   to operational configurations, but does not change the implementation
   defaults required by [RFC7045].

The second half of the first sentence is not quite tre, since the 
draft does provide advice on default processing of the CALIPSO 
option.  There is no equivalent to RFC 7045 for options, so 
presumably the defaults specified in RFC 2460 for an intermediate 
system would apply.  These are:

- pass by default all options in a Destination Options header

- obey the instructions in the top two bits of the option type for 
  options in a Hop-by-Hop Options header

My inclination is to suggest that Section 2.2 be beefed up to point 
this out, e.g., by saying

   The advice provided in this document is only meant to guide an
   operator in configuring forwarding devices, and is *not* to be
   interpreted as advice regarding default configuration settings for
   network devices.  That is, this document provides advice with respect
   to operational configurations, but does not change the implementation
   defaults required by [RFC7045] and [RFC2460].

and to suggest that all advice for option implementation defaults be 
left out of this document -- at most, it should be pointed out what 
the default configuration default _is_.

Section 3.3.1.1, uses of Hop-by-Hop option header, fails to mention 
the following hop-by-hop options:

   o  Quick-Start     [RFC4782]
   o  CALIPSO         [RFC5570]

I missed this the first time around, sorry about that.  Also, as an 
editorial nit, I would suggest either including the type in this 
list, as was done in Section 3.3.6.2, or leaving it out in both 
places (and while I am at it, I would also suggest listing the 
options in the same subsection in both places, either Uses or 
Specification -- I also missed that in my previous comments).

Section 3.10.5, advice regarding experimental use headers (253/254):

Advice from -00:
   Routers, security gateways, and firewalls SHOULD have configuration
   knobs for IP packets that contain this extension header to select
   between "ignore & forward" and "drop & log".  Otherwise, no
   legitimate experiment using these options will be able to traverse
   any IP router.

   The aforementioned configuration knob SHOULD default to "drop & log".

   Special care needs to be taken in the case of "drop & log".  Devices
   SHOULD count the number of packets dropped, but the logging of drop
   events SHOULD be limited so as to not overburden device resources.

Advice from -01:
   Intermediate systems should discard packets containing these 
   extension headers.

Presumably the reason for this change to avoid giving advice to 
implementors regarding the default configuration and to focus on 
advice to operators on what configuration to set.  If so, maybe 
something along the following lines would have less dissonance with 
the preceding paragraphs (c.f. jumbogram option advice):

Alternative advice:
   Intermediate systems should discard packets containing these 
   extension headers.  This policy could be overridden in specific 
   environments where the experimental headers are used.

General comment on Section 4, advice about options:  should the 
advice be nuanced to distinguish between cases where an option 
appears in a Hop-by-Hop option header vs a Destination Options 
header?  For instance, should the advice be to discard all options 
that are supposed to appear only in a Destination Options header if 
they appear in a Hop-by-Hop options header?  This is done for Tunnel 
Encapsulation Limit but not for other destination options (other 
than Line-Identification, for which the advice is unconditional 
discard).  Also, should it be recommended that implemention allow 
separate polcies for these cases?

Section 4.3.6.5, advice on Router Alert option:

Current text:
   Intermediate systems should discard packets that contain this option.

Recommended text:
   Intermediate systems should discard packets that contain this option.
   This policy could be overridden in specific environments where
   support for RSVP or similar protocols is desired.

Section 4.3.8.5, advice on processing CALIPSO option: eliminate the 
text that provides advice about implentation defaults.

Section 4.3.17.1, Uses if RFC3692-style experimental options: I 
would recommend s/MUST NOT/must not/ since this document does not 
levy that requirement -- RFC 4727 does.

Section 4.3.17.5, advice regarding RFC3692-style experimental options:

Current text:
   Intermediate systems should discard packets that contain these
   options.

Recommended text:
   Intermediate systems should discard packets that contain these
   options.  This policy could be overridden in specific environments 
   where support for one or more of these options is desired.

Unknown options: there is no section covering these.  I am not 
concerned if the RFC 2460 implementation defaults (i.e., obey the 
instructions in the top two bits of the option type) is 
operationally acceptable.

Thanks for considering these comments.

Mike Heard

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Aug 2014 10:58:14 -0300

Hi, Mike,

Thanks so much for your feedback! Please find my comments in-line....

> headers and Section 4 discusses specific options.

Yep. Fixed.

> option.  

We will remove this "default configuration" thing for this option, such
that there is coherence throughout the document in this respect
(recommending defaults for options but not for EHs would likely lead to
confusion).

Thoughts?

> the default configuration default _is_.

Agreed.

> Specification -- I also missed that in my previous comments).

All of these are good points. We will fix all of them in the next
revision. Thanks!

> advice to operators on what configuration to set. 

Exactly. This was the motivation for removing such text.

> If so, maybe 

The thing is that "this policy could be overriden.." sounds a bit like
defining configuration defaults. mm.. how about:

    Intermediate systems should discard packets containing these
    extension headers.  Only in in specific scenarios in which
    experiments are to be performed, an operator may want to permit
    these extension headers.

?

> header?

Yes. Even if te advice ends up being the same. I will check if there are
any options (other than the padding ones) that cane be included in
different EH types (of the top of my head, most of the options are meant
for specific EH types).

> For instance, should the advice be to discard all options 
> discard). 

Yes. I will make sure we do this for all options.

> Also, should it be recommended that implemention allow separate polcies for these cases?

I would think so.

>    support for RSVP or similar protocols is desired.

I agree with the recommended text, but as with the experimental options
above, I'd edit it as:

  Intermediate systems should discard packets that contain this option.
  Only in specific environments where support for RSVP or similar
  protocols is desired should this option be permitted.

Thoughts?

> text that provides advice about implentation defaults.

Will do.

> levy that requirement -- RFC 4727 does.

Correct. Will do.

>    where support for one or more of these options is desired.

How about tweaking this text as I did above?

> operationally acceptable.

mm.. let me think about this one -- I'll come back to you.

Thanks so much!

Best regards,
-- 
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: Thu, 21 Aug 2014 07:53:52 -0700 (PDT)

Hello Fernando,

Thanks for the quick reply.  Your responses all work for me.  Just a 
couple of small comments ...

>     experiments are to be performed, an operator may want to permit

That works for me (as do the other tweaks of a similar nature that 
you suggested).  I suggested the text "This policy could be 
overridden ..." because it appeared elsewhere in the draft.  If you 
don't like it here, you may want to do a "search and destroy" 
mission to root it out in other places where it appears.

> different EH types (of the top of my head, most of the options are meant

As far as I could tell, the padding options are the only ones that 
are allowed to appear in both kinds of option extension headers.

> mm.. let me think about this one -- I'll come back to you.

Sounds good.  Thanks again for your efforts.

Mike Heard

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Aug 2014 12:05:26 -0300

Hi, Mike,

Thanks again for your feedback! Comments in-line....

> mission to root it out in other places where it appears.

It would work for *me*. But I guess tweaking the text a bit might avoid
confusion to others.. -- I will proceed with the search & destroy as
indicated. :-)

> are allowed to appear in both kinds of option extension headers.

So I guess that for the most part, there's no need of a "per-EH-type"
kind of policy for IPv6 options?

Thanks!

Best regards,

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 21 Aug 2014 08:57:54 -0700 (PDT)

> kind of policy for IPv6 options?

I'm not sure I'd quite say that.

For one thing, I think you agreed that the advice should be to 
discard packets with options that appear in the wrong kind of 
options header.  So the recommended policy for a given option would 
depend on the type of option header in which it appears.  But that 
doesn't mean that you need to write a separate section for each 
option type / EH type combination.

Also, in the case of unknown options, or RFC3692-style experimental 
options, if the default action (ignore or discard, depending on the 
upper two bits of the option code) is deemed too permissive, then 
there is clear benefit to allowing a different policy depending on 
the type of option header.

Finally, I could also see a case for an intermediate box to perform 
detailed scrutiny of stuff in a HbH option header but to just pass 
all stuff in a Destination Options header -- not just because of 
greater security issues with HbH but because of implementation 
constraintes (HbH is in a fixed position and can appear only once).  
That would be a global per-EH-type kind of policy.

I'm putting these last two things on the table mainly as food for 
thought.

Thanks

Mike Heard

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 Aug 2014 06:27:56 -0300

On 08/21/2014 12:57 PM, C. M. Heard wrote:
> options header. 

After giving this one some thought, I'd say that my take is that the
best option is to produce a 6man document that specifies the default
processing of options, such that we complement RFC7045 (which does that
for IPv6 extension headers). -- this had been suggested by Brian
Carpenter already.

After all, advice of the kind "Drop this packet if it contains two
Router Alert options is really a default setting, rather than something
an operator would configure".

In the worst case scenario (if the 6man document doesn't fly there, we
may incorporate such defaults in this document).

Thoughts?

Thanks!

Best regards,

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 22 Aug 2014 07:39:59 -0700 (PDT)

[ 6man added to cc: list ]

Fernando, I would have to agree that there is a need for a 
standards-track document doing for options what RFC 7045 did for 
extension headers.  The current rules in RFC 2460 for intermediate 
systems are:

(a) Inspect options in a hop-by-hop options header; process known 
options as specified in the document defining the option, otherwise 
take the action indicated in the upper two bits of the option code.

(b) Pass destination options transparently; do not inspect them or 
filter packets based on them.

There really aren't any provisions for intermediate systems to 
filter IPv6 packets on the basis of the options they contain.  That 
is not consonant with oft-repeated operational requirements.  The 
new document that you propose would need to provide for such 
filtering.  When that is done, the above rules are (IMHO) a 
reasonable starting point for deault behavior, modulo refinements 
such as discarding packets with options that appear in the wrong 
kind of options header.

Mike Heard