Subject: Re: [v6ops] draft-ietf-v6ops-tunnel-loops WGLC

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Apr 2011 14:08:24 -0700

Hi Fred,

It may seem unusual for an author to comment on their own document,
however in the case of ISATAP at least I am concerned that this new
version may encourage router vendors to build products that do not
provide necessary support for legacy hosts.

In particular, I have come to understand that legacy ISATAP hosts
depend on the router advertising non-link-local IPv6 prefixes on its
ISATAP interface. If a router vendor were to read the recommendations
in this new version of the document, however, they might incorrectly
conclude that the use of non-link-local IPv6 prefixes on ISATAP
interfaces should be deprecated.

This seems like something that could be corrected with the addition
of 1-2 sentences. How would you like to proceed?

Thanks - Fred

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Thursday, March 31, 2011 2:30 AM
To: [email-masked]
Cc: [email-masked]; Ron Bonica
Subject: [v6ops] draft-ietf-v6ops-tunnel-loops WGLC

This is to initiate a one week working group last call of draft-ietf-v6ops-tunnel-loops; it will close a week from Friday. The IESG reviewed the document and asked for changes; we need to be sure we are comfortable with the changes. The diff from the version sent to the IESG last November is at http://tinyurl.com/6dhowhf

Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

---

From: Fred Baker <[email-masked]>
Date: Mon, 4 Apr 2011 23:26:39 +0200

For a change to a protocol specification? I would start by finding a working group chartered to work on protocols, and discuss it with the chair.

We've been over this, Fred, many many times. You knew the answer before you wrote the email. Act accordingly.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Apr 2011 14:42:47 -0700

No sir - not for a change to a protocol specification.
The protocol specification says what it always has said;
that being, that IPv6 ND - including router and prefix
discovery - are to be supported as specified in RFC4861
and as qualified by the specifications in RFC5214.

This is strictly a clarification to an operational
recommendation - that being, if a router vendor were to
read the *operational* recommendations in this new version
of the document, they might incorrectly conclude that the
use of non-link-local IPv6 prefixes on ISATAP interfaces
should be deprecated. That would break backwards compat,
which would render the tool useless. Hence, the operational
recommendations need to be qualified.

Fred
[email-masked]  

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]] 
> Sent: Monday, April 04, 2011 2:27 PM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]; Ron Bonica
> Subject: Re: [v6ops] draft-ietf-v6ops-tunnel-loops WGLC
> 
> For a change to a protocol specification? I would start by 
> finding a working group chartered to work on protocols, and 
> discuss it with the chair.
> 
> We've been over this, Fred, many many times. You knew the 
> answer before you wrote the email. Act accordingly.
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fred Baker
> > This is to initiate a one week working group last call of 
> draft-ietf-v6ops-tunnel-loops; it will close a week from 
> Friday. The IESG reviewed the document and asked for changes; 
> we need to be sure we are comfortable with the changes. The 
> diff from the version sent to the IESG last November is at 
> http://tinyurl.com/6dhowhf
> > 
> > Please read it now. If you find nits (spelling errors, 
> minor suggested wording changes, etc), comment to the 
> authors; if you find greater issues, such as disagreeing with 
> a statement or finding additional issues that need to be 
> addressed, please post your comments to the list.
> 
>

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 04 Apr 2011 22:13:25 -0700

Seems like an application for an errata, if it indeed is simply an
implmentation pitfall. the informational document should not be wrongly
be assumed to depricate any part of 5214 since it doesn't claim that
from outset.

I'd prefer that we continue the last call with the document that we have
given this also in the form that has cleared the iesg once already.

On 4/4/11 2:08 PM, Templin, Fred L wrote:
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Fred Baker
>     *Sent:* Thursday, March 31, 2011 2:30 AM
>     *To:* [email-masked]
>     *Cc:* [email-masked]; Ron Bonica
>     *Subject:* [v6ops] draft-ietf-v6ops-tunnel-loops WGLC
> 
>     draft-ietf-v6ops-tunnel-loops; it will close a week from Friday. The
>     IESG reviewed the document and asked for changes; we need to be sure
>     we are comfortable with the changes. The diff from the version sent
>     to the IESG last November is at http://tinyurl.com/6dhowhf
> 
>     Please read it now. If you find nits (spelling errors, minor
>     suggested wording changes, etc), comment to the authors; if you find
>     greater issues, such as disagreeing with a statement or finding
>     additional issues that need to be addressed, please post your
>     comments to the list.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Apr 2011 12:36:46 -0700

Hi Joel,

That's a good idea about filing an errata - the thought
hadn't occurred to me, so thanks for mentioning it.

Fred

> From: Joel Jaeggli [mailto:[email-masked]] 
> Sent: Monday, April 04, 2011 10:13 PM
> To: Templin, Fred L
> Cc: Fred Baker; [email-masked]; [email-masked]; 
> Ron Bonica

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Apr 2011 16:59:11 +0200

> Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding add…

WGLC closing Sunday. Any comments on the draft?

---

From: Mark Townsley <[email-masked]>
Date: Mon, 11 Apr 2011 12:30:39 +0200

I think we should have much stronger language here that filtering of protocol 41 packets breaks 6to4, along with pointers to the relevant documents discussed in v6ops as to why this causes problems. It's more than "may not be suitable for scenarios where IPv4 connectivity is essential on all interfaces" as this action can have real adverse affects on unsuspecting users. 

3.2.1.1.  Filtering IPv4 Protocol-41 Packets

   In this measure a tunnel router may drop all IPv4 protocol-41 packets
   received or sent over interfaces that are attached to an untrusted
   IPv4 network.  This will cut-off any IPv4 network as a shared link.
   This measure has the advantage of simplicity.  However, such a
   measure may not always be suitable for scenarios where IPv4
   connectivity is essential on all interfaces.

Further, I believe we should be very clear in the abstract that this is an attack vector for which there are (at the time of writing) no known reports of any malicious attacks  utilizing said vector.

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Apr 2011 04:05:52 +1200

> I think we should have much stronger language here that filtering of protocol 41 packets breaks 6to4, along with pointers to the relevant documents discussed in v6ops as to why this causes problems…

+1

In fact this issue is specifically mentioned in several places
in draft-ietf-v6ops-6to4-advisory, and is summarized in the Security
Considerations as:

   A blanket recommendation to block Protocol 41 is not compatible with
   mitigating the 6to4 problems described in this document.

This is part of a balanced recommendation; elsewhere the draft says:

   The strategic
   solution is to deploy native IPv6, making Protocol 41 redundant.

     Brian