Subject: (ngtrans) draft-ietf-ngtrans-mech-04.txt: security issue

From: [email-masked]
Date: Sun, 12 Mar 2000 23:07:29 +0900

About draft-ietf-ngtrans-mech-04.txt: Could we put more explicit
	wording about addresses (inner and out) on the packet? If the
	receiving node does not filter out non-conforming packets properly,
	there will be security issues.  Ingress filter (section 5.6) is a big
	plus (thanks for the addition!), but not really a complete solution.

	I personally would like to see the following restriction, from security
	perspective.  Actually this may be more restrictive than mech-04
	suggests.  Gory details are attached below.

	    A packet generated by automatic tunnel must carry the following
	    header fields.  Note that inner header field must match the
	    outer header field.

	    outer header
		IPv4 src: IPv4 address of the originating node
		IPv4 dst: IPv4 address of the destination node (not multicast)
	    inner header
		IPv6 src: IPv4 compatible for IPv4 src
		IPv6 dst: IPv4 compatible for IPv4 dst

	    Under any of following conditions, receiving node MUST drop the
	    packet:
	    - any of IPv4 src/dst is an IPv4 multicast address (224.0.0.0/4)
	    - any of IPv4 src/dst equals to 0.0.0.0
	    - any of IPv4 src/dst equals to 255.255.255.255
	    - any of IPv4 src/dst equals to a broadcast address of any of 
	      subnets directly connected to the receiving node
	    - if IPv4 src violates ingress filter rule
	      (incoming interface for the packet != outgoing interface for
	      IPv4 src, computed by the routing table of receiving node)

	Even with the check, malicious party can inject fabricated source
	address (for both IPv4/v6) to force receiving node to reply to
	wrong address (like someone's broadcast address).  In the folloing
	itojun replies to the packet, and the reply packet causes trouble.
	This is same as problem in forged IPv4 source address, so I think
	we are unable to solve it.
		badguy --auto tunnel--> itojun --auto tunnel--> victim
			(victim->itojun)	(itojun->victim)

	Some analysis on RFC1933, and 6to4-03 (04 is mostly the same) can be
	found at:
http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-00.txt
	(yes, I missed the i-d cutoff).  I should have checked mech-04 instead.

itojun

* requiring exact match betwen IPv6 src and IPv4 src
	From draft-ietf-ngtrans-mech-04.txt section 5.3 and section 5.4, it
	looks that the only corect form of packet from auto tunnel is like
	this.

	    outer header
		IPv4 src: IPv4 address of the originating node (*2)
		IPv4 dst: IPv4 address of the destination node
	    inner header
		IPv6 src: IPv4 compatible for IPv4 src
		IPv6 dst: IPv4 compatible for IPv4 dst (*1)

	IPv6 destination must always be IPv4 compatible for IPv4 destintaion
	from paragraph 1 of mech-04 section 5.3 (*1).

	mech-04 section 5.4 suggests to have configured tunnel between A
	and C.  This does not require injection of ::/96 route, as long as
	A has global IPv6 address (B can assign an address to A from directly
	attached subnet, and perform proxy NDP for A).
		A <--conf tunnel-- B <--native IPv6-- C
		A ---auto tunnel-------------------->
	Therefore, we can assume that the only address pair appear on the
	auto tunnel is the IPv4 compatible for IPv4 src (*2).  In the above
	example, source on auto tunnel is A.

	RFC2185 3.3.4 tries to cover the following case, where we may see
	non-matching IPv4/v6 source:
		A <--auto tunnel-- B <--native IPv6-- C
		A ---auto tunnel-------------------->
	A packet from C to A will have the following addresses, and IPv6 source
	does not match IPv4 source.
	    outer header
		IPv4 src: B's IPv4 addr
		IPv4 dst: A's IPv4 addr
	    inner header
		IPv6 src: C's normal IPv4 addr (not IPv4 compat)
		IPv6 dst: A's IPv4 compat addr for IPv4 dst
	Because this implies the existence of route for IPv4 compatible
	address (for routing packet from C to B), it seems to be less
	practical for use in wide area.
	From RFC2772 section 3.5, ::/96 is forbidden for EGP.
	RFC2185 is based on RFC1933, so I think mech-04 can override RFC2185.

	Revision of mech-04 should clarify this, by:
	- saying that some of the items in RFC2185 do not match mech-04/05, or
	- dropping reference to RFC2185

* forbidding multicast IPv4 address in outer header
	The last sentence in draft-ietf-ngtrans-mech-04.txt section 5.4
	leaves little room of ambiguity: do we need to allow multicast
	IPv4 address in outer header?  I think we can safely drop them
	(sender rule already forbids it).

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Mar 2000 13:00:59 -0800 (PST)

Unless somebody has problems with these additional constraints
when decapsulating automatic tunnelled packets I'll add the constraints
to section 5.6.

> 	      IPv4 src, computed by the routing table of receiving node)

I'd like to replace the last bullet with a just a reference to 
the ingress filtering RFC.

   Erik

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 14 Mar 2000 08:52:12 +0900

>the ingress filtering RFC.

	yup, that's fine.

	please add the following to the drop condition (just to clarify):
	- if inner src/dst header does not match the sender rule

itojun

---

From: Steve Deering <[email-masked]>
Date: Tue, 14 Mar 2000 07:40:59 -0800

> > 	    Note that inner header field must match the
> > 	    outer header field.

What does that mean?

Steve

---

From: [email-masked]
Date: Wed, 15 Mar 2000 01:13:58 +0900

>> > 	    Note that inner header field must match the

	IPv4 src/dst address in outer IPv4 header must match the
	IPv6 (in IPv4 compatible address) src/dst address in inner IPv6 header.

itojun

---

From: Steve Deering <[email-masked]>
Date: Tue, 14 Mar 2000 08:33:51 -0800

>	IPv6 (in IPv4 compatible address) src/dst address in inner IPv6 header.

Ah.  OK, that clearer explanation should go in the document.

Steve

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 14 Mar 2000 09:53:07 -0800 (PST)

> 	IPv6 (in IPv4 compatible address) src/dst address in inner IPv6 header.

Thinking about this some more ...

When decapsulating a packet that was encapsulated with automatic
tunneling it is absolutely clear that the IPv6 destination should be an
IPv4 compataible address and that it should match the outer IPv4 destination
address.

But for the source address we have in the far past talked about routers
doing automatic tunneling for IPv4-compatible addresses.
In that case the sources would not match.
If we implement the above restrictions we will disable that capability
(it might be the right thing to do - I just feel we should ask the explicit
question).

Also, even for end-end automatic tunneling requiring "matching" source
addresses as above means that the sender is required to have
an IPv4-compatible IPv6 address in order to send packets to an
IPv4-compatible destination address. Once again, this might be the right choice
but I feel we should ask the explicit question.

   Erik

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 15 Mar 2000 08:53:09 +0900

>(it might be the right thing to do - I just feel we should ask the explicit

	The above case is like:
		source --IPv6 native-> router --auto tunnel-> dest

		on IPv6 header of the packet (inner):
			src=normal IPv6 address of source
			dst=IPv4 mapped address of dest
		on IPv4 header of the packet between router and dest (outer):
			src=IPv4 address of router
			dst=IPv4 address of dest

	With mech-04 sender rule, the packet will never appear from the
	first place.  The source is required to send the packet in auto tunnel
	form, not IPv6 native.  (see section 5.3, paragrah 4)
	The behavior was already changed between RFC1933 -> mech-04, I believe.

	There might be one pithole: mech-04 does not talk about what the
	behavior of IPv6-only sending node should be.
	(for example, what should happen if the "source" on the above diagram
	is IPv6-only?)

>but I feel we should ask the explicit question.

	I think this is the right choice.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Mar 2000 08:40:22 -0600

Jun-ichiro itojun Hagino wrote:
...
>         I think this is the right choice.

Why? What is the value of this restriction? It seems to be a real limit on
deployment scenarios to me.

I'm beginning to think that all these rules have to be configurable. From
experience with IPv4 VPNs, this seems to be the only way to have adequate
flexibility.

  Brian

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 15 Mar 2000 23:56:15 +0900

>experience with IPv4 VPNs, this seems to be the only way to have adequate

	Without this check, your node will be attacked by malicious parties
	and generate unuseful (or harmful) packets, which would chew up your
	precious bandwidth.

	Actually, if the sender obeys mech-04 sender rule, we will only see
	packets that has matching src/dst in inner/outer.  No other
	combinations will appear on the wire, if the sender follows the rule
	carefully.  The wire packet change is due to the changes between
	RFC1933 and mech-04, this is not my call.  I just wanted to get more
	explicit wording, to help implementers filter out non-conforming
	packets.  Are you unhappy with RFC1933 -> mech-04 changes?

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Mar 2000 11:53:20 -0600

>         packets.  Are you unhappy with RFC1933 -> mech-04 changes?

Firstly I'm not saying no checks. I am saying that it should be possible to
configure the checks (as I do today on my VPN software and my personal
firewall).

Second, OK, I see that mech-04 excludes automatic tunnels involving routers.
That does make me wonder why we bother with them (given that 6to4 does just
about the same thing but more flexibly). But if we accept this exclusion,
then the check you propose is not a problem.

  Brian

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 15 Mar 2000 14:14:17 -0800 (PST)

> 	The behavior was already changed between RFC1933 -> mech-04, I believe.

The text doesn't quite say that - it talks about the "auto-tunneling module".
Thus on all nodes that have an auto-tunneling module your observation
is correct. But we don't require all dual-stack hosts to have an
auto-tunneling module. 

> 	(for example, what should happen if the "source" on the above diagram

That is another issue.

So unless we want to restrict automatic tunneling to be solely end-end
(i.e. the sender MUST encapsulate when sending to an ipv4-compatible address)
we can't enforce the source address checks when decapsulating.

If we make that restriction then ipv4-compatible addresses will be even
less useful than they are today.
For instance, putting an ipv4-compatible address in the DNS means that
only dual-stack nodes which have an "auto-tunneling module" and
an IPv4-compatible address themselves will be able to reach that 
address.
Sounds like one could never put IPv4-compatible address in the (global) DNS 
under such constraints.

Is this new limitation an acceptable cost for making it harder to
use automatic tunneling as a way to circumvent IPv6 ingress filtering?

   Erik

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 16 Mar 2000 09:00:28 +0900

>> 	(for example, what should happen if the "source" on the above diagram

	Hmm, then I need to see text that covers sender rule for
	- IPv6-only node, or
	- IPv4/v6 dual stack node without IPv4 address assigned
	they can be:
	- should not transmit the packet to outside of the node
	- should send packets to IPv4 compatible destination with blablabla

	As you may have guessed, former one has my personal preference.

>Sounds like one could never put IPv4-compatible address in the (global) DNS 

	Since we have no global route entry for ::/96 between ASes (EGP),
	practically it is not very meaningful to put IPv4-compatible onto
	global DNS database (RFC2772 3.5).  Even if we put an IPv4 compatible
	address for node A onto DNS database, from RFC2772 3.5, it is not
	possible to reach the node A from any IPv4-non-capable in different
	AS from node A.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 15 Mar 2000 16:28:15 -0800 (PST)

> 	As you may have guessed, former one has my personal preference.

While such text might make sense somewhere I'd like to treat that as outside
the scope of trans-mech - that document talks about dual-stack and currently
says nothing substancial about IPv6-only nodes.

> 	possible to reach the node A from any IPv4-non-capable in different

While we don't ever want global routes for anything in ::/96
the rest of your argument doesn't follow from that.

As trans-mech (and RFC 1933) is currently written it is possible to
have a site with dual-stack and/or IPv6 only nodes that have a
::/96 route to some "local" router. That router can then implement an
"auto tunneling module" that will do the encapsulation.
Thus the individual (dual or IPv6-only) hosts do not need an auto-tunneling
module and do not need IPv4-compatible addresses to be able to communicate with
nodes that have IPv4-compatible addresses.

Note: I'm not saying that we need to preserve the above behavior; it might very
well make sense to add your proposed restrictions that force auto-tunneling to 
be end-to-end. I'm just pointing out that your above argument that it isn't 
currently usable is incorrect.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 15 Mar 2000 16:44:16 -0800 (PST)

After looking at the specific text in section 5.6 some more I realized the
following.

When automaticcally tunneled packets are decapsulated they SHOULD NOT be
forwarded since the auto tunnel always terminates at the endpoint.
Thus if we continue allow the IPv6 source and IPv4 source in the packet to
not "match" the worst that would happen is some form of DoS attack that
circumvents ingress filtering *but* the target of the attack has
both the IPv4 (topologically correct) address and the potentially bogus
IPv6 source address. Thus the target has the possibility to log both
addresses when subject to DoS attacks.

This argument is basically the same as the argument why the Mobile IPv6
home address option does not need to be authenticated by itself
(see draft-ietf-mobileip-ipv6-10.txt).

Thus wouldn't it be sufficient to recommend that implementations make
both source address available when logging security relevant events?

   Erik

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 16 Mar 2000 10:03:58 +0900

>the rest of your argument doesn't follow from that.

	sorry I wasn't careful enough.  confusing...

>nodes that have IPv4-compatible addresses.

	hmmmm...  about ::/96 route in a site, I think, is either of follows:
	- if we would like to cover relayed case like this:

		IPv4 non-capable node --native IPv6--> relay
			--auto tunnel--> final destination

		(*) the relay and the final destination are auto tunnel capable.

	  we need to document it in mech-??.  without written documentation
	  admins have no idea how to configure a site.
	- if we don't want the relayed case, we need to explicitly reject it
	  in the document.

	currently mech-04 is silent about it and I figured - maybe wrongly -
	that only auto tunnel capable node should be able to transmit to
	v4 compat address.

>currently usable is incorrect.

	thank you for clarification.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Mar 2000 12:51:29 -0600

I definitely want to see the possibility of routers originating auto
tunnels; it seems a pointless restriction to limit them to e2e use.

So I agree with Erik.

    Brian

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Mar 2000 10:44:51 -0800 (PST)

Itojun,

I noticed that there is an updated draft for the addressing architecture
(draft-ietf-ipngwg-addr-arch-v3-00.txt) thus if you feel we should add
something about rejecting bad IPv4-mapped addresses this might be a good
time to ask that question on the ipng list.

FYI: My draft text for ngtrans-mech reads:
   After the decapsulation the node SHOULD silently discard a packet
   with an invalid IPv6 source address.  This includes IPv6 multicast
   addresses, the unspecified address, and the loopback address but also
   IPv4-mapped IPv6 source addresses where the IPv4 part of the address
   is an (IPv4) multicast address, broadcast address, 0.0.0.0, or
   127.0.0.1.

  Erik

---

From: [email-masked]
Date: Tue, 21 Mar 2000 19:07:10 +0900

>time to ask that question on the ipng list.

	Thanks, I'll raise it in ipngwg (since the document is tagged as
	ipngwg document).

itojun