Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Thu, 9 Sep 2004 15:34:07 +0200

Hi,

> > Dear All,
> > 
> > An issue of general character has been brought up in 
> connection with the zero-conf work. 
> > The issue is the following:
> > 
> > MUST Ipv6-in-Ipv4 tunnel servers, as routers, support 
> NUD-like mechanisms that enables
> > them to send ICMP destination unreachable messages back to origin ?
> > 
> > The initial feedback received in this respect is that - 
> "yes, they MUST".
> > 
> > As some RFCs previously has been silent about this, e.g. 
> 6to4 - RFC 3056,
> > and the working group currently is standardising a 
> mechanism which also seems
> > to be silent about this (Teredo) I would very much like to 
> hear if the above is the
> > general sentiment of the work group.
> 
> What happens, afaik, is the following:
> Remote Box (A) = 2001:db8::1
> tunnelendpoint @ Tunnel Server (Ts) = 2001:db8:1000::1
> tunnelendpoint @ Tunnel Client (Tc) = 2001:db8:1000::1
> R? = Routers in between.
> 
> Thus schematically:
> A -> Ra -> Rb -> Rc -> Ts -(6in4/proto41 tunnel)-> Tc
> 
> The packet will arrive at Ts, which will stick it into a 6in4 
> packet and
> actually forward it to Tc.
> 
> Following situations could arise:
>  a) IPv4 path works and Tc accepts the packet
>     -> no problems
>  b) IPv4 path works, Tc doesn't accept packet
>     -> it should return with a proto-41 unreach icmp
>  c) IPv4 route is broken between Ts and Tc
>     -> it should return a unreach host
> 
> In case of b and c when Ts gets a icmp route/port/host 
> unreach they can
> send a IPv6 unreach route/host back to the Remote Box A.
> This is, what I noticed, is what the current Linux, KAME and XP
> implementations do.
> 

Thanks,

So what you're saying is that the Tunnel Server can rely on the information from
the IPv4 layer and thus does not need glue native IPv6 NUD-like mechanism 
on top of the IPv4 layer - ?

> > I should be stressed that adding this to the goals of the zero-conf
> > requirements document isn't believed to severely limit the solution
> > space - but it requires implementation of a mechanism which 
> is know to
> > scale very badly and which in addition is susceptible to the DoS
> > attack described in Section 4.3.2 of RFC 3756.
> 
> The point where this can be DoS'd is by sending the Tc IPv4 
> unreachables
> for the Tc. Thus if you know the endpoints you can simply send a few
> icmp's and if the Ts remembers the state, which it hopefully does not
> do, then you can effectively disable the tunnel.
> 
> The real way to fix this is doing egress/ingress filtering on IPv4...
> But many ISP's do not do any filtering at all, so tough luck.
> For that matter, the not so many IPv6 ISP's that are out there don't
> filter on IPv6 either, at least most of them, so most are 
> repeating the
> same problem again, but all has to do with the router not 
> being able to
> do filtering or something on linerate...
> 

Neither of these are real problems in the particular scenario of
zeroconf, due to its severe assumptions on IPv4 source filtering and 
source spoof preventions.

A different issue however is that the server may be swamped with ICMP proto-41
unreachable from IPv4 nodes in the case where the server is used to reflect packets into
the network.

Thanks, Karen

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 13 Sep 2004 09:13:57 +0200

Karen E. Nielsen wrote:
<SNIP>
> So what you're saying is that the Tunnel Server can rely on the
> information from the IPv4 layer and thus does not need glue
> native IPv6 NUD-like mechanism on top of the IPv4 layer - ?

Correct.

> source spoof preventions.

Which should indeed be there, but are not in most cases.
Then again, using spoofing to do DDoS's is not needed when the
kiddy people have 50k host big botnets at their disposal.

> A different issue however is that the server may be swamped with
> ICMP proto-41 unreachable from IPv4 nodes in the case where the
> server is used to reflect packets into the network.

I have seen quite a number of icmp unreachable's coming onto one
of the Tunnel Servers we have, when people turned off their proto-41
or when the route was unavailable etc. Fortunatly these are only
icmp's and thus doesn't cost most in terms of bandwidth etc.

One of the solutions is proto41-Heartbeat, let the client send a
heartbeat every now and then to the Tunnel Server, if it doesn't
do that just shutdown the tunnel.

Then again, I do not know of anyone having a Tunnel Server which has
more than 5000 tunnels connected to it. Maybe the Hexago people have
more experience in that direction of volume of users ?

Greets,
 Jeroen

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 13 Sep 2004 20:59:13 -0700

> Now a standard last hop IPv6 router on a lan monitors the reachability
of
> its lan hosts using NUD and notifies of black holes by sending IPv6
> destination unreachable
> back to origin. (Actually the ICMP is generated when a NUD cache times
out
> and address resolution cannot be performed anew, but in this context 
> that's a detail.)

I don't think that in this age of firewalls, any application should rely
on ICMP packets for detecting that a destination is not reachable. Most
firewalls are programmed to silently drop the traffic they don't like...

That being said, Teredo hosts and relays can in fact use the Teredo
bubble mechanism to verify that their peers are reachable.

-- Christian Huitema

---

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Tue, 14 Sep 2004 09:11:47 +0200

> 
> <SNIP>
> 
> > My new question is then  - is the proto-41 translation 
> scheme the general mech
> > adopted for (and accepted for) this purpose by the WG ?
> 
> You mean that errors in IPv4 space should be converted to 
> errors in IPv6
> space?
> 

I mean whether it is considered sufficient/good enough for
for Tunnel Server reachability detection to rely on 
translation of IPv4 ICMPs only.

BR, Karen

---

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Tue, 14 Sep 2004 09:23:04 +0200

Hi Christian,

> firewalls are programmed to silently drop the traffic they 

I don't disagree. The problem is with the alternative.

> bubble mechanism to verify that their peers are reachable.

Does this mean that Teredo Servers perform (or are meant to perform, i.e. SHOULD - ?)
some kind of RFC 2461 NUD-like reachability
mechanism using the bubble mechanism, when the reachability of end-host
are in question ?
- Or is it rather so that vendors if they like could implement this ?

BR, Karen

---

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Wed, 15 Sep 2004 14:34:14 +0200

Hi Brian,

Thanks a lot for your comments.

Left is how to get an answer to the general question, though.

A few comments below.

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, September 15, 2004 11:45 AM
> To: Karen E. Nielsen (AH/TED)
> Cc: 'Pekka Savola'; V6OPS WG; 'Radhakrishnan Suryanarayanan';
> [email-masked]; 'Jeroen Massar'
> Subject: Re: Unreachability detection at tunnels servers WAS: RE:
> Comments on zeroconf draft
> 
> 
> Karen,
> 
> Thanks for the clarification. One comment below..
> 
> Karen E. Nielsen (AH/TED) wrote:
> > Hi Brian,
> > 
> > I probably wasn't very clear because I wasn't thinking about
> > translation of ICMP proto-41 unreachable messages. Let me 
> try to clarify
> > my question.
> > 
> > A tunnel server, which IPv6-in-IPv4 encapsulates
> > packets to dual stack end-hosts, acts as a last hop IPv6 
> router at the
> > IPv6 level.
> > 
> > Examples of such a server is a Teredo server, and Isatap 
> server as well
> > as a 6to4 tunnel server (when the server-to-host 6to4 case 
> is supported)
> 
> And that is not described in RFC 3056, so isn't part of standardized
> 6to4. A 6to4 router, as described in RFC 3056, is like any other IPv6
> router as far as NUD and ICMPv6 is concerned - there is nothing
> special for the 6to4 decapsulator to do in this respect. The router
> function does what any router does.
> 

Agreed.

> A host which claims to support RFC 3056 really needs to behave like
> a 6to4 router. To be clear, it acts as its own last hop router.
> It's forwarding the decapsulated IPv6 packets to a local IPv6 stack.
> If that forwarding action fails it should generate an ICMPv6 
> unreachable
> response. (It's a very bizarre error condition though, and 
> probably can
> never happen in reality. Why would there be a 6to4 
> decapsulator operating,
> if there is no local IPv6 stack?)
> 
> A 6to4 encapsulator can only detect IPv4 unreachability, which in IPv6
> terms is a link failure and should obviously be handled like any other
> link failure.
> 

Well, an 6to4 encapsulator could perform NUD on the IPv6 level even on the
router-to-router links.

RFC 3056 even has a reference to RFC 2893 in this respect, only the reference,
in my mind, isn't clear (and furthermore it is quickly becoming deprecate).

But going into that discussion is of-topic and different from the issue
that I wanted to raise with this thread.

> 6to4 was designed to be orthogonal to everything else; generic tunnel
> servers are different and your questions below certainly 
> apply to them.
> 

Good.

Thanks,
Karen

>     Brian
> 
> > 
> > Now a standard last hop IPv6 router on a lan monitors the 
> reachability of its 
> > lan hosts using NUD and notifies of black holes by sending 
> IPv6 destination unreachable 
> > back to origin. (Actually the ICMP is generated when a NUD 
> cache times out and 
> > address resolution cannot be performed anew, but in this 
> context that's a detail.)
> > 
> > My question is:
> > 
> > What are the requirements on tunnel servers in this respect 
> - that is, is it required
> > that a tunnel server performs IPv6 reachability monitoring 
> comparatively to the above, 
> > meaning something which results in it being able to send 
> IPv6 ICMPs back to origin 
> > when a packet doesn't reach an end-host (at the IPv6 level) ??
> > 
> > Ultimatively that would mean that some IPv6 NUD like 
> mechanism would have to be glued
> > on top of the tunnelservice.
> > 
> > Given the answer from Jereon about translation of IPv4 ICMP 
> proto-41 - 
> > it could be that the answer to the question is - "NO that 
> is not required. It suffices
> > that the tunnel server aims to translate all proto-41 
> unreach IPv4 ICMP's into
> > IPv6 destination unreachables which are sent back to origin."
> > 
> > This also means that whether black holes are detected or 
> not, relies on the benevolence
> > of the end-hosts to generate proto-41 unreach ICMPs (and 
> large enough such messages, i.e. messages which includes 
> original Ipv6 header) and not on (stateful) mechanisms implemented
> > by the tunnel server.
> > 
> >>-----Original Message-----
> >>From: Brian E Carpenter [mailto:[email-masked]]
> >>Sent: Monday, September 13, 2004 2:41 PM
> >>To: Karen E. Nielsen (AH/TED)
> >>Cc: 'Pekka Savola'; V6OPS WG; 'Radhakrishnan Suryanarayanan';
> >>[email-masked]; 'Soininen Jonne (Nokia-NET/Helsinki)'
> >>Subject: Re: Unreachability detection at tunnels servers WAS: RE:
> >>Comments on zeroconf draft
> >>
> >>
> >>Karen E. Nielsen (AH/TED) wrote:
> >>
> >>>Dear All,
> >>>
> >>To be clear, are you asking about ICMPv4 or ICMPv6 responses?
> >>
> >>    Brian
> >>
> >>
> >>>I should be stressed that adding this to the goals of the 
> >>
> >>zero-conf requirements
> >>
> >>>document isn't believed to severely limit the solution 
> >>
> >>space - but it requires
> >>
> >>>implementation of a mechanism which is know to scale very badly and
> >>>which in addition is susceptible to the DoS attack 
> >>
> >>described in Section 4.3.2 of RFC 3756.
> >>
> >>>BR, Karen
> >>>
> >>>
> >>>
> >>>>On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote:
> >>>>
> >>>>
> >>>>>Normally last hops routers performs NUD so that they can 
> send ICMPs
> >>>>>back to origin to notify of black holes/unreachability.  
> Personally
> >>>>>I am not sure that this is a MUST requirement on the 
> >>
> >>Tunnel Servers.
> >>
> >>>>>I have actually thought that we could avoid this, 
> especially since
> >>>>>we have no explicit goals as to the nodes being registered as
> >>>>>reachable in the DNS using the Ipv6 address - wherefore we 
> >>
> >>are first
> >>
> >>>>>and foremost looking to support the situation where 
> >>
> >>communication is
> >>
> >>>>>initiated by the tunnel clients and not from the outside.
> >>>>
> >>>>This seems short-sighted to me, because the actual 
> >>
> >>*advantage* of IPv6
> >>
> >>>>is realized only when *incoming* connectivity is enabled 
> (if it was
> >>>>just about outbound connectivity, v4 would work as well). 
> >>>
> >>> If this
> >>>
> >>>
> >>>>would imply that the communication between two nodes 
> inside the 3GPP
> >>>>network or communication originating from IPv6 internet and 
> >>
> >>coming to
> >>
> >>>>a 3GPP node could just silently fail.. this would seem to be very 
> >>>>undesirable.
> >>>
> >>>
> >>>Note this is not about the connectivity silently failing, it
> >>>is about the node no longer being there/no longer being active. 
> >>>
> >>>But what you're saying is that the destination unreachable 
> >>
> >>ICMPs are a MUST
> >>
> >>>to support at a Ipv6-in-Ipv4 Tunnel Server ?
> >>>
> >>>- BTW, with the risk of bluring the difference in between
> >>>solution space and requirement space - I suppose this in 
> >>
> >>particular applies
> >>
> >>>to the v6ops accepted "tunnel server" mechanisms, 6to4 and 
> >>
> >>Teredo border routers ?
> >>
> >>>
> >>>>-- 
> >>>>Pekka Savola                 "You each name yourselves 
> king, yet the
> >>>>Netcore Oy                    kingdom bleeds."
> >>>>Systems. Networks. Security. -- George R.R. Martin: A 
> Clash of Kings
> >>>>
> >>>>
> >>>
> >>>
> > 
>

---

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Tue, 28 Sep 2004 10:44:57 +0200

Hi Pekka,

It seems that we are converging against a resolution, which is:

In the area of IPv6 black hole detection, tunnel servers may
not provide a service comparatively with the native IPv6 one.

Ideally, IPv6 transition/tunnelling mechanisms should provide black hole
detection mechanisms similar to original IPv6 NUD processes.

Whether such are provided, however, will for the individual
transition mechanism be a tradeoff weighting the implementation aspects and
the anticipated deployment environment aspects against the added value of such IPv6 NUD like
processes.

(-??)

I can live with that.

BR, Karen

> From: Pekka Savola [mailto:[email-masked]]
> Sent: Monday, September 27, 2004 11:27 AM
> Cc: V6OPS WG; 'Radhakrishnan Suryanarayanan'; [email-masked];
> 'Soininen Jonne (Nokia-NET/Helsinki)'
> Subject: RE: Unreachability detection at tunnels servers WAS: RE:
> I've tried to figure out how to close this thread but I haven't had 
> much success yet.. :/
> 
> On Wed, 22 Sep 2004, Karen E. Nielsen (AH/TED) wrote:
> > > As for my personal take -- hopefully I've understood the 
> arguments 
> > > properly..
> > > 
> > > If you receive IPv4 ICMP error messages relating to an 
> IPv6-in-IPv4
> > > tunnel, one should probably do something if it's possible, because
> > > that will be an indication that IPv6 link layer has 
> failed (and that
> > > particular error can be propagated the same way as any 
> other IPv6 link
> > > failure, or by direct ICMP message conversion).
> > > 
> > > What and whether the implementations must treat IPv4 ICMP error 
> > > messages somehow depends on the mechanism in question.  
> > > draft-ietf-v6ops-mech-v2-06.txt does not mandate it for static MTU
> > > discovery, but it's obviously required for dynamic MTU 
> discovery.  
> > > 6to4 spec (section 7) doesn't require it either, but 
> seems to imply 
> > > that it can be done.
> > > 
> > > So, as to the issue whether tunnel servers need to be able to send
> > > back ICMPv6 error messages if the implementation thinks 
> that the link
> > > has failed, I'd say "yes, it probably should" because 
> shouldn't all
> > > IPv6 nodes be supposed to be able to do something like that. The
> > > issue then is what constitutes good indication for "link 
> failure"  
> > > (e.g., in this case, IPv4 tunneling failing).  Specifying 
> what that
> > > must or should include is probably mechanism-dependent.
> > 
> > 
> > The tunnel servers are in many respects replacing IPv6 
> access routers, 
> > for which we have explicit requirements in this respect, i.e.,
> >  SHOULD perform IPv6 NUD. 
> > 
> > If I understand you correctly you seem to be saying that not only
> > is it up for the individual tunnel mechanism to decide how 
> to perform
> > determination of link-failure (with that, I agree completely) 
> 
> Yes.
> 
> > - but also (?) that it is up to the individual mechanism to 
> determine
> > what constitutes indication of link failure, and thus consequently,
> > which kind of link failures that it will seek to monitor 
> and report - !!
> 
> Yes, this is what I meant.
> 
> This stems from the practical point of view that it's a bit difficult 
> for us (well, we could create a draft or RFC) to create a "policy" on 
> that, to be followed by transition mechanisms to come.  The typical, 
> pragmatic approach is to look each proposition and try to figure out 
> whether it is justified or not.
> 
> > I may not disagree with the latter, but if this is the route that we
> > want to take, I would like it us to do it with our "eyes wide open"
> > so to speak - saying clearly that in the areas of IPv6 black hole
> > detection, tunnel servers may not provide a service comparatively
> > with the native IPv6 one.
> 
> Black hole detection is indeed a problem, but luckily enough, the
> problem is already commonplace, both in v4 (e.g., firewalling without
> ICMP transmissions on rejects) and (to a degree) in v6.  Therefore, if
> you want to build a very robust application, you'll have to deal with
> black holes in any case.  However, the vast majority of apps won't
> consider this a sufficiently wide problem.
> 
> That being said, I think it would be very useful to try to keep the
> original NUD & ICMP characteristics of IPv6 in the tunneling
> mechanisms that are specified, if not for other reason than providing
> a good and quick indication of network blockage to the apps.  But that
> seems to be a tradeoff which needs to be weighted per transition
> mechanism.  I'd certainly like to default to specifying similar NUD
> processes, unless otherwise justified, though.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>