Subject: RE: (ngtrans) Re: RFC 3056

From: "Christian Huitema" <[email-masked]>
Date: Fri, 1 Feb 2002 10:09:43 -0800

The passage of RFC 3056 about security is a bit weak. It does say:

   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.

But it also adds that you can't do the check for packets that went
through a relay router. Brian mentioned having a list of the addresses
of relay routers, but that is not realistic either: given hot-potato
routing, the packets are ditched to the nearest relay that advertises
2002::/16; how can you get a list of all routers that do that in all
ISPs?

The security rules should in fact be rewritten as follow:

1) If the IPv6 source address is in a 2002::/16 domain, the IPv4 source
address should be consistent with it.

2) If the IPv6 source address is not in a 2002::/16 domain, and if the
destination address is in the 2002::/16 domain, then the IPv4
destination should be consistent with the IPv6 destination. The source
IPv4 address should not really be checked.

3) If neither the IPv6 source address not the IPv6 destination address
is in the 2002::/16 domain, then special rules apply -- the packets
should not be relayed, unless some form of ACL explicitly enables this
combination of IPv4 and IPv6 source and destination addresses.

As far as relay routers are concerned, they should only accept from IPv4
the packets that meet rule (1).

The reason for not checking the source IPv4 address in (2) is the
difficulty of either maintaining a list of all router addresses. The
only way to bypass that would be to use an anycast address as a source
address, but anycast source addresses can only be deployed by relaxing
ingress filtering for such addresses, which mean in practice that they
can be easily spoofed. If these addresses can be spoofed, then using
them is worse than not checking at all; at a minimum, using a
topologically valid source address allows for logging and tracing.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Feb 2002 16:15:19 +0100

Christian,

Your rules are good. When we revise 3056, they should go in.

However, I continue to believe that a paranoid site might well also
build an ACL of trusted relays (rather as a personal firewall builds
a list of acceptable ports). This site would not accept incoming relay
traffic by default; the first packet from a new relay would trigger
a human decision. 

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Sun, 3 Feb 2002 17:37:02 +0200 (EET)

> > address should be consistent with it.

I note that if source is 2002, destination will not be checked.

As my draft put it (decapsulation rules) [I added some explanation here]:

    if dst=2002                        1) or 2)
        dst MUST match dst_v4
            if src=2002                1)
                src MUST match src_v4
            fi
    elif src=2002                      3)
        src MUST match src_v4
    else
        drop
    fi
    accept

1) 6to4 router -> 6to4 router
2) 6to4 relay -> 6to4 router
3) 6to4 router -> 6to4 relay

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 5 Feb 2002 09:50:53 +0100 (CET)

> As my draft put it (decapsulation rules) [I added some explanation here]:

I think it would be useful to take yours and Christian's proposed rules
(which appear close to identical as far as I can tell) and look
at what threats the do not address i.e. to what extent it would still
be easy to circumvent IPv4 ingress filtering with the rules in place.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Tue, 05 Feb 2002 10:10:48 -0500

> be easy to circumvent IPv4 ingress filtering with the rules in place.

as far as I can tell, the only way to fix the ingress filtering problem
is to apply the same kinds of filters to the v6 packets that are 
currently being applied to v4 packets.  it that means applying filters
to v6 packets embedded in v4 packets, so be it.

to put it another way, ingress filtering is ineffective if you don't 
apply the filter to all inbound link.  tunnels are no different in 
this respect than any other kind of link.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Feb 2002 17:10:52 +0200 (EET)

> be easy to circumvent IPv4 ingress filtering with the rules in place.

Compare the rules when the source is of 2002::/16.  There's a difference:
destination address consistancy is not checked in both.