[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-v6ops-6to4-security-01.txt
On 10-feb-04, at 22:06, Internet-Drafts@ietf.org 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?