[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-v6ops-6to4-security-01.txt
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...
On Mon, 1 Mar 2004, Iljitsch van Beijnum 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:
The the text you quoted below, and then some more:
> "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."
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].
> 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
[..]
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.
> The draft talks about "6to4 routers" without specifying what those are.
> 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".
> "If the 6to4 router established a BGP session between all the possible
> 6to4 relays,"
>
> 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
> presence of RFC 3068 relays as anycasting isn't compatible with the use
> of TCP.
Nothing excludes such routers from having multiple addresses, and
running the BGP sessions between those addresses.
> "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.
I don't see what's unclear here. The source address is the IPv4
source where you receive the 6to4 encapsulated traffic?
> "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.
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.
> "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.
No, this has never been done on Linux. I seem to recall this issue,
but that it was caused by something else altogether.
> "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?
Yes.
>It is conceivable
> that due to internal routing issues packets may flow over an
> alternative 6to4 router in sites that use more than one.
Yep, it's conceivable. "Don't do that."
> "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.
True. Must be an editing glitch from the major overhaul. Will
remove.
> "o Discard traffic received from 6to4 routers with the destination as
> a 6to4 prefix."
>
> Reuse your code.
Sorry, I didn't get your point?
> "This section describes attacks against 6to4 networks. Attacks which
> legerate 6to4 networks"
>
> "Legerate" isn't an English word. "Leverage", maybe?
Yep.
> "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.
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
> work and what bad stuff would be the result.
There's some 4.1.1, but the more elaborate version was removed AFAIR.
Will add back.
> "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.
Yep, the description of the attack should certainly be more
descriptive.
> "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?
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 :)
> "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?
Yep.
> 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.
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
> 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.
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
> then simply spoofs both source addresses.
Sure, but that's a different threat.
> "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.
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.
> "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???
This is just one sentence. For completeness.
> 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).
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.
> 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.
They are there for the completeness.
> 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
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.
> "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.
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.
> 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.
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).
> "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,
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
> dangerous in the case of sites, because it makes it impossible to do
> any kind of IPv6inIP tunneling, defeating the purpose of transition
> mechanisms.
True, which is IMHO this is probably a bad tradeoff -- which should be
made clearer.
> "4.4 Summary of the Attacks"
>
> 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.
> 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.
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 :-)
> "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.
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.
> "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.
These are already specified by the 6to4 spec -- I don't see the reason
for objection?
> "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.
Yep, each proposal has its tradeoffs. Can't be helped.
> Our efforts
> would be much better spent by moving people to native IPv6 or at least
> configured tunnels. Then most 6to4 issues go away.
I certainly don't disagree with that, but some people are not
complying. :-)
> "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?
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