Subject: Re: [BEHAVE] Comments on draft-denis-icmpv6-generation-for-teredo-00

From: Gurpreet Virdi <[email-masked]>
Date: Thu, 17 Sep 2009 20:25:06 +0000

Hi Teemu,

I am part of the Teredo team at Microsoft and I had some comments about #1, #2, #3 and #4 points you mention below. Here are my comments:

#1: The draft now says "Furthermore, the IPv6 firewall might not be on the return data path in which case generated ICMPv6 Echo Replies might break Teredo host-based relay feature.". This might seem a little confusing. See in both the host-based relay features and non-host-based relay feature....the firewall might be on the return data path. The difference is that in the host-based relay feature, the ICMPV6 Echo Reply packet hits the relay *before* hitting the IPV6 firewall (the host itself is the relay!!!). And in the non host-based relay feature, the ICMPV6 Echo Reply packet will hit the relay after hitting this IPV6 firewall. Hence, the host-based relay feature will not work with this draft.

#2: Currently Teredo relay discovery only succeeds when the following conditions are met
A) if the firewall on the peer machine exempts ICMPV6 Echo Request and
B) if the IPV6 address is a valid IPV6 address belonging to a peer machine that is up & running.

Now A is not common by default. In windows teredo clients, the time this is most common is when the peer is a host-based relay and I will not talk about it in detail, because you have already mentioned it in the draft as being one of the cases where the IPV6 firewall will not reply to pings.

Now B, requires that the attacker to guess your 128 bit IPV6 address correctly.

But with this draft, Teredo relay discovery will now succeed even if the above 2 conditions i.e. A & B are not met. So potentially an attacker could go around sending pings to all sorts of address ranges and ping replies from the IPV6 firewall in front of these machines will help in discovering Teredo relays around the world. 

This can certainly be mitigated by taking measures like: the firewall should only respond to ping requests that are destined to actual *active* IPV6 addresses behind the firewall.

#3: A windows teredo client will today re-do teredo relay discovery every 15 seconds (3 retransmissions) for a non-TCP connection and for a TCP connection it will redo relay discovery (upto 3 retransmissions) when TCP fails to confirms path reach-ability. If all 3 retransmissions don't end up getting a ping reply, the connection could potentially break. Hence, we have to be very careful when rate limiting. A way to approach this problem could be that instead of rate limiting, if the traffic increases too much, packets should be forwarded to the end host and let the end host take care of it.

#4: Perhaps we need to collect data on key applications that rely on ping replies while choosing a destination address. The false positive can absolutely have an adverse effect for example: take a TCP connection which will start on the Teredo address and then fail after x seconds only after which the next address in the list *might* be tried. X seconds might be too long in terms of latency.

Thanks
Gurpreet
 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 16, 2009 7:53 AM
> To: Dave Thaler
> Cc: [email-masked]
> Subject: RE: Comments on draft-denis-icmpv6-generation-for-teredo-00
> 
> Hi Dave, behave,
> 
> We've updated this draft based on received feedback:
> http://www.ietf.org/id/draft-denis-icmpv6-generation-for-teredo-01.txt
> 
> 1) We tried to tackle this by adding more text clarifying reply
> generation MUST only be done if middlebox is certainly on the return
> path and also clarification that host-specific relay function could
> otherwise break.
> 
> 2) We'd like more clarification on this: how discovery is made easier
> when compared to attacker just sending ICMPv6 Echo Requests to various
> IPv6 peers out there?
> 
> 3) Yes, but blindly responding might make middlebox act as reflector on
> some attacks - i.e. there should be some sanity in ICMPv6 echo reply
> generation. Then again, this is about the same for any host/server and
> from that point of view useless to have in this document? Therefore we
> are consider dropping that piece of text out.
> 
> 4) Right, but which one is worse: false negative or false positive
> reply of peer's liveness? The ICMPv6 anyway only tells the peer's lower
> layers are alive, but nothing about application layer stuff.
> 
> We also added some text on CGA.
> 
> Best regards,
> 
> 	Teemu
> 
> >-----Original Message-----
> >From: ext Dave Thaler [mailto:[email-masked]]
> >Sent: 23 July, 2009 03:36
> >To: Denis-Courmont Remi (Nokia-D/Helsinki)
> >Cc: Savolainen Teemu (Nokia-D-MSW/Tampere); Behave WG
> >Subject: RE: Comments on draft-denis-icmpv6-generation-for-teredo-00
> >
> >I forwarded the doc to our Teredo implementers and have some
> >additional feedback from them to pass along.
> >
> >1) The option for "Forced ICMPv6 Echo Reply generation for clients"
> >mentioned in 2.1 is especially problematic in that it breaks
> >the concept of a host-specific relay (a dual-stack host that
> >is acting as a relay for itself).
> >
> >2) A security consideration is that this draft makes discovery
> >of Teredo relays much easier for an attacker, when then makes
> >it easier to mount attacks against them.
> >
> >3) Section 5 talks about rate limiting.  If you rate limit,
> >then you limit the usefulness because communication won't be
> >established.
> >
> >4) There are applications that consider ping replies as an
> >indicator of liveness (e.g., when picking which IP address to
> >use among a set, or whatever else).  Spoofing echo responses
> >will cause such apps to have expected behavior.
> >
> >
> >> -----Original Message-----
> >> From: Rémi Denis-Courmont [mailto:[email-masked]]
> >> Sent: Wednesday, July 22, 2009 12:30 AM
> >> To: Dave Thaler
> >> Cc: Savolainen Teemu (Nokia-D-MSW/Tampere); Behave WG
> >> Subject: Re: Comments on draft-denis-icmpv6-generation-for-teredo-00
> >>
> >> On Tuesday 21 July 2009 22:22:02 ext Dave Thaler wrote:
> >> > Section 2.2 talks about translators sending (spoofed) echo replies
> >> > by default. However, if the translator is not guaranteed to be on
> >> > the
> >> reverse
> >> > path, e.g. in the case of multiple stateless translators, this is
> >> > dangerous. At minimum, the SHALL's need to be constrained to cases
> >> where
> >> > the translator is guaranteed to be on the reverse path.
> >>
> >> I don't disagree that a clarification would be good.
> >>
> >> However, I think it depends on how "a" translator is
> >defined. I think
> >> we can all agree that there has to be translation in both
> >paths. Then
> >> it depends whether one thinks of the translator as an abstract whole
> >> system or as a physical box between wires.
> >>
> >> Indeed, if the inbound and outbound boxes are distinct, stateless,
> >> unable to communicate with one another *and* topologically separate,
> >> there is a problem.
> >>
> >> > Section 2.3 states that firewalls SHOULD send (spoofed)
> >echo replies
> >> > to Teredo addresses.  This is again too strong.  If the firewall
> >> > would block incoming unsolicited packets from Teredo clients, then
> >> > it shouldn't send echo replies.  At minimum, the SHOULD
> >needs to be
> >> > constrained to a case where it would actually allow
> >packets through
> >> > from that address.
> >>
> >> Right.
> >>
> >> --
> >> Rémi Denis-Courmont
> >> Nokia Devices R&D, Maemo Software, Helsinki
> >>
> >
> >
>

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 21 Sep 2009 14:23:11 +0300

On Thursday 17 September 2009 23:25:06 ext Gurpreet Virdi wrote:
> Hi Teemu,
>
> I am part of the Teredo team at Microsoft and I had some comments about #1,
> #2, #3 and #4 points you mention below. Here are my comments:
>
> #1: The draft now says "Furthermore, the IPv6 firewall might not be on the
> return data path in which case generated ICMPv6 Echo Replies might break
> Teredo host-based relay feature.". This might seem a little confusing. See
> in both the host-based relay features and non-host-based relay
> feature....the firewall might be on the return data path. The difference is
> that in the host-based relay feature, the ICMPV6 Echo Reply packet hits the
> relay *before* hitting the IPV6 firewall (the host itself is the relay!!!).
> And in the non host-based relay feature, the ICMPV6 Echo Reply packet will
> hit the relay after hitting this IPV6 firewall. Hence, the host-based relay
> feature will not work with this draft.

It does not *break* the host-based relay feature. A host-based relay behind an 
ICMPv6-filtering network infrastructure is broken to start with. Or then I 
missed something...

Adding ICMPv6 generation into the picture does not fix the problem, but it 
does not make it much worse either. On top of that, running a host-based 
relays would most probably break the firewall policy (as tunneled would not be 
"seen" by the firewalls).

> #2: Currently Teredo relay discovery only succeeds when the following
> conditions are met A) if the firewall on the peer machine exempts ICMPV6
> Echo Request and B) if the IPV6 address is a valid IPV6 address belonging
> to a peer machine that is up & running.
>
> Now A is not common by default. In windows teredo clients, the time this is
> most common is when the peer is a host-based relay and I will not talk
> about it in detail, because you have already mentioned it in the draft as
> being one of the cases where the IPV6 firewall will not reply to pings.
>
> But with this draft, Teredo relay discovery will now succeed even if the
> above 2 conditions i.e. A & B are not met. So potentially an attacker could
> go around sending pings to all sorts of address ranges and ping replies
> from the IPV6 firewall in front of these machines will help in discovering
> Teredo relays around the world.

Yes, this is a security consideration. But is it a problem? if you don't want 
your relay to be discovered, you should simply *not* filter inbound ICMPv6. If 
you do inbound ICMPv6, then your Teredo relay is totally useless anyway.

This is just the same issue as #1 really: why would one run a Teredo relay if 
one implements a firewall filtering policy that is fundamentally incompatible 
with Teredo?

> This can certainly be mitigated by taking measures like: the firewall
> should only respond to ping requests that are destined to actual *active*
> IPV6 addresses behind the firewall.

Exactly, but this is hardly realistic implementation-wise.

---

From: <[email-masked]>
Date: Mon, 21 Sep 2009 15:25:38 +0200

Hi,

Thank you for your replies.

Rémi responded to 1 and 2, so here's for 3 and 4: 

>#3: A windows teredo client will today re-do teredo relay 
>discovery every 15 seconds (3 retransmissions) for a non-TCP 
>connection and for a TCP connection it will redo relay 
>discovery (upto 3 retransmissions) when TCP fails to confirms 
>path reach-ability. If all 3 retransmissions don't end up 
>getting a ping reply, the connection could potentially break. 
>Hence, we have to be very careful when rate limiting. A way to 
>approach this problem could be that instead of rate limiting, 
>if the traffic increases too much, packets should be forwarded 
>to the end host and let the end host take care of it.

Well, I'm not sure forwarding is solution (esp. in protocol translator scenario), but smart rate limiting would be. I.e. allow certain number of replies for unique destination (say few every 15 secs matching "legal" Teredo behaviour), but not humongous volumes (that resemble unreasonably strange behaviour for Teredo). We can improve text on this issue.

>#4: Perhaps we need to collect data on key applications that 
>rely on ping replies while choosing a destination address. The 
>false positive can absolutely have an adverse effect for 
>example: take a TCP connection which will start on the Teredo 
>address and then fail after x seconds only after which the 
>next address in the list *might* be tried. X seconds might be 
>too long in terms of latency.

Isn't it somewhat dangerous to trust on ping on address selection (due reliability and possible filtering issues)? Doesn't address selection usually work based on algorithms/preferences and on parallel transport layer connectivity tests? And doesn't all(?) address selection solutions leave Teredo pretty much as last resort connectivity approach "after all other things have failed", and thus there are not many places where to fallback if also Teredo connectivity fails (save IP over HTTP)? I.e. the false positive could prolong ultimate connection setup failure a bit, but false negative would make connection setup fail unnecessarily?

Furthermore, if an application has strict latency requirements, isn't it waste of time to first spend one RTT on ping test, the time app could've used for app/transport layer signaling? 

Best regards,

	Teemu

---

From: Gurpreet Virdi <[email-masked]>
Date: Mon, 21 Sep 2009 17:01:42 +0000

#1: If we are guranteed that the network infrastructure is dropping ICMPV6 Echo Requests, then I agree to you. But if we are not, I would rather argue that the proposal in this draft could end up breaking teredo relay functionaility. Here is why. With the proposal in the draft, teredo relay functionaility ends up depending on relays hosted out in the wild instead of host-based relay (windows clients by default are host-based relays). Is it guranteed that there will be a teredo relay hosted in the wild that will end up getting hit for this host machine? If yes, then once again i think that this draft is good to go. But if not, we could end up breaking a connection that could have potentially succeeded with host specific relay (rather than relying on a relay hosted in the wild which doesn't quite exist).

#2: I agree to you in that indeed a teredo relay should take care of this. All I was pointing out was that in terms of talking about backward *compatibility* or rather supporting backward behaviour..this draft might have made it worse for existing Teredo relays deployed in the world. 

Thanks
Gurpreet

 ________________________________________
From: Rémi Denis-Courmont [[email-masked]]
Sent: Monday, September 21, 2009 4:23 AM
To: [email-masked]
Cc: Gurpreet Virdi; Savolainen Teemu (Nokia-D-MSW/Tampere); Ali Turkoglu; Dave Thaler
Subject: Re: [BEHAVE] Comments on draft-denis-icmpv6-generation-for-teredo-00

---

From: Gurpreet Virdi <[email-masked]>
Date: Mon, 21 Sep 2009 17:02:04 +0000

#3: Ok. Sounds good. I will look forward to the modified draft.

#4: Correct in the sense that apps should not use ping to detect reachability etc.. But the reality is that some apps do that and it wouldn't be good to break them. So my suggestion would be to do a survey on applications that use this kind of a ping model.

Thanks
Gurpreet
________________________________________
From: [email-masked] [[email-masked]]
Sent: Monday, September 21, 2009 6:25 AM
To: Gurpreet Virdi
Cc: Dave Thaler; Ali Turkoglu; [email-masked]
Subject: RE: Comments on draft-denis-icmpv6-generation-for-teredo-00

Hi,

Best regards,

        Teemu