[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-nakibly-v6ops-tunnel-loops review
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Gabi Nakibly
> Sent: Wednesday, July 21, 2010 8:38 AM
> To: Brian E Carpenter; Fred Baker
> Cc: IPv6 Operations
> Subject: Re: draft-nakibly-v6ops-tunnel-loops review
>
> Brian,
> Thanks for the thorough review. I agree that a summary of the pros and cons of
> the solutions is in order. Nonetheless, I believe that making a clear choice
> among the solutions may be hard to do since in different situations different
> solutions may preferable.
I believe the situation for ISATAP router can be handled
best by the Section 3.2.3 Neighbor Reachability Check. I
believe it should be the recommended solution for ISATAP,
and we should just come right out and say this.
Fred
fred.l.templin@boeing.com
> Gabi
>
>
>
> ----- Original Message ----
> > From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> > To: Fred Baker <fred@cisco.com>
> > Cc: IPv6 Operations <v6ops@ops.ietf.org>
> > Sent: Wed, July 21, 2010 5:57:48 AM
> > Subject: Re: draft-nakibly-v6ops-tunnel-loops review
> >
> > Fred,
> >
> > IMHO this is indeed sound work. As I said, even if it's to be informational,
> > I think there should be some sort of choice made among the solutions, or
> > at least a summary of the pros and cons. So I think we need progress on
> > that before a WGLC.
> >
> > Brian
> >
> > On 2010-07-21 03:05, Fred Baker wrote:
> > > Thanks much for the review. Looks like it at least needs an update before
> >being finalized.
> > >
> > > Question for you. Would you consider an updated version of the document ready
> >for WGLC, or do we need further discussion on it? Apart from the beauty of the
> >prose, are the notions proposed sound?
> > >
> > > On Jul 19, 2010, at 8:25 PM, Brian E Carpenter wrote:
> > >
> > >> On 2010-07-16 02:48, Fred Baker wrote:
> > >>> Could I interest you in doing a thorough review of
> >draft-nakibly-v6ops-tunnel-loops and commenting to v6ops?\
> > >> Summary
> > >> -------
> > >>
> > >> This draft proposes mitigation techniques for malicious loops formed
> > >> using a mixture of automatic IPv6-in-IPv4 tunnel mechanisms.
> > >>
> > >> The draft doesn't recommend a choice of technique. I think that for the
> > >> work to go forward, the WG would need to agree on a recommendation.
> > >> Otherwise, the world will shrug its shoulders.
> > >>
> > >> Details
> > >> -------
> > >>
> > >> Several IPv6 transition aids rely on automatic tunneling of IPv6 in
> > >> IPv4. If an attacker succeeds in making two such methods link up
> > >> with each other head-to-tail, a loop will form, and will consume all
> > >> available resources. With manually configured tunnels, such a loop
> > >> will be excluded by construction, but with automatic tunnels, an attacker
> > >> can (under certain conditions) create a packet that a tunnel egress
> > >> will feed back into regular IPv6 routing such that it ends up back
> > >> in the tunnel again, until its hop limit expires.
> > >>
> > >> Section 2 describes the attack scenario. I find the terminology
> > >> rather confusing:
> > >>
> > >> 1. For each tunnel, there is an object called "the tunnel router".
> > >> I assume this is supposed to be the encapsulating ingress router.
> > >> But it isn't stated clearly.
> > >>
> > >> 2. Tunnels have egress decapsulators. Their role is not described
> > >> very clearly, but is assumed to be understood.
> > >>
> > >> 3. There's a reference to destination hosts being "in" the tunnel.
> > >> ("The attack is ... initiated by sending an
> > >> IPv6 packet (packet 0 in Figure 1) destined to an end point in T2...")
> > >>
> > >> But hosts aren't in tunnels. They are outside the tunnel, beyond the
> > >> egress router. [OK, some hosts do their own decapsulation, but then one
> > >> can separate their decapsulator from their IPv6 stack, and anyway such
> > >> hosts are not routers and will not forward packets back into the network.]
> > >>
> > >> So does this mean "destined to a fictitious end point that appears
> > >> to be reached via T2"?
> > >>
> > >> There's a similar problem in the very first sentence of section 2:
> > >>
> > >> " In this section we shall denote an IPv6 address of a tunnel's node by
> > >> the prefix of the tunnel and the IPv4 address of the node, i.e.,
> > >> Addr(Prefix, IPv4). "
> > >>
> > >> Does that mean
> > >>
> > >> " In this section we shall denote an IPv6 address of a node reached via
> > >> a given tunnel by the prefix of the tunnel and the IPv4 address of the
> >node, i.e.,
> > >> Addr(Prefix, IPv4). " ?
> > >>
> > >> 4. The description in section 2 then states that a packet to IPv6 address
> > >> (Prf2, IP1) is encapsulated in tunnel T2 and delivered to router R1 as the
> > >> tunnel egress, but that R1 erroneously treats it as if it came from tunnel
> >T1.
> > >> It isn't made very clear that this happens *because* the whole of the IPv4
> > >> Internet acts as a shared link layer as far as these automatic tunneling
> > >> techniques are concerned. Therefore, R1 can only rely on the (dubious)
> > >> addresses in the packet headers to figure out what to do next, and what it
> > >> does is send the packet back to R2, because that's what the IPv6 prefix
> >tells
> > >> it to do.
> > >>
> > >> As far as I can see, the return packet from R1 to R2 could be sent by
> > >> native IPv6 if such connectivity exists, but is more likely to be sent
> > >> via tunnel T1, which is what R1 probably uses to provide global v6 access.
> > >> The draft should make this point clear, anyway.
> > >>
> > >> Section 3 of the draft describes three possible mitigation strategies.
> > >>
> > >> 1. Checking the embedded IPv4 addresses explicitly in the tunnel end
> points.
> > >> This is fairly straightforward and would fix the problem in most cases, but
> > >> creates some overhead. Configuration would be needed to deal with 6rd
> > >> and with RFC1918-based tunnels.
> > >>
> > >> 2. Checking that the end point exists, by various techniques. I am more
> > >> pessimistic about these options than the author seems to be.
> > >>
> > >> 3. Use different protocol numbers for different tunnel types. This would
> > >> be hard to deploy - in fact I think it's hopeless, since backwards
> > >> compatibility with proto 41 would have to be kept.
> > >>
> > >> By the way, is it sufficient if either R1 or R2 makes the checks?
> > >>
> > >> Brian Carpenter
> > >
> > > http://www.ipinc.net/IPv4.GIF
> > >
> > >
> >
> >
>
>
>
>