Subject: mech-v2: rewritten security text

From: Pekka Savola <[email-masked]>
Date: Wed, 28 Jan 2004 16:20:34 +0200 (EET)

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.