Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-ipv6-11.txt

From: [email-masked]
Date: Thu, 8 Jul 2010 13:00:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Traversal Using Relays around NAT (TURN) Extension for IPv6
	Author(s)       : G. Camarillo, et al.
	Filename        : draft-ietf-behave-turn-ipv6-11.txt
	Pages           : 15
	Date            : 2010-07-08

This document adds IPv6 support to Traversal Using Relays around NAT
(TURN).  IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6,
and IPv6-to-IPv4 relaying.  This document defines the REQUESTED-
ADDRESS-FAMILY attribute for TURN.  The REQUESTED-ADDRESS-FAMILY
attribute allows a client to explicitly request the address type the
TURN server will allocate (e.g., an IPv4-only node may request the
TURN server to allocate an IPv6 address).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-ipv6-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 08 Jul 2010 15:59:17 -0400

This revision removes a note that didn't make sense anymore given the
changes made in -10.

Simon

On 2010-07-08 16:00, [email-masked] wrote:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Jul 2010 13:34:25 -0700

I was just reading all the new drafts for IETF 78 and wondering two things about this draft. 

It seems to me that the MUST ignore DF solution that got added would break any application level path MTU discover algorithm. Am I understanding this correctly? It seemed like we had a lot of discussion around adding this in the base TURN spec and I can't find much discussion about why we decided to remove this in v6. I'm concerned that it be possible to build application layer MTU discovery because algorithm based on ICMP seem to not work in a high percentage of the cases due to ICMP blocking. 

The idea that this a device can know if a v6 address is not tunneled seems impossible to implement to me. The idea that this MUST NOT work if you have 6to4 or teredo address seems like a pretty big limitation to me - did anyone run this by v6ops? I wonder if the WG might be able to figure a better way to solve this security problem. The security section substantial under represents the amount of amplification possible because one can send a packet much larger than 1500 and still have this work and the bandwidth application is O(N^2) so moving N from 1500 to say 16 k makes a huge difference. 

I note the alternative behavior for v4 to 6 fragmentation results in less bandwidth usage than the preferred behavior so I wonder why the preferred is preferred. 

>> implementation to automatically retrieve the ASCII version of the

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Simon Perreault <[email-masked]>
Date: Mon, 19 Jul 2010 19:17:59 -0400

On 07/19/2010 04:34 PM, Cullen Jennings wrote:
> It seems to me that the MUST ignore DF solution that got added would
> break any application level path MTU discover algorithm. Am I
> understanding this correctly? It seemed like we had a lot of
> discussion around adding this in the base TURN spec and I can't find
> much discussion about why we decided to remove this in v6. I'm
> concerned that it be possible to build application layer MTU
> discovery because algorithm based on ICMP seem to not work in a high
> percentage of the cases due to ICMP blocking.

As far as I know, the DONT-FRAGMENT attribute was only ever discussed
once, in this thread:
http://www.ietf.org/mail-archive/web/behave/current/msg07095.html

Here's a recap of the proposal:

- For IPv6-to-IPv6, DONT-FRAGMENT would be ignored. (No change to
current text.)

- For IPv4-to-IPv6, DONT-FRAGMENT would be ignored. (No change to
current text.)

- For IPv6-to-IPv4, we would have the following behaviours:

  - Preferred behaviour
    - DONT-FRAGMENT absent
      - Fragment header absent
        => Set DF=1
      - Fragment header present
        => Set DF=0
    - DONT-FRAGMENT present
      - Fragment header absent
        => Set DF=1
      - Fragment header present
        => Set DF=?
  - Alternative behaviour
     - DONT-FRAGMENT absent
       => Set DF=?
     - DONT-FRAGMENT present
       => Set DF=1

As I never got any feedback on this, I refrained from changing the text.

Now, I would suggest filling in the two '?' above with '1' and '0':

  - Preferred behaviour
    - DONT-FRAGMENT absent
      - Fragment header absent
        => Set DF=1
      - Fragment header present
        => Set DF=0
    - DONT-FRAGMENT present
      - Fragment header absent
        => Set DF=1
      - Fragment header present
        => Set DF=1
  - Alternative behaviour
     - DONT-FRAGMENT absent
       => Set DF=0
     - DONT-FRAGMENT present
       => Set DF=1

OK?

> The idea that this a device can know if a v6 address is not tunneled
> seems impossible to implement to me. The idea that this MUST NOT work
> if you have 6to4 or teredo address seems like a pretty big limitation
> to me - did anyone run this by v6ops? I wonder if the WG might be
> able to figure a better way to solve this security problem.

I think I'll let the WG speak on that...

> The
> security section substantial under represents the amount of
> amplification possible because one can send a packet much larger than
> 1500 and still have this work and the bandwidth application is O(N^2)
> so moving N from 1500 to say 16 k makes a huge difference.

I'm not sure I understand that. If you could propose changes to the
current text, that would probably be helpful.

> I note the alternative behavior for v4 to 6 fragmentation results in
> less bandwidth usage than the preferred behavior so I wonder why the
> preferred is preferred.

You mean that a TURN server should always reassemble fragments?

There are many variables other than bandwidth usage that need to be
considered before we move away from draft-ietf-behave-v6v4-xlate...

Thanks,
Simon

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 19 Jul 2010 16:52:13 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cullen Jennings
> Sent: Monday, July 19, 2010 1:34 PM
> To: Simon Perreault; David Harrington; Gonzalo Camarillo
> Cc: [email-masked]
> Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-ipv6-11.txt
> 
> 
> understanding this correctly? It seemed like we had a lot of discussion
> around adding this in the base TURN spec and I can't find much
> discussion about why we decided to remove this in v6. I'm concerned
> that it be possible to build application layer MTU discovery because
> algorithm based on ICMP seem to not work in a high percentage of the
> cases due to ICMP blocking.
> 
> to me - 

If a host is running Teredo or 6to4, that host has an IPv4 address (which
is why it is running Teredo or running 6to4) and has an IPv6 address (by
virtue of running Teredo or 6to4).  So, a host running Teredo or running
6to4 has both an IPv4 and an IPv6 address.  Its IPv4 address might be
limited by its NAT (due to the NAT's filtering or mapping behavior); there 
is no similar filtering on 6to4 or Teredo addresses.  So it shouldn't
need TURN-v6 in order to get an IPv4 address or in order to get an IPv6
address.

I don't believe there is any harm caused by this restriction.  If there
is, can you provide the use case?

> did anyone run this by v6ops?

No.

Teredo and 6to4 seem to be falling out of favor as witnessed by Google and
Yahoo citing Teredo and 6to4 as reasons they are reluctant to add AAAAs to
their properties.  To be fair, Teredo and 6to4 are not cited as the sole
reasons, but they are cited as reasons.

Regarding v6ops: I realize draft-vandevelde-v6ops-harmful-tunnels is not a 
v6ops WG document but it appears to have reasonable consensus.  And as we 
all know, TURN adds a hop to the media path which is not along its normal 
routing path, which is done again by 6to4 and Teredo -- so the combination 
of TURN and Teredo/6to4 would incur yet worse performance problems than seen

today with just Teredo/6to4.  And today's performance complaints about 6to4 
and Teredo are almost solely around TCP and using web sites, not interactive

voice/video which are more sensitive to performance issues.

-d

> I wonder if the WG might be able
> to figure a better way to solve this security problem. The security
> section substantial under represents the amount of amplification
> possible because one can send a packet much larger than 1500 and still
> have this work and the bandwidth application is O(N^2) so moving N from
> 1500 to say 16 k makes a huge difference.
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 20 Jul 2010 14:05:02 -0700

> As I never got any feedback on this, I refrained from changing the text.

well a big problem here is most the people that care about TURN do not read the behave list anymore because the volume of stuff they don't care about is too large. 

>      - Fragment header present

I'm having a hard time getting my head around all this stuff again - that may be fine but I'm not sure. The key thing from my point of view is that there is some way to do an application level path MTU discovery when using TURN that does not rely on receiving ICMP packets from intermediaries as packets from intermediaries are often blocked. This might solve it - I'm just not sure. Thoughts?

> You mean that a TURN server should always reassemble fragments?

Well, I would not want to mandate that as some servers may not want to deal with the state issues of doing reassembly but it seems like the preferred behaviors should be to reassemble but that is not required. 

> considered before we move away from draft-ietf-behave-v6v4-xlate...

Fair enough - one solution would be to explain pros and cons of both and let devices do either. 

Cullen Jennings

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 20 Jul 2010 14:42:33 -0700

> need TURN-v6 in order to get an IPv4 address or in order to get an IPv6

The host might know that the v6 interface is over 6to4 but it's not clear how an applications that was using TURN would know this. This is the usually problem between what the host might know when using something like IPSEC and what an application running on that host can find out. The whole point from the OS point of view was for the application not to know or care how the v6 interface had shown up. We also have issues such as the when the tunnels is not terminated on the same host as the app is running on - it might terminate on a NAT/router or it might terminate on host that is running several virtual machines and and the application is running on a virtual machine. 

> is, can you provide the use case?

Yes, the security of this design is based on the idea that a TURN system will be able to detect that it's IPv6 packets are not using a tunnel technology. This is not an architecture that meets with reality - tunnels are hard to detect by design and there are lots of forms of them. 

> reasons, but they are cited as reasons.

Sure - makes sense why Google does not want to point DNS at things where the v6 connectivity is dependent on something as ephemeral as one of these tunnels but deployment of v6 over various tunnels seems fairly likely to continue for a long time. Perhaps not for servers that have to be reachable after a AAAA query but certainly for end hosts situations. 

> v6ops WG document but it appears to have reasonable consensus.

Hmm - not sure about that but lets assume you are right 

>  And as we 
> today with just Teredo/6to4.  

I agree but my point is that I don't see how a TURN application can detect this. 

> And today's performance complaints about 6to4 
> voice/video which are more sensitive to performance issues.j

Not really disagreeing with you but it will happen -  the experience with VoIP over VPN and other relays is certainly that relays are not good but VoIP does often work fine when it has to go through multiple relays. Clearly choosing a v4 address is often going to work better than choosing a v6 address in some of these situations but ICE can help figure out which is best.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 20 Jul 2010 15:16:12 -0700

> Sent: Tuesday, July 20, 2010 2:43 PM
> To: Dan Wing
> Cc: 'David Harrington'; 'Gonzalo Camarillo'; [email-masked]
> The host might know that the v6 interface is over 6to4 but it's not
> clear how an applications that was using TURN would know this. This is
> the usually problem between what the host might know when using
> something like IPSEC and what an application running on that host can
> find out. The whole point from the OS point of view was for the
> application not to know or care how the v6 interface had shown up. We
> also have issues such as the when the tunnels is not terminated on the
> same host as the app is running on - it might terminate on a NAT/router
> or it might terminate on host that is running several virtual machines
> and and the application is running on a virtual machine.
> 
> >
> > I don't believe there is any harm caused by this restriction.  If
> > there is, can you provide the use case?
> 
> Yes, the security of this design is based on the idea that a TURN
> system will be able to detect that it's IPv6 packets are not using a
> tunnel technology. This is not an architecture that meets with reality
> - tunnels are hard to detect by design and there are lots of forms of
> them.

The SECDIR review at
http://www.ietf.org/mail-archive/web/secdir/current/msg01581.html said:

    As the Security Considerations correctly note, TURN with this
    extension is basically equivalent to TURN without it, with
    the exception that certain routing loop attacks inherent to
    TURN could be easier with this mechanism. My only significant
    concern that is not addressed in the document is how this
    mechanism relates to the routing loop attacks introduced by
    other forms of v4/v6 translation and tunneling, e.g., as
    discussed in this paper:

    <http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf>

    It's not immediately obvious to me that extending TURN in
    this way makes these (currently non-TURN-related) attacks
    viable, but I would encourage the authors to consider the
    issue and add some text to the document explaining how the
    attacks do or do not apply here.

And Simon had proposed:  don't do TURN-IPv6 with ISATAP/6to4/Teredo tunnels.

That Nakibly paper concentrates on three automatic tunnels:  ISATAP, 6to4,
and Teredo.

Cullen, your objection seems to be that a TURN-IPV6 client or TURN-IPV6
server cannot discern if it is using one of those tunnels.  The Nakibly
paper summarizes unique aspects of those automatic tunnels, ISATAP:
0200:5EFE or 0000:5EFE in bits 64-96; 6to4: 2002::/16; Teredo: 2001::/32.  A
TURN-IPV6 server can identify IPv6 addresses belonging to those automatic
tunnels, and refuse to service those requests.  Specifically, the TURN-IPv6
server can return an error message when attempts are made to use those
addresses from TURN clients or as TURN peers.  A client could also do those
same checks.

Of course static tunnels and 6rd tunnels cannot be pattern-matched like the
automatic tunnels, above (ISATAP, 6to4, Teredo).  However, I don't know if
the attacks described in the Nakibly paper are also possible with static
tunnels or with 6rd.  Richard, can static tunnels or 6rd could be used to
launch Nakibly-like attacks, too?

-d

> Sure - makes sense why Google does not want to point DNS at things
> where the v6 connectivity is dependent on something as ephemeral as one
> of these tunnels but deployment of v6 over various tunnels seems fairly
> likely to continue for a long time. Perhaps not for servers that have
> to be reachable after a AAAA query but certainly for end hosts
> situations.
> 
> >
> Not really disagreeing with you but it will happen -  the experience
> with VoIP over VPN and other relays is certainly that relays are not
> good but VoIP does often work fine when it has to go through multiple
> relays. Clearly choosing a v4 address is often going to work better
> than choosing a v6 address in some of these situations but ICE can help
> figure out which is best.
> 
> >
> >>
> >>
> >> Cullen Jennings

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 20 Jul 2010 15:34:36 -0700

Related, see Brian Carpenter's review of draft-nakibly-v6ops-tunnel-loops-02
at
http://www.ietf.org/mail-archive/web/v6ops/current/msg04828.html

http://tools.ietf.org/html/draft-nakibly-v6ops-tunnel-loops-02#section-3.1
proposes that the routers doing the automatic tunneling (ISATAP, 6to4,
Teredo, and 6rd) perform validation of the addresses used.

I expect this would resolve the problem.  Richard Barnes:  thoughts?

-d

> From: Dan Wing [mailto:[email-masked]]
> Sent: Tuesday, July 20, 2010 3:16 PM
> To: 'Cullen Jennings'
> Cc: 'David Harrington'; 'Gonzalo Camarillo'; [email-masked]';
> [email-masked]'
> Subject: RE: [BEHAVE] I-D Action:draft-ietf-behave-turn-ipv6-11.txt
> 
> > > is why it is running Teredo or running 6to4) and has an IPv6
> address
> > (by
> > > limited by its NAT (due to the NAT's filtering or mapping
> behavior);
> > there
> The SECDIR review at http://www.ietf.org/mail-
> archive/web/secdir/current/msg01581.html said:
> 
> That Nakibly paper concentrates on three automatic tunnels:  ISATAP,
> 6to4, and Teredo.
> 
> 0200:5EFE or 0000:5EFE in bits 64-96; 6to4: 2002::/16; Teredo:
> 2001::/32.  A TURN-IPV6 server can identify IPv6 addresses belonging to
> those automatic tunnels, and refuse to service those requests.
> Specifically, the TURN-IPv6 server can return an error message when
> attempts are made to use those addresses from TURN clients or as TURN
> peers.  A client could also do those same checks.
> 
> Of course static tunnels and 6rd tunnels cannot be pattern-matched like
> the automatic tunnels, above (ISATAP, 6to4, Teredo).  However, I don't
> know if the attacks described in the Nakibly paper are also possible
> with static tunnels or with 6rd.  Richard, can static tunnels or 6rd
> could be used to launch Nakibly-like attacks, too?
> 
> -d
> 
> > > Regarding v6ops: I realize draft-vandevelde-v6ops-harmful-tunnels
> is
> > not a

---

From: Simon Perreault <[email-masked]>
Date: Wed, 21 Jul 2010 08:20:45 -0400

> And Simon had proposed:  don't do TURN-IPv6 with ISATAP/6to4/Teredo tunnels.

Small clarification: it was Richard's proposal and is implemented on the
server side based on the client's source address. From the current text:

   The attack is mitigated as follows.  It is RECOMMENDED that TURN
   relays not accept allocation or channel binding requests from
   addresses known to be tunneled, and that they not forward data to
   such addresses.  In particular, a TURN relay MUST NOT accept Teredo
   or 6to4 addresses in these requests.

> A client could also do those same checks.

Wouldn't it be better to let the server do them earlier, when it
receives data from a Teredo/6to4/ISATAP peer? So filters would be
applied to both client source address and peer source address. Neither
could be using Teredo/6to4/ISATAP.

> automatic tunnels, above (ISATAP, 6to4, Teredo).

And TSP. And the hundreds of non-IETF tunnelling protocols that are out
there.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 21 Jul 2010 09:04:55 -0700

> From: Richard L. Barnes [mailto:[email-masked]]
> Sent: Wednesday, July 21, 2010 6:23 AM
> To: Dan Wing
> Cc: 'Cullen Jennings'; 'David Harrington'; 'Gonzalo Camarillo';
> [email-masked]
> Yes, I think validating the addresses would do the trick.  (I think my
> earlier suggestion, that relay routers not accept bindings to/from
> tunnel addresses, is equivalent?) 

A TURN server could identify ISATAP, 6to4, and Teredo addresses, as they
have unique bits.  But a TURN server can't identify a 6rd address (there 
aren't unique bits in its address).  The Nakibly PDF didn't mention 6rd
(it didn't exist when the PDF was written), but 
draft-nakibly-v6ops-tunnel-loops-02 does mention 6rd.

So, TURN is reliant on the tunnels protecting themselves from tunnel
attacks.

Are you suggesting that we have TURN also refuse those tunnel addresses 
that it can identify (ISATAP, 6to4, Teredo)?

-d

> The TURN document should explain
> what the validation entails, either directly or by reference.
> 
> --Richard
> 
> 
> 
> On Jul 20, 2010, at 6:34 PM, Dan Wing wrote:
> 
> >>>> their properties.  To be fair, Teredo and 6to4 are not cited as
> the
> >>> sole

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 21 Jul 2010 11:43:30 -0700

assuming this only happens is a problem for specific types of tunnels, then adding in simple advice on how and to detect and when to ignore would solve my "I don't know how to implement this" problem. 

Cullen Jennings

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 21 Jul 2010 09:22:32 -0400

Yes, I think validating the addresses would do the trick.  (I think my  
earlier suggestion, that relay routers not accept bindings to/from  
tunnel addresses, is equivalent?)  The TURN document should explain  
what the validation entails, either directly or by reference.

--Richard

---

From: Dave Thaler <[email-masked]>
Date: Wed, 21 Jul 2010 23:00:41 +0000

See my review of the same draft, attached.

-Dave

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dan Wing
> Sent: Tuesday, July 20, 2010 3:35 PM
> To: 'Cullen Jennings'
> Cc: [email-masked]; 'David Harrington'; 'Gonzalo Camarillo'; [email-masked]
> proposes that the routers doing the automatic tunneling (ISATAP, 6to4, Teredo,
> and 6rd) perform validation of the addresses used.
> 
> > > something like IPSEC and what an application running on that host
> > > can find out. The whole point from the OS point of view was for the
> > > application not to know or care how the v6 interface had shown up.
> > > We also have issues such as the when the tunnels is not terminated
> > > on
> > the
> > > - tunnels are hard to detect by design and there are lots of forms
> > > of them.
> >
> > Cullen, your objection seems to be that a TURN-IPV6 client or
> > TURN-IPV6 server cannot discern if it is using one of those tunnels.
> > The Nakibly paper summarizes unique aspects of those automatic tunnels,
> ISATAP:
> > 2001::/32.  A TURN-IPV6 server can identify IPv6 addresses belonging
> > to those automatic tunnels, and refuse to service those requests.
> > Of course static tunnels and 6rd tunnels cannot be pattern-matched
> > like the automatic tunnels, above (ISATAP, 6to4, Teredo).  However, I
> > don't know if the attacks described in the Nakibly paper are also
> > possible with static tunnels or with 6rd.  Richard, can static tunnels
> > or 6rd could be used to launch Nakibly-like attacks, too?
> >
> > -d
> >
> > > likely to continue for a long time. Perhaps not for servers that
> > > have to be reachable after a AAAA query but certainly for end hosts
> > > situations.
> > >
> > > >
> > > > And today's performance complaints about 6to4 and Teredo are
> > > > almost solely around TCP and using web sites, not
> > > interactive
> > > >
> > > good but VoIP does often work fine when it has to go through
> > > multiple relays. Clearly choosing a v4 address is often going to
> > > work better than choosing a v6 address in some of these situations
> > > but ICE can
> > help

Subject: Review of draft-nakibly-v6ops-tunnel-loops-02
From: Dave Thaler <IMCEAEX-_O=MICROSOFT_OU=FIRST+20ADMINISTRATIVE+20GROUP_CN=RECIPIENTS_CN=[email-masked]>
To: IPv6 Operations <[email-masked]>
Date: Wed, 21 Jul 2010 22:11:52 +0000

Overall this draft is useful for new tunnel protocol designers.  However I
have a number of substantial comments on the actual text.

1) The title and abstract come across as saying things are broken. That is,
the word "vulnerabilities" (not "threats") appears in the abstract, and the
word "Proposed" appears in the title.  However, I find no evidence of this,
since it appears RFC 5214 (ISATAP) is fine, and the draft itself states the
problem doesn't occur if both routers are 6to4.  And it states it's only for
protocol 41 which takes out Teredo (which isn't mentioned as a result).
And that's the list of automatic tunnels that are widely deployed today.

As such, I think the audience is primarily authors of new protocols (like
6RD etc.) and "vulnerabilities" should be changed to "threats" and
"proposed" should be changed to "current" or something.   We don't
want people to incorrectly conclude from this draft that people shouldn't
use existing protocols that already mitigate these issues.  (And yes I
see evidence of that incorrect conclusion, e.g. people saying that TURN
should block 6to4 addresses, without understanding the problem).

Similarly in the introduction it says there's a "vulnerability in the design
of IPv6 automatic tunnels", which for the reasons in my first paragraph
above does not appear to be correct.

2) Several places in the doc, e.g. the second paragraph of section 2
incorrectly imply that a router has only one IPv4 address.  This is a
bad assumption given that it's a router.

3) The third paragraph of section 3 walks through an assumption
("We assume...") that a vulnerability exists.  However for the specific
protocols widely deployed such a vulnerability doesn't exist.  It
would be more honest to caveat it with "if the threat were left
unmitigated..."

4) Section 3.1 second paragraph proposes that you can detect an
ISATAP suffix.   Similar to how the 3rd bullet of the limitations mentions
with 6RD, there is no guarantee that detecting an ISATAP suffix can
be safely done since you can have false positives.   Hence this proposed
mitigation would cause black holes and hence falls into the category of
what I might call a Bad Idea.

Right now the draft leaves section 3.1 as a "proposed" mitigation with
limitations, and should instead lead the reader to conclude that this
mitigation is almost always a really bad idea.   It sort of does so now
but should really state this explicitly.

5) Section 3.2.1 assumes that RS's are indeed sent on a tunnel, which is
not a safe assumption.   Counter examples might be the use of
static configuration instead (which would render the proposed
mitigation harmful in that it creates black holes).   Furthermore,
some widely deployed implementations (like Windows) of 6to4
do not use RS/RA.  RS/RA isn't designed for use between routers,
and hence use between a 6to4 gateway and 6to4 relay is arguably
router-to-router.  And for the 6to4 gateway-in-a-host case,
RS/RA would be useful but not required to get the prefix since it's
well-known.

Because of the above reasons, section 3.2.1 is also what I might call
a Bad Idea.

6) Section 3.2.2 is fine.  It's saying you can use ACLs to mitigate the threat
operationally without any protocol changes.  However what's missing
from this document is the mitigation of putting a firewall around the
network area using the tunnel.  As has already been discussed earlier
on this list, but was never added to the draft (that I can find anyway),
is what is covered in RFC 5214 section 10:

   There is a possible spoofing attack in which spurious ip-protocol-41
   packets are injected into an ISATAP link from outside.  Since an
   ISATAP link spans an entire IPv4 site, restricting access to the link
   can be achieved by restricting access to the site; i.e., by having
   site border routers implement IPv4 ingress filtering and ip-
   protocol-41 filtering.

7) Section 3.2.3 should be Recommended, along with the firewalling
point above.   Those two are what I mean by "current" mitigations
in my point 1 at top.

8) On the question of "should this be combined with tunnel-security-concerns"
I think that would be a perfectly reasonable thing to do (if the WG agrees),
although if we do that I'd probably prefer to only take the things
that are "current" mitigations, and not in the Bad Idea category.

-Dave Thaler