[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
mech-v2: rewritten security text
Hi,
I modified section 4 on spoofing threats a bit and rewrote Security
Considerations to expand on the problems a bit.
Objections or other suggestions?
======
4. Threat Related to Source Address Spoofing
The specification above contains rules that apply tunnel source
address verification in particular and ingress filtering
[RFC2827][BCP38UPD] in general to packets before they are
decapsulated. When IP-in-IP tunneling (independent of IP versions)
is used it is important that this can not be used to bypass any
ingress filtering in use for non-tunneled packets. Thus the rules in
this document are derived based on should ingress filtering be used
for IPv4 and IPv6, the use of tunneling should not provide an easy
way to circumvent the filtering.
In this case, without specific ingress filtering checks in the
decapsulator, it would be possible for an attacker to inject a packet
with:
- Outer IPv4 source: real IPv4 address of attacker
- Outer IPv4 destination: IPv4 address of decapsulator
- Inner IPv6 source: Alice which is either the decapsulator or a
node close to it.
- Inner IPv6 destination: Bob
Even if all IPv4 routers between the attacker and the decapsulator
implement IPv4 ingress filtering, and all IPv6 routers between the
decapsulator and Bob implement IPv6 ingress filtering, the above
spoofed packets will not be filtered out. As a result Bob will
receive a packet that looks like it was sent from Alice even though
the sender was some unrelated node.
The solution to this is to have the decapsulator only accept
encapsulated packets from the explicitly configured source address
(i.e., the other end of the tunnel) as specified in section 3.6.
While this does not provide complete protection in the case ingress
filtering has not been deployed, it does provide a significant
increase in security. The issue and the remainder threats are
discussed at more length in Security Considerations.
5. Security Considerations
An implementation of tunneling needs to be aware that while a tunnel
is a link (as defined in [RFC2460]), the threat model for a tunnel
might be rather different than for other links, since the tunnel
potentially includes all of the Internet.
Several mechanisms (e.g., Neighbor Discovery) depend on Hop Count
being 255 and/or the addresses being link-local for ensuring that a
packet originated on-link, in a semi-trusted environment. Tunnels
are more vulnerable to a breach of this assumption than physical
links, as an attacker anywhere in the Internet can send an IPv6-in-
IPv4 packet to the tunnel decapsulator, causing injection of an
encapsulted IPv6 packet to the configured tunnel interface unless the
decapsulation checks are able to discard packets injected in such a
manner.
Therefore, this memo specifies strict checks to ameliorate this
threat:
- IPv4 source address of the packet MUST be the same as configured
for the tunnel end-point,
- IPv4 ingress filtering MAY be implemented to check that the IPv4
packets are received from an expected interface,
- IPv6 packets with several, obviously invalid IPv6 source address
MUST be discarded (see Section 3.6 for details), and
- IPv6 ingress filtering should be performed, to check that the
IPv6 packets are received from an expected interface.
Especially the first check is vital: the to avoid the check, the
attacker must be able to know the source of the tunnel (difficult)
and be able to spoof it (easier).
If the remainder threats of tunnel source verification are considered
to be significant, a tunneling scheme with authentication should be
used instead, for example IPsec [RFC2401] (preferable) or Generic
Routing Encapsulation (GRE) with a pre-configured secret key
[RFC2890]. As the configured tunnels are set up more or less
manually anyway, setting up the keying material is probably not a
problem.
If the tunneling is done inside an administrative domain, proper
ingress filtering at the edge of the domain can also eliminate the
threat from outside of the domain. Therefore shorter tunnels are
preferable to longer ones, possibly spanning the whole Internet.
Additionally, an implementation must treat interfaces to different
links as separate e.g. to ensure that Neighbor Discovery packets
arriving on one link does not effect other links. This is especially
important for tunnel links.
When dropping packets due to failing to match the allowed IPv4 source
addresses for a tunnel the node should not "acknowledge" the
existence of a tunnel, otherwise this could be used to probe the
acceptable tunnel endpoint addresses. For that reason, the
specification says that such packets MUST be discarded, and an ICMP
error message SHOULD NOT be generated.