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

From: "Yuchi Chen" <[email-masked]>
Date: Fri, 10 Oct 2014 12:59:17 +0800

Hi all,
 
I support the adoption for this draft. IMO, this seems like timely advice concerning the recent data on filtering of packets with extension headers.

Best regards!
--------------
Yuchi Chen

-----Original Message-----
From: OPSEC [mailto:[email-masked]] On Behalf Of Gunter Van de Velde (gvandeve)
Sent: Wednesday, October 08, 2014 6:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers
 
Dear all,
 
Many thanks for your input on this request.
OPSEC chairs will look at the received input and see together with the v6ops chairs how the IPv6 EH work could progress.
 
Kind Regards,
G/

-----Original Message-----
From: Gunter Van de Velde (gvandeve) 
Sent: 24 September 2014 11:28
To: [email-masked]
Subject: Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers
 
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
 
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 13 Oct 2014 09:09:42 +0200 (CEST)

On Mon, 13 Oct 2014, Ole Troan wrote:

> shouldn't this be a draft authored by operators? giving operational 
> recommendations coming out of... well, actual operations?

Well, another way of looking at this is that operators just want things to 
work as well as they can, so they need guidance from vendors and protocol 
designers.

Isn't this a BCOP style document? I believe at least one of the authors is 
active in one or more BCOP group.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 13 Oct 2014 09:31:55 +0200 (CEST)

On Mon, 13 Oct 2014, Ole Troan wrote:

>>> shouldn't this be a draft authored by operators? giving operational recommendations coming out of... well, actual operations?
>>
>> Well, another way of looking at this is that operators just want things to work as well as they can, so they need guidance from vendors and protocol designers.
>>
>> Isn't this a BCOP style document? I believe at least one of the authors is active in one or more BCOP group.
>
> the protocol designer's recommendation does appear pretty clear, RFC2460:
>
>   "With one exception, extension headers are not examined or processed
>   by any node along a packet's delivery path, until the packet reaches
>   the node (or each of the set of nodes, in the case of multicast)
>   identified in the Destination Address field of the IPv6 header."
>
> my point is that I don't think the IETF should be making recommendations about how they should run their network, and certainly not make recommendations that are at odds with the functioning of the protocol.

You mean you don't want non-operators in the IETF to make recommendations?

The way I see it is that vendors are making equipment based on customer 
requirements. Since a lot of vendor equipment obviously inspect packets, 
including those with extension headers along the way (probably to do 
ACLs), then this equipment is already violating the functioning of the 
protocol (which of course is nothing new).

My opinion is that it's better to look at common implementation and 
document and give recommendations where this differs from the blueprints.

What I don't like is that if we follow along this path we're basically 
saying "extension headers don't work on the Internet" which has the 
implication that fewer will use them, meaning the vendors that don't 
follow the protocol designer intention has little downside, and thus 
perpetuating the problem.

I don't know how to make it right though. I would like to see extension 
headers working well, but I also understand that people want to be able to 
do filtering.

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 13 Oct 2014 07:38:02 -0700 (PDT)

> >   identified in the Destination Address field of the IPv6 header."

RFC 7045, a standards-track document, explicitly changes that.  The 
subject draft does not make any recommendations that contradict 
RC 7045.  It supplements RFC 7045 where the latter does not fully 
nail down the behaviour.

There is also draft-gont-6man-ipv6-opt-transmit, which (if 
approved) will do the same for options that RFC 7045 does for 
extension headers.  Same commens wrt that.

> including those with extension headers along the way (probably to do ACLs),
> then this equipment is already violating the functioning of the protocol
> (which of course is nothing new).
> 
> My opinion is that it's better to look at common implementation and document
> and give recommendations where this differs from the blueprints.
> 
> What I don't like is that if we follow along this path we're basically saying
> "extension headers don't work on the Internet" which has the implication that
> fewer will use them, meaning the vendors that don't follow the protocol
> designer intention has little downside, and thus perpetuating the problem.
> 
> headers working well, but I also understand that people want to be able to do
> filtering.

RFC 7045 revises IPv6 to acknowledge the reality of packet 
inspection by forwarding devices, but lit levies requirements that, 
if followed, should make the behaviour far less destructive.  The 
sibject draft complements it with operational advice that is much in 
the same spirit.

//cmh

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Oct 2014 08:24:48 +1300

> sibject draft complements it with operational advice that is much in 

Exactly. I believe this draft, and the options draft, are *exactly* what
the IETF should do (and why we have an E in our name instead of an S;
we are not the Internet Standards Task Force). If our standards are
unrealistic, we should be the ones to do something about it...

   Brian

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Oct 2014 13:03:20 -0700

On 10/13/2014 12:24 PM, Brian E Carpenter wrote:
...
> unrealistic, we should be the ones to do something about it...

If it's that our standards are unrealistic, it would be useful to
address this as changes to the standards.

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 13 Oct 2014 13:47:19 -0700 (PDT)

> address this as changes to the standards.

That's what RFC 7045 does; it has "Updates: 2460, 2780" on its front 
page.  Similarly, draft-gont-6man-ipv6-opt-transmit (the options 
draft referred to above) has "Updates: 2460 (if approved)" in its 
front page.

//cmh

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Oct 2014 13:56:46 -0700

> draft referred to above) has "Updates: 2460 (if approved)" in its 

Right, but it's not what either this doc
(draft-gont-opsec-ipv6-eh-filtering) or
draft-gont-v6ops-ipv6-ehs-in-real-world does.

I've raised this issue before.

Joe

---

From: joel jaeggli <[email-masked]>
Date: Mon, 13 Oct 2014 22:33:40 -0700

> address this as changes to the standards.

It's not entirely unrealistic to expect a consensus about observed
reality to emerge from ops before it evolves into protocol maintenance.

The working groups remit doesn't involve changing standards so frankly
that's right out.

joel

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Oct 2014 23:50:57 -0700

> reality to emerge from ops before it evolves into protocol maintenance.

Observed reality doesn't include recommendations.

And if observed reality requires consensus, I doubt you're describing
anything that involves either observation or reality.

Joe

---

From: joel jaeggli <[email-masked]>
Date: Tue, 14 Oct 2014 00:02:21 -0700

...

The goals of the v6ops working group are:

1. Solicit input from network operators and users to identify
operational issues with the IPv4/IPv6 Internet, and
determine solutions or workarounds to those issues. These issues
will be documented in Informational or BCP RFCs, or in
Internet-Drafts.

This work should primarily be conducted by those areas and WGs
which are responsible and best fit to analyze these problems, but
v6ops may also cooperate in focusing such work.

2. Publish Informational or BCP RFCs that identify potential security
risks in the operation of shared IPv4/IPv6 networks, and document
operational practices to eliminate or mitigate those risks.

This work will be done in cooperation with the Security area and
other relevant areas or working groups.

3. As a particular instance of (1) and (2), provide feedback to
the IPv6 WG regarding portions of the IPv6 specifications that
cause, or are likely to cause, operational or security concerns,
and work with the IPv6 WG to resolve those concerns. This feedback
will be published in Internet-Drafts or RFCs.
...

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 14 Oct 2014 08:23:17 -0700 (PDT)

> I've raised this issue before.

If I correctly understand the intent, draft-gont-opsec-ipv6-eh-filtering 
is not supposed to make any recommendations that contravene RFC 2460 
as updated by RFC 7045 and draft-gont-6man-ipv6-opt-transmit.  If 
you see something specific where it does so please point it out.  I 
didn't find anything like that when I reviewed the document.

//cmh

---

From: Tim Chown <[email-masked]>
Date: Tue, 14 Oct 2014 23:46:39 +0100

> will be published in Internet-Drafts or RFCs.

… which suggests publishing the observations / problem statement in one draft in v6ops, and then progressing   recommendations in a separate document in conjuction with opsec seems perfectly reasonable?

I’m puzzled by the length of this conversation / debate…

Tim

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Oct 2014 08:57:38 +0200

cheers,
Ole

> On 10 Oct 2014, at 6:59 , Yuchi Chen <[email-masked]> wrote:
> 
> Hi all,
> 
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Oct 2014 09:15:11 +0200

cheers,
Ole