Subject: [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Wed, 24 Sep 2014 09:27:40 +0000

Dear,
 
Please find this request for WG adoption for "Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers"
The authors of the work explicitly asked for "Call for WG adoption" in its current state. 
 
Latest draft can be found at:
http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02 

(1) Do you support for adopting the draft as OPSEC WG item?

This call for WG adoption will end 8 October 2014.

Kind Regards,
OPSEC chairs

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Sep 2014 13:55:25 +1200

I'm responding to the relevant WG as requested.

I think the document is useful and realistic, given the real world
in which firewalls live. I think OPSEC is the appropriate WG to adopt it.

I am not convinced it should be a BCP; partly for the reason Joe
gives, and partly because the advice may evolve in the light of
experience. Making the document Informational softens that difficulty.

    Brian

On 25/09/2014 07:39, Joe Touch wrote:
> I am concerned about V6OPS advice that effectively deprecates IPv6
> capabilities in a BCP. IMO, if these are significant security or
> performance issues, they should be reviewed within INTAREA as updates to
> the IPv6 spec.
> 
> To do this in a BCP undermines the spec without updating it.
> 
> Some other comments:
> 
> The advice sections in this doc fail to use RFC2119-style
> recommendations. In some cases, lower-case is used, and in other cases
> odd phrasing is used that avoids RFC2119 keywords.
> 
> If this is indeed advice in the form of a BCP, the actual advice should
> be provided in RFC2119-style format.
> 
> Also, the term "intermediate systems" is used in a NOTE and is not
> defined; this doc should clearly identify the type of systems that it is
> intended for (e.g., routers).
> 
> Joe
> 
> On 9/24/2014 2:32 AM, Gunter Van de Velde (gvandeve) wrote:
>> Dear,
>>
>> OPSEC Chairs requested "Call for WG adoption" on draft-gont-opsec-ipv6-eh-filtering.
>>
>> Please voice your reflexions in OPSEC WG
>>
>> G/
>>
>> -----Original Message-----
>> From: OPSEC [mailto:[email-masked]] On Behalf Of Gunter Van de Velde (gvandeve)
>> Sent: 24 September 2014 11:28
>> To: [email-masked]
>> Subject: [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers
>>
>> Dear,
>>  
>> _______________________________________________
>> OPSEC mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/opsec
>>
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 25 Sep 2014 10:14:45 -0400

> (1) Do you support for adopting the draft as OPSEC WG item?

I do.

I'm sad, but I do....

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Sep 2014 07:32:19 -0700

Hi, all,

On 9/24/2014 11:56 PM, Fred Baker (fred) wrote:
> For the record, Opsec is considering adopting the draft, not v6ops;

I'm including both groups in this response.

> Gunter asked v6ops to chime in on the discussion in opsec. The author
> has been asking both sets of chairs, and I haven’t seen the
> groundswell of support, or even comment, that would lead in the
> direction of v6ops adoption. 

When a doc is "shopped around", that tells me it's not ready for
anything. The ADs should determine where a doc belongs and should alert
related WGs at that time - and during WGLC.

> I personally share your concerns; if we
> want to deprecate parts of RFC 2460, I think we need to do that in
> 6man.

I disagree. This is a significant change to the IPv6 spec; the 6man
charter excludes those:

---
The 6man working group is responsible for the maintenance, upkeep, and
advancement of the IPv6 protocol specifications and addressing
architecture. It is not chartered to develop major changes or additions
to the IPv6 specifications....

> What v6ops or opsec would be chartered to do is give advice.

Agreed. IMO, advice should be limited to explaining cases that fall
under MAY or SHOULD in other documents.

Anything that overrides a MUST or MUST NOT needs to happen in the WG
chartered to update the original doc; AFAICT, that's only INTAREA in
this case (if not, it's certainly not *OPS or *MAN).

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Sep 2014 08:38:51 -0700

On 9/25/2014 7:58 AM, Fernando Gont wrote:
...
> May I ask where does draft-gont-opsec-ipv6-eh-filtering try to deprecate
> anything? 

In every statement where an existing IPv6 required capability is changed.

E.g.:
- demotes requirements to "SHOULDS" (most x.x.x.5 sections).

- deprecates the flags in HBH options intended to declare how an option
is handled when not known by providing advice specific to each option
type that does not consider the flag setting

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Sep 2014 12:45:44 -0300

> related WGs at that time - and during WGLC.

The document has never been "shopped around". Please see my response to
Fred.

> this case (if not, it's certainly not *OPS or *MAN).

Could you please point out which part of this I-D overrides a MUST or
SHOULD?

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Sep 2014 12:52:43 -0300

> - demotes requirements to "SHOULDS" (most x.x.x.5 sections).

They are lowercase shoulds. And not protocol changes, but operational
advice.

> type that does not consider the flag setting

The advice in this I-D essentially mimics RFC7045 for options. That was
the intent. Am I missing something?

Thanks,

---

From: Tim Chown <[email-masked]>
Date: Thu, 25 Sep 2014 17:13:10 +0100

> the intent. Am I missing something?

Hi,

I would say that putting forward operational recommendations in a style similar to RFC4890, which does not use RFC2119 language, is both appropriate and useful.

I agree that were there specific protocol changes then of course these should be run through 6man (most likely) to update existing RFCs.

There are many drafts that fall between v6ops and opsec, where the scope is IPv6 operational security practices.

Tim

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Sep 2014 09:39:54 -0700

> They are lowercase shoulds. And not protocol changes, but operational

I see no utility to a BCP that makes operational recommendations without
qualifying them in RFC2119 language.

Further, this doc does not explicitly indicate the distinction between
upper and lowercase of the RFC2119 terms. IMO, except for use in
discussion prose, those terms need to be avoided at all cost except
where used in their RFC2119 sense.

> the intent. Am I missing something?

The places where you provide contradictory advice, notably (from 7045):

   RFC 2460 requires destination hosts to discard packets containing
   unrecognised extension headers.  However, intermediate forwarding
   nodes SHOULD NOT do this, since that might cause them to
   inadvertently discard traffic using a recently standardised extension
   header not yet recognised by the intermediate node.  The exceptions
   to this rule are discussed next.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Sep 2014 15:58:03 -0300

> qualifying them in RFC2119 language.

Yes, the document track should be changed to Informational, as suggested
by Brian.

> upper and lowercase of the RFC2119 terms. 

It's the uppercase that are special, not the lowercase. There's a single
bogus RFC2119 usage that needs to be changed to lowercase.. and that's it.

>    to this rule are discussed next.

Looks like you've decided to ignore the next paragraph, which says:

   If a forwarding node discards a packet containing a standard IPv6
   extension header, it MUST be the result of a configurable policy and
   not just the result of a failure to recognise such a header.  This
   means that the discard policy for each standard type of extension
   header MUST be individually configurable.  The default configuration
   SHOULD allow all standard extension headers.

and also ignore the Security Considerations, which says:

   These changes do not affect a firewall's ability to filter out
   traffic containing unwanted or suspect extension headers, if
   configured to do so.  However, the changes do require firewalls to be
   capable of permitting any or all extension headers, if configured to
   do so.  The default configurations are intended to allow normal use
   of any standard extension header, avoiding the connectivity issues
   described in Sections 1 and 2.1.

draft-gont-opsec-ipv6-eh-filtering provides configuration advice, *not*
a default policy or the like (and this is pretty clear in the Intro). So
it doesn't go against RFC7045. For instance, that was the main/sole goal
of the latest rev of the I-D

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Sep 2014 13:24:11 -0700

...
> bogus RFC2119 usage that needs to be changed to lowercase.. and that's it.

The doc needs to remove the definition of 2119 language, and IMO also
needs to add a statement that no use of those terms is intended in the
2119 sense.

When both are used (both 2119-sense and not), I use the following text
to make the distinction explicit:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

>    SHOULD allow all standard extension headers.

The term "standard" in that paragraph refers to a specific set of
extensions defined in RFC2460 - i.e., those that are deemed mandatory to
support.

Your doc refers to other extensions that were not defined in RFC2460,
and for which that paragraph does not apply.

>    described in Sections 1 and 2.1.

The recommendations in your document are to have a default that
overrides the security considerations in RFC2460. Your doc would have to
say something like "when the following attack is noticed,..." or "in the
following specific use case...".

> of the latest rev of the I-D

Advice that doesn't give a specific context is advice to override a
default, IMO. You need a lot more context to explain when and/or where
such overrides are relevant.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Sep 2014 13:25:38 -0700

PS - I have a day job, and this isn't it. If others care about this doc,
I encourage them to speak up.

In its current form, I don't support its adoption by any WG.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Sep 2014 08:30:42 +1200

I've given my views of this draft on the appropriate list, but...

On 26/09/2014 04:39, Joe Touch wrote:
...
> qualifying them in RFC2119 language.

Why? The word "should" is a perfectly clear word in the English language.
RFC 2119 qualifies its meaning in a particular way, but there's nothing
in the IETF process that requires us to use that qualification.

> upper and lowercase of the RFC2119 terms. 

Huh? It cites RFC 2119 in the prescribed words, which make it clear
that "SHOULD" is a qualified version of "should". It's quite common for
RFCs to use both. (The only word that can be problematic in that way
is "may" - I have take to using "might" to avoid the ambiguity in
"may".)

> IMO, except for use in

Why? RFC 2119 is perfectly clear about how it qualifies normal usage.

   Brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Sep 2014 14:17:51 -0700

> in the IETF process that requires us to use that qualification.

If this issued as a BCP, there should be recommendations in RFC2119
language. A BCP with no such recommendations doesn't explain current
practice sufficiently, IMO.

> is "may" - I have take to using "might" to avoid the ambiguity in

Once you cite RFC2119, you're saying that the key words used have
special meaning. There's nothing in RFC2119 that requires them to be
capitalized; the use of capitals is mentioned only in the abstract:

	These words are often capitalized.

Often. Not exclusively. IMO, if you want to mix 2119 and non-2119 it is
necessary to be explicit in how to tell the difference.

> Why? RFC 2119 is perfectly clear about how it qualifies normal usage.

I found only text that defines their use as exclusively having special
meaning:

  This document defines these words as they should be
   interpreted in IETF documents.

Can you point to where you found the doc to say otherwise?

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Sep 2014 10:56:34 +1200

I agree it would have been better if RFC 2119 had specified
upper case letters. Apart from that, I have said all I plan
to say on this topic.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Sep 2014 20:24:21 -0300

Hi, Joe,

> needs to add a statement that no use of those terms is intended in the
[...]

FWIW, I have no issues adding such a description if deemed necessary.
However, if anything, this is easily fixable, and certainly not a
show-stopper.

> and for which that paragraph does not apply.

That's not correct. NPlease see Section 1.1 of RFC7045, which says:

   In this document, "standard" IPv6 extension headers are those
   specified in detail by IETF Standards Actions [RFC5226].
   "Experimental" extension headers include those defined by any
   Experimental RFC and the header values 253 and 254 defined by
   [RFC3692] and [RFC4727] when used as experimental extension headers.
   "Defined" extension headers are the "standard" extension headers plus
   the "experimental" ones.

> overrides the security considerations in RFC2460.

Nope. Please check Section 2.2 of our I-D, which says:

   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
   [draft-gont-6man-ipv6-opt-transmit].

i.e., our recommendations shouldn't be used as "default configurations"
of any devices.

> such overrides are relevant.

If you look closely at the I-D, it is essentially a "default allow",
modulo HBH, in which case we provide recommendations 8a few options)
well within RFC7045.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Sun, 28 Sep 2014 22:57:03 -0700

On 9/25/2014 4:24 PM, Fernando Gont wrote:
...
>    network devices.  
...
> i.e., our recommendations shouldn't be used as "default configurations"

So these are not defaults...

...
> If you look closely at the I-D, it is essentially a "default allow",

except that they are. Esp. two of the specific recommendations.

Perhaps this most clearly highlights the reason I don't see the utility
or purpose in this doc.

Operational recommendations should be explained in the context of
existing standards, and only where they deviate from them in a specific
operational context.

Joe