Subject: Re: I-D ACTION:draft-ietf-v6ops-6to4-security-01.txt

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 1 Mar 2004 11:15:02 +0100

On 10-feb-04, at 22:06, [email-masked] wrote:

> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security 
> -01.txt

Comments:

   "The 6to4 specification outlined quite a few security considerations,
    but it has been shown that in practice some of them have been
    difficult to get implemented due to their abstract nature."

How do you implement a consideration? And what exactly are you  
referring to? This is from RFC 3056:

   "In any case, any 6to4 traffic whose source or destination address
    embeds a V4ADDR which is not in the format of a global unicast
    address MUST be silently discarded by both encapsulators and
    decapsulators.  Specifically, this means that IPv4 addresses defined
    in [RFC 1918], broadcast, subnet broadcast, multicast and loopback
    addresses are unacceptable."

I don't find this particularly abstract, and apparently implementers  
didn't have much trouble with it either, this is from FreeBSD:

# netstat -rnf inet6
Destination       Gateway              Flags     Netif Expire
default           2002:c058:6301::     UGSc      stf0
2002::/24         ::1                  UGRSc      lo0 =>
2002::/16         2002:dfe0:e1e2::1    Uc        stf0
2002:7f00::/24    ::1                  UGRSc      lo0
2002:dfe0:e1e2::1  link#7              UHL        lo0
2002:e000::/20    ::1                  UGRSc      lo0
2002:ff00::/24    ::1                  UGRSc      lo0

As you can see they filter 0.0.0.0/8, 127.0.0.0/8, 224.0.0.0/4 and  
255.0.0.0/8. (That last one is probably a bit excessive,  
255.255.255.255/32 should be enough.) Linux also filters RFC 1918,  
169.254.0.0/16 and 240.0.0.0/4:

# ip -6 route
::/96 via :: dev tun6to4 metric 256 mtu 1480 advmss 1420
unreachable ::/96 dev lo metric 1024 error -101 mtu 16436 advmss 16376
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -101 mtu 16436  
advmss 16376
unreachable 2002:a00::/24 dev lo metric 1024 error -101 mtu 16436  
advmss 16376
unreachable 2002:7f00::/24 dev lo metric 1024 error -101 mtu 16436  
advmss 16376
unreachable 2002:a9fe::/32 dev lo metric 1024 error -101 mtu 16436  
advmss 16376
unreachable 2002:ac10::/28 dev lo metric 1024 error -101 mtu 16436  
advmss 16376
unreachable 2002:c0a8::/32 dev lo metric 1024 error -101 mtu 16436  
advmss 16376
unreachable 2002:e000::/19 dev lo metric 1024 error -101 mtu 16436  
advmss 16376
2002::/16 dev tun6to4 proto kernel metric 256 mtu 1480 advmss 1420
unreachable 3ffe:ffff::/32 dev lo metric 1024 error -101 mtu 16436  
advmss 16376
default via ::192.88.99.1 dev tun6to4 metric 1024 mtu 1480 advmss 1420

(This doesn't show up in either the routing table or firewalling rules.  
Also note their take on the ::/96 address space.)

The draft talks about "6to4 routers" without specifying what those are.  
This confusing, as many systems that run 6to4 don't act as routers.

   "If the 6to4 router established a BGP session between all the possible
    6to4 relays,"

This is of course both insane scalability-wise and impossible in the  
presence of RFC 3068 relays as anycasting isn't compatible with the use  
of TCP.

   "o  Disallow traffic from 6to4 routers where the IPv4 tunnel source
       address does not match the 6to4 prefix."

Source or destination isn't specified. See discussion below.

   "The 6to4 router will also perform security checks on traffic that it
    will receive from other 6to4 relays, or 6to4 routers, or from within
    the 6to4 site.  These checks include:"

Is this the current situation? If so, where is it specified? If not, is  
this draft specifying that this must be done? There is no  
justification.

   "o  Disallow traffic transmission to other 6to4 domains through 6to4
       relay router or via some third party 6to4 router.

    o  Discard traffic received from other 6to4 domains via a 6to4 relay
       router."

I believe older versions of Linux did this as they were unable to  
properly tunnel to other 6to4 routers or hosts directly. If this isn't  
allowed, it should be spelled out very specifically.

   "o  Disallow traffic from 6to4 routers where the IPv4 tunnel source
       address does not match the 6to4 prefix."

Is it mandated that only the host holding the corresponding IPv4  
address may tunnel packets with 6to4 IPv6 addresses? It is conceivable  
that due to internal routing issues packets may flow over an  
alternative 6to4 router in sites that use more than one.

   "o  Disallow traffic where the destination IPv6 address is not a
       global address; in particular, e.g. link-local addresses, mapped
       addresses and such should not be used. Note, this check might be
       incorrect if 6to4 were to be used."

Huh??? This last sentence doesn't compute.

   "o  Discard traffic received from 6to4 routers with the destination as
       a 6to4 prefix."

Reuse your code.

   "This section describes attacks against 6to4 networks.  Attacks which
    legerate 6to4 networks"

"Legerate" isn't an English word. "Leverage", maybe?

   "It is possible to conduct a variety of attacks on the 6to4 nodes.
    These attacks are:

    1.  Attacks with Neighbor Discovery (ND) Messages"

Finally, but not before page 12, something that isn't blatantly  
obvious. However, there is no description of how such an attack would  
work and what bad stuff would be the result.

   "The attacker - a malicious IPv4 or IPv6 node - can send packets with
    spoofed source address to a 6to4 node to accomplish a DoS attack."

It isn't clearly specified what kind of DoS attack. What I get from the  
discussion below this is that third party hosts reachable over 6to4 can  
be used to hide the identity of the attacker, but the sentence above  
seems to indicate something very different.

"4.1.4 Local IPv4 Broadcast Attack"

This is covered in the original RFC and it's handled appropriately in  
at least the FreeBSD implementation. (I can tell you it works too - I  
accidentally messed up my subnet mask at some point so that my IP  
address was a broadcast address and 6to4 wouldn't work.) So why are we  
talking about this?

   "6to4 relays have only one significant security check they must
    perform for general safety: when decapsulating IPv4 packets, check
    that 2002:V4ADDR::/48 and V4ADDR match."

Are we talking about the source addresses here? I don't believe it is a  
requirement that packets arriving over 6to4 must have an IPv4 source  
address that matches the 6to4 source address. However, it may be  
reasonable to impose such a requirement, but in  that case it must be  
spelled out such that it's impossible to miss so that implementers and  
operators know it. But I think it's meaningless anyway as an attacker  
then simply spoofs both source addresses.

   "6to4 relay should not relay packets between 6to4 addresses."

Again, reuse your code. It's worse than useless to talk about the same  
thing twice in the same document. See above for my objections.

"4.2.1 Attacks with ND Messages

    These attacks are the same as employed against 6to4 routers as
    described in Section 4.1.1."

Then why talk about it again??? Note that this isn't just me being  
annoyed over wasting time reading the same thing: having the same thing  
in a specification more than once is also a great way to introduce  
errors in new versions of documents and in implementations (speaking  
from painful experience here).

As a more general note: the draft spends too much time discussing  
things that are "not really useful", taking away focus from stuff that  
we need to do something about.

It would probably be useful to separate three aspects of the problem,  
possibly to the degree of having separate documents:

- 6to4 end-user issues
- 6to4 relay operator issues
- implementation issues

    "1.  Usage of access lists in the relay to limit access."

Announcing reachability to 2002::/16 and 192.88.99.1 and then deploy  
filters is inappropriate, as it can lead to black holes if the routing  
information leaks beyond what the relay expects. Since whether this  
happens is beyond the direct control of the relay operator, this can  
easily happen. So either the relay should be prepared to handle  
unexpected traffic or it shouldn't announce those routes outside its  
AS.

Alternatively, we may want to rethink the prohibition on announcing  
more specifics for 2002::/16 as this is an effective way to limit  
access to a relay.

   "Such attacks can easily be thwarted by implementing protocol-41
    filtering in IPv4 nodes or sites that do not implement IPv6 over IPv4
    tunneling."

This is either useless or dangerous. Useless in the case of hosts,  
which already throw out packets for protocols they don't run, and  
dangerous in the case of sites, because it makes it impossible to do  
any kind of IPv6inIP tunneling, defeating the purpose of transition  
mechanisms.

"4.4 Summary of the Attacks"

Skipping this part, see notes on duplication of content.

Under "5.1 Encapsulating IPv6 into IPv4":

        "ipv4 address embedded in src_v6 MUST match src_v4"

Either there is no IPv4 header so the check is meaningless or one has  
just been added, so checking yourself is redundant.

Dropping packets with non-6to4 source addresses is unacceptable, as  
this creates black holes and isn't compatible with the practice of  
setting up a private relay to have better connectivity towards 6to4  
hosts.

"5.2 Decapsulating IPv4 into IPv6

    The checks described in this section are to be performed when
    decapsulating IPv4 into IPv6.  They will be performed in both the
    6to4 router and relay."

This isn't a good idea as regular 6to4 hosts and routers need to be  
more restrictive than relays. To be more specific: in the case of a  
6to4 host or router the destination IPv6 address must be a 6to4 address  
for which the corresponding IPv4 address is assigned to the host or  
router. Any other destination address, be it multicast, non-global  
scope, regular unicast space or any other 6to4 addresses, must be  
discarded.

(Also note that as with any other external facing interface, it is  
always prudent to filter out packets that come in with source addresses  
that are known to be internal.)

   "The disallowed addresses include those defined
    in [13], and others widely used and known not to be global."

I strongly object to the fact that all kinds of filtering is  
expected/mandated without justification. Filtering isn't free; it  
should only be done if there is a compelling benefit. For instance,  
while it is perfectly fine if operators choose to filter RFC 1918  
source addresses, it would be a mistake to mandate that implementations  
do this automatically as implementations must handle packets coming  
from non-existing sources anyway so the need to get rid of a known  
subsection of these is debatable, which means the user must be able to  
make the tradeoff.

"6.2 Anyone Pretending to Be a 6to4 Relay

    Even though this was already discussed in Section 4.1.2, it bears
    some additional elaboration as it was the only problem which cannot
    be even partially solved."

And then the draft goes on to try and solve it, the cure being worse  
than the disease as it breaks 6to4 as it exists today. Our efforts  
would be much better spent by moving people to native IPv6 or at least  
configured tunnels. Then most 6to4 issues go away.

   "o  Every dual-stack site (or even ISP) would be required to have
       their own 6to4 relay."

What about IPv6-only parts of the network?

---

From: Pekka Savola <[email-masked]>
Date: Mon, 1 Mar 2004 17:14:41 +0200 (EET)

Thanks for a lot of good comments.

I didn't know which of the comments were commentary in genreal, or 
where you were proposing a different text.  That is, it wasn't always 
clear what you were expecting the text to be.  But I'll try to address 
the issues the best way I can...

>     addresses are unacceptable."

And:

   By default, 6to4 traffic will be accepted and decapsulated from any
   source from which regular IPv4 traffic is accepted.  If this is for
   any reason felt to be a security risk (for example, if IPv6 spoofing
   is felt to be more likely than IPv4 spoofing), then additional source
   address based packet filtering could be applied.  A possible
   plausibility check is whether the encapsulating IPv4 address is
   consistent with the encapsulated 2002:: address.  If this check is
   applied, exceptions to it must be configured to admit traffic from
   relay routers (Section 5).  2002:: traffic must also be excepted from
   checks applied to prevent spoofing of "6 over 4" traffic [6OVER4].     

> didn't have much trouble with it either, this is from FreeBSD:
[..]

The reject routes that are automatically installed only handle 
*encapsulation*, not *decapsulation* (which is done in the stf 
pseudointerface on BSD).

The decapsulation part, is by far the most troublesome one.  In short, 
the reject route is only preventing your site from doing harm or 
misconfiguration, but does not protect you from misuse.

> This confusing, as many systems that run 6to4 don't act as routers.

RFC3056 specifies them, and it's a normative reference:

   6to4 router (or 6to4 border router):
         an IPv6 router supporting a 6to4 pseudo-interface.  It is
         normally the border router between an IPv6 site and a wide-area
         IPv4 network.

This also includes (with some wiggling) the "host" problem.  
Functionally, the description of '6to4 router' should be change "an 
IPv6 router" in above to "in IPv6 node".

> This is of course both insane scalability-wise 

Certainly, this has some serious issues -- but at least today, there 
are about 27 or so relays in the network -- not that high a number, 
really.  In the long run, this probably isn't a solution though.

> and impossible in the  

Nothing excludes such routers from having multiple addresses, and 
running the BGP sessions between those addresses.

> Source or destination isn't specified. See discussion below.

I don't see what's unclear here.  The source address is the IPv4
source where you receive the 6to4 encapsulated traffic?

> this draft specifying that this must be done? There is no  

Yes, this should be the current situation.  It's stated in the 
security considerations, and this is just continuation of the checks 
described there.

The whole reason for this document in the first place was to re-write 
the security considerations to be actually useful.  If 6to4 is 
revised, these are probably clarified a LOT.
 
> properly tunnel to other 6to4 routers or hosts directly. 

No, this has never been done on Linux.  I seem to recall this issue, 
but that it was caused by something else altogether.

> address may tunnel packets with 6to4 IPv6 addresses?

Yes.

 >It is conceivable  

Yep, it's conceivable. "Don't do that." 

> Huh??? This last sentence doesn't compute.

True.  Must be an editing glitch from the major overhaul.  Will 
remove.
 
>    "o  Discard traffic received from 6to4 routers with the destination as

Sorry, I didn't get your point?
 
> "Legerate" isn't an English word. "Leverage", maybe?

Yep.
 
> obvious.

The first pages are a better introduction to 6to4 that 6to4 spec is 
currently h

> However, there is no description of how such an attack would  

There's some 4.1.1, but the more elaborate version was removed AFAIR.  
Will add back.
 
> seems to indicate something very different.

Yep, the description of the attack should certainly be more 
descriptive.
 
> address was a broadcast address and 6to4 wouldn't work.) So why are we  

It's an important example of a check AFAIK only very few implement -- 
only, it isn't described clearly enough that it shouldn't exist if the 
current spec was followed :)

> Are we talking about the source addresses here? 

Yep.

> I don't believe it is a  
> address that matches the 6to4 source address.

Well, you could mince words over this but RFC 3056 sect 5.3 states 
along the lines of:

   ADDITIONAL DECAPSULATION RULE for 6to4 routers

        [MUST] apply any security checks (see Section 8);

where sect 8 meant to refer to security considerations, but the 
section itself is immensely vague what the actual required checks are.

As said, the current 6to4 spec from security POV is pretty .. bad 
quality.

> However, it may be  
> operators know it. 

If we revise 6to4 spec, that's certainly number 1 consideration.  But 
this doc is meant as a "security update" -- isn't it enough?

> But I think it's meaningless anyway as an attacker  

Sure, but that's a different threat.

> thing twice in the same document. See above for my objections.

This is grinding it in, slowly, by inches, so that everyone 
understands what this means.  It didn't seem to be clear from the 
first, so just saying it once would probably lead to misunderstandings 
and missing the point.
 
> Then why talk about it again??? 

This is just one sentence.  For completeness.

> Note that this isn't just me being  

I can certainly agree that duplication is problematic in many aspects, 
but here we aren't actually doing any duplication, just referring to 
the problem mentioned in the referred section.

Or maybe you were commenting on general, e.g., 4.2.2 vs 4.1.2 or the 
like.  The threats are indeed similar, but the prevuous input -- 
leading to restructuring the document -- was that the different cases 
should be separate.
 
> we need to do something about.

They are there for the completeness.
 
> - 6to4 relay operator issues

I think the last one is already explained in a bit of detail, but I
agre that the first two are not explicitly described as a "target
audience".  Attacks are separated between whether they are targeted at
6to4 or native v6 (or v4) networks.
 
> unexpected traffic or it shouldn't announce those routes outside its  

If you read the following header, it said:

   Attempts to use the relay's IPv4 address instead of 192.88.99.1 can
   be mitigated in the following ways:

Such access lists would just concern those that do not use 
192.88.99.1.

> more specifics for 2002::/16 as this is an effective way to limit  

Well, this has been pointed out in other contexts, before, but with 
little traction.  Folks didn't want the v6 routing table to include v4 
as well :-).  The policy is supposed to be ensured by limiting the 
visibility of the route using some other mechanisms. (e.g., not 
exporting it anywhere, or sending it with no-export).

> which already throw out packets for protocols they don't run, 

Well, it depends on whether you want to be seeing those packets in 
your logs or not (assuming that your zone-alarm or whatever barfs 
every time someone sends you bad packets).  They're thrown out, with 
or without "ICMP protocol unreachable" message back.

> and  

True, which is IMHO this is probably a bad tradeoff -- which should be 
made clearer.

> Skipping this part, see notes on duplication of content.

I guess one can't please everyone.  Better a slightly verbose, or 
terse to the point of being difficult to read if you are not a subject 
matter expert in the area.
 
> setting up a private relay to have better connectivity towards 6to4  

Good catch!  My co-author messed up that section by mistake :-).  The 
correct one is like:

    src and dst MUST pass ipv6-sanity checks, else drop
    if src=2002
        src MUST match src_v4
    elif dst=2002
        (accept)
    else
        drop
    fi
    accept

this works in the case you describe as well :-)

> scope, regular unicast space or any other 6to4 addresses, must be  

The point is that the implementation does not, generally, know whether 
it's a router or relay -- that's decided by the routing table.  
Routers could probably have additional checks, but those are probably 
outside of the scope of this document -- those are probably quite 
similar to what you will want to configure in any of your border 
routers.
 
> subsection of these is debatable, which means the user must be able to  

These are already specified by the 6to4 spec -- I don't see the reason 
for objection?
 
> than the disease as it breaks 6to4 as it exists today.

Yep, each proposal has its tradeoffs.  Can't be helped.

> Our efforts  

I certainly don't disagree with that, but some people are not 
complying. :-)

> What about IPv6-only parts of the network?

That's the "end-game" case.  Either there are (public) network relays,
or those can't talk (if 6to4 is even used anymore).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings