Subject: RE: (ngtrans) Re: RFC 3056

From: "Christian Huitema" <[email-masked]>
Date: Thu, 7 Feb 2002 07:55:35 -0800

Not to be pedantic, but the algorithm:

> > >     if dst=2002                        1) or 2)
> > >         dst MUST match dst_v4
> > >             if src=2002                1)
> > >                 src MUST match src_v4
> > >             fi
> > >     elif src=2002                      3)
> > >         src MUST match src_v4
> > >     else
> > >         drop
> > >     fi
> > >     accept

can be rewritten

if src=2002
	src MUST match src_v4
elif dst=2002
	dst MUST match dst_v4
else
	drop
fi

Which is very close to what I proposed:

if src=2002
	src MUST match src_v4
elif  dst=2002
	dst MUST match dst_v4
else
	take a hard look at the packet; probably drop; certainly don't
relay
fi

And not very far from what Brian proposed

if src=2002
	src MUST match src_v4
elif  dst=2002
	dst MUST match dst_v4
	paranoid nodes may do further checks
else
	take a hard look at the packet; probably drop
fi

One reason for "take a hard look" is configured tunnels. If you have
configured tunnels, they will arrive at the same interface as 6to4
(local IPv4 address, proto type 41). The configured tunnel is
essentially an entry in the routing tables, that says smtg like "the
next hop for 2001:XXXX://n = 2002:tunnel:xxxxx". One way to "take a hard
look" is thus to perform a reverse path check.

The "paranoid" check was detailed by Brian: paranoid routers would want
some assurance that the source IPv4 is actually an authorized relay
router. How exactly we would do that is interesting, but there are
potential solutions, e.g. certificates issued by some 6to4
Kapellmeister.

-- Christian Huitema

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Thursday, February 07, 2002 7:11 AM
> To: Erik Nordmark
> Cc: Brian E Carpenter; Christian Huitema; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: (ngtrans) Re: RFC 3056
> 
> On Tue, 5 Feb 2002, Erik Nordmark wrote:
> > > As my draft put it (decapsulation rules) [I added some explanation
> here]:
> > >
> > >     if dst=2002                        1) or 2)
> > >         dst MUST match dst_v4
> > >             if src=2002                1)
> > >                 src MUST match src_v4
> > >             fi
> > >     elif src=2002                      3)
> > >         src MUST match src_v4
> > >     else
> > >         drop
> > >     fi
> > >     accept
> >
> > I think it would be useful to take yours and Christian's proposed
rules
> > (which appear close to identical as far as I can tell) and look
> > at what threats the do not address i.e. to what extent it would
still
> > be easy to circumvent IPv4 ingress filtering with the rules in
place.
> 
> Compare the rules when the source is of 2002::/16.  There's a
difference:
> destination address consistancy is not checked in both.
> 
> To make comparison easier, Christian's rules:
> 
> > 1) If the IPv6 source address is in a 2002::/16 domain, the IPv4
source
> > address should be consistent with it.
> >
> > 2) If the IPv6 source address is not in a 2002::/16 domain, and if
the
> > destination address is in the 2002::/16 domain, then the IPv4
> > destination should be consistent with the IPv6 destination. The
source
> > IPv4 address should not really be checked.
> >
> > 3) If neither the IPv6 source address not the IPv6 destination
address
> > is in the 2002::/16 domain, then special rules apply -- the packets
> > should not be relayed, unless some form of ACL explicitly enables
this
> > combination of IPv4 and IPv6 source and destination addresses.
> 
> 
> --
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> 
> 
>

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Feb 2002 18:15:14 +0200 (EET)

On Thu, 7 Feb 2002, Christian Huitema wrote:
> 	src MUST match src_v4   a)
> 	dst MUST match dst_v4   b)
> 	drop                    c)

This is not equal to the above.

Consider a packet with src=2002, dst=2002.

These rules would only check source, not destination ("_else_ if..").  My 
rules further above would check both.

(I don't dispute extra checks -- there could be some, but I added the 
simplest possible set.)

> look" is thus to perform a reverse path check.

I'm not 100% sure what you mean with the latter part..

If configured tunnel is configured in point-to-point mode so that both 
remote and local IPv4 addresses and preferably IPv6 too, are given, the 
algorithm for separating proto 41 should make them apart from 6to4.

Autotunneling and/or "easy" configured tunnels via autotunnel+routing is 
another issue..

> potential solutions, e.g. certificates issued by some 6to4

Yes.