Subject: [BEHAVE] draft-denis-icmpv6-generation-for-teredo-00 (was I-D Action:draft-denis-icmpv6-generation-for-teredo-00.txt)

From: "Dan Wing" <[email-masked]>
Date: Mon, 29 Jun 2009 12:20:29 -0700

> We have submitted a new I-D that relates to the 
> ongoing protocol translator work.
>
> All comments are very welcome.

In the Introduction,

   ...
   However, two scenarios have been identified where this
   Teredo procedure might fail:

   1) When a NAT-PT [RFC2766] or NAT64 [I-D.bagnulo-behave-nat64]
   protocol translator is on the path: the translator translates an IPv6
   ICMPv6 Echo Request originating from Teredo client into an IPv4
   ICMPv4 Echo Request and forwards it toward the IPv4 peer.  However,
   in the IPv4 realm, ICMPv4 does not always work reliably.  If the IPv4
   peer does not reply with an ICMPv4 Echo Reply for any reason (for
   example, ICMPv4 Echo Replies are disabled or filtered by an IPv4
   firewall), the Teredo client will not get any ICMPv6 Echo Reply
   response packet back, and thus it will determine that the peer is
   unreachable.  That implies that transport sessions, which otherwise
   could have succeeded, will not even be initiated.  Effectively IPv4
   nodes behind protocol translators that do not successfully respond
   with ICMPv4 Echo Replies cannot be reachable by Teredo clients.

bagnulo-behave-nat64 applies to the "an IPv6 network to the IPv4 Internet"
scenario.  In that scenario, the host on the IPv6 network is IPv6-only, so it
would not be running Teredo.  I believe the first scenario in the introduction
(which I excerpted above) has an IPv4 host running Teredo, and the IPv4 host
is behind a translator?  If so, this would occur when the IPv4 host is running
Teredo and also in BEHAVE's scenario 2 (IPv6 Internet to an IPv4 network) or
BEHAVE's scenario 3 (An IPv4 network to IPv6 Internet) where or BEHAVE's
scenario 5 (An IPv6 network to an IPv4 network) or BEHAVE's scenario 6 (An
IPv4 network to an IPv6 network).

I realize that the working group has not discussed how 6to4, Teredo, or dual
stack hosts are supposed to work in conjuncation with translators.  Your draft
would be improved by more clearly describing the network topology for your
scenario 1 -- that is, describe if the host (running Teredo) is IPv4-only and
is running Teredo across a 6-to-4 translator -- if that is, in fact, the
scenario where the problem occurs.  If it is, I believe the problem would
occur with stateless 6/4 translation, as well.

Other questions:  

* the draft implies that IPv6 echo request/reply will work better than IPv4
echo request/reply.  Do we have operational experience that network
administrators will permit IPv6 echo request/reply in places where they are
blocked with IPv4?  For example, I am thinking of the relatively common belief
that your host should be "invisible" on the Internet and should not respond to
any unsolicited messages.  Many host-based firewalls are configured with
exactly that behavior so the host appears invisible.  To me, this says that
Teredo itself needs to be less reliant on such ICMP echo request/reply
messages.

* I am very uncomfortable with a middlebox spoofing an ICMP echo reply on
behalf of an end system.  The text in Section 2.1 only says the spoofing
should only be done for Teredo echo requests,

      If enabled, the middlebox shall always immediately
      generate an ICMPv6 Echo Reply when it detects an ICMPv6 Echo
      Request originated from a Teredo client. 

but I found no description of how a middlebox would know if an "ICMPv6 Echo
Request originated from a Teredo client".  RFC4380 doesn't require any sort of
fixed string in Teredo-originated ICMP echo requests.  So I guess the
middlebox would have to be configured to know which hosts are running Teredo,
somehow?

If there was a way for the echo request to request such middlebox spoofing,
this might meet with approval as it can be argued that the host knows what it
is asking for.  This would of course require updating Teredo clients.  

-d

---

From: <[email-masked]>
Date: Mon, 29 Jun 2009 23:08:03 +0200

Hi Dan,

Thank you for the feedback, comments inline:

	Teemu 

>-----Original Message-----
>From: ext Dan Wing [mailto:[email-masked]] 
>Sent: 29 June, 2009 22:20
>To: 'Behave WG'; Savolainen Teemu (Nokia-D-MSW/Tampere)
>Subject: draft-denis-icmpv6-generation-for-teredo-00 (was I-D 
>Action:draft-denis-icmpv6-generation-for-teredo-00.txt)
>
>   ...
>scenario.  In that scenario, the host on the IPv6 network is 
>IPv6-only, so it would not be running Teredo.  I believe the 
>first scenario in the introduction (which I excerpted above) 
>has an IPv4 host running Teredo, and the IPv4 host is behind a 
>translator?  If so, this would occur when the IPv4 host is 
>running Teredo and also in BEHAVE's scenario 2 (IPv6 Internet 
>to an IPv4 network) or BEHAVE's scenario 3 (An IPv4 network to 
>IPv6 Internet) where or BEHAVE's scenario 5 (An IPv6 network 
>to an IPv4 network) or BEHAVE's scenario 6 (An

The bagnulo-behave-nat64 mentions in 4.2. the case where NAT64 is in front of IPv4 servers to make them visible for the IPv6 internet (and they likely are visible for the IPv4 internet as well). However, the client connecting to those servers may use IPv4 or IPv6 depending on its address selection rules (/transition technology selection, which can be Teredo among others). E.g. client could be making a choice between using a private IPv4 address or a Teredo address. But if using Teredo address it may end up going through protocol traslator and thus may get into missing ICMPv6 echo reply trap.

In our scenario 1 the client host running Teredo has private, NATted, IPv4 address as well.

>I realize that the working group has not discussed how 6to4, 
>Teredo, or dual stack hosts are supposed to work in 
>conjuncation with translators.  Your draft would be improved 
>by more clearly describing the network topology for your 
>scenario 1 -- that is, describe if the host (running Teredo) 
>is IPv4-only and is running Teredo across a 6-to-4 translator 
>-- if that is, in fact, the scenario where the problem occurs. 
> If it is, I believe the problem would occur with stateless 
>6/4 translation, as well.

Yes it would occur with stateless translation as well. I'll look at clarifying the scenario, as it is as you wrote (due holidays I may not be able to accomplish that by -01 deadline). Well, the host has IPv4-only access network at hand, but the host itself is naturally dual-stack.

Of course the scenario 1 we describe is a corner-case of sorts, but level of that depends on where translators end-up being placed in real life and how common IPv6 usage over Teredo will be.

>Other questions:  
>
>* the draft implies that IPv6 echo request/reply will work 
>better than IPv4 echo request/reply.  Do we have operational 
>experience that network administrators will permit IPv6 echo 
>request/reply in places where they are blocked with IPv4?  For 
>example, I am thinking of the relatively common belief that 
>your host should be "invisible" on the Internet and should not 
>respond to any unsolicited messages.  Many host-based 
>firewalls are configured with exactly that behavior so the 
>host appears invisible.  To me, this says that Teredo itself 
>needs to be less reliant on such ICMP echo request/reply messages.

Unfortunately I don't have that information, but that is a good question. I need to study that further.

>* I am very uncomfortable with a middlebox spoofing an ICMP 
>echo reply on behalf of an end system.  

I am somewhat uncomfortable as well, but we did not figure any other way without changing Teredo client implementations. It would be nice, though, if the echo reply could be tagged with an "evil bit" - ideas are welcome how to do that backwards compatible way.

>The text in Section 
>2.1 only says the spoofing should only be done for Teredo echo 
>requests,
>
>but I found no description of how a middlebox would know if an 
>"ICMPv6 Echo Request originated from a Teredo client".  
>RFC4380 doesn't require any sort of fixed string in 
>Teredo-originated ICMP echo requests.  So I guess the 
>middlebox would have to be configured to know which hosts are 
>running Teredo, somehow?

By the well-known Teredo prefix of "2001:0000::/32":
--
   A middlebox can determine the ICMPv6 Echo Request is coming from a
   Teredo client from the packet's IPv6 source address prefix, 2001:
   0000::/32, as described in RFC4380 [RFC4380].
--

>If there was a way for the echo request to request such 
>middlebox spoofing, this might meet with approval as it can be 
>argued that the host knows what it is asking for.  This would 
>of course require updating Teredo clients.  

Going for Teredo client update path would surely open more options.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 29 Jun 2009 16:17:26 -0700

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, June 29, 2009 2:08 PM
> To: [email-masked]; [email-masked]
> Subject: RE: draft-denis-icmpv6-generation-for-teredo-00 (was 
> I-D Action:draft-denis-icmpv6-generation-for-teredo-00.txt)
> 
> Hi Dan,
> 
> The bagnulo-behave-nat64 mentions in 4.2. the case where 
> NAT64 is in front of IPv4 servers to make them visible for 
> the IPv6 internet (and they likely are visible for the IPv4 
> internet as well). However, the client connecting to those 
> servers may use IPv4 or IPv6 depending on its address 
> selection rules (/transition technology selection, which can 
> be Teredo among others). E.g. client could be making a choice 
> between using a private IPv4 address or a Teredo address. But 
> if using Teredo address it may end up going through protocol 
> traslator and thus may get into missing ICMPv6 echo reply trap.
>

Is this diagram accurate?

 +-----------+                       +--------------+  +---------+
 |IPv4 client+---<Internet>--(IPv6)--+6/4 translator+--+  IPv4   |
 |with Teredo|                       +--------------+  | server  |
 +-----------+                                         +---------+

So in this case the IPv4 client prefers Teredo over IPv4, does an 
AAAA query and gets an AAAA response, which is the 6/4 translator.

That 6/4 translator is part of the "same network" as the IPv4
server, that is, the 6/4 translator is under the same administrative
domain as the IPv4 server because the IPv4 server's AAAA record
points to the 6/4 translator's IPv6 address.

In this network topology, the IPv4 ICMP Echo Requests (or their
responses) would be dropped between the 6/4 translator and 
the IPv4 server, correct?  If so, this seems like an issue with
configuring the firewalls and ACLs between the 6/4 translator
and IPv4 server?

> Yes it would occur with stateless translation as well. I'll 
> look at clarifying the scenario, as it is as you wrote (due 
> holidays I may not be able to accomplish that by -01 
> deadline). Well, the host has IPv4-only access network at 
> hand, but the host itself is naturally dual-stack.

Ok.

> Of course the scenario 1 we describe is a corner-case of 
> sorts, but level of that depends on where translators end-up 
> being placed in real life and how common IPv6 usage over 
> Teredo will be.
> 
> >Other questions:  
> >
> Unfortunately I don't have that information, but that is a 
> good question. I need to study that further.

Ok.  I wasn't involved with Teredo.  Hopefully someone with
Teredo standardization or deployments can comment.

> I am somewhat uncomfortable as well, but we did not figure 
> any other way without changing Teredo client implementations. 
> It would be nice, though, if the echo reply could be tagged 
> with an "evil bit" - ideas are welcome how to do that 
> backwards compatible way.

If the 6/4 translator is in the same administrative domain as
the server it is spoofing, I am more comfortable with it 
spoofing traffic from the host it is serving.  But if it does
that, it would be better if it did some sort of liveliness
check with the server.

> By the well-known Teredo prefix of "2001:0000::/32":

Thanks.  I had missed that text in the document.

-d

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Tue, 30 Jun 2009 09:46:01 +0300

On Monday 29 June 2009 22:20:29 ext Dan Wing wrote:
> blocked with IPv4?  For example, I am thinking of the relatively common
> belief that your host should be "invisible" on the Internet and should not
> respond to any unsolicited messages.  Many host-based firewalls are
> configured with exactly that behavior so the host appears invisible.  To
> me, this says that Teredo itself needs to be less reliant on such ICMP echo
> request/reply messages.

Teredo requires ICMPv6 Echo to work. This is clearly stated in the 
specification, and I think it is consistent with the Host Requirements. If 
they are filtered, Teredo will consider that the other host is unreachable - 
regardless of the direction of the "flow".

How else can you do return routing anyway?

> Request originated from a Teredo client".  RFC4380 doesn't require any sort
> of fixed string in Teredo-originated ICMP echo requests.  So I guess the
> middlebox would have to be configured to know which hosts are running
> Teredo, somehow?

Teredo was statically assigned the 2001:0::/32 prefix, so this is a non-issue.

> this might meet with approval as it can be argued that the host knows what
> it is asking for.  This would of course require updating Teredo clients.

Lets ignore the deployment problems with updating Teredo clients. Still, what 
changes are you trying to propose to the protocol? If echo won't work, how 
else could Teredo clients learn routes, short of updating all IPv6 nodes?

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

---

From: Christian Huitema <[email-masked]>
Date: Tue, 30 Jun 2009 14:42:58 +0000

> else could Teredo clients learn routes, short of updating all IPv6

If echo does not work, Teredo clients will have to forego the return routing test. If they don't want to blindly trust the first packet coming from a native IPv6 hosts, they will have to rely on heuristics to filter out the obvious hacks, and on end-to-end security to reduce spoofing attacks to DOS attacks.

-- Christian Huitema