Subject: [mobile-ip] Routing headers: design team recommendation

From: Erik Nordmark <[email-masked]>
Date: Wed, 23 Jan 2002 21:34:55 +0100 (CET)

The MIPv6 security design team is trying to resolve the issues
around routing headers as used by MIPv6.

This note specifies the design teams' motivation and current position.
In order to move forward in an efficient manner it would be beneficial if
responses could make it clear whether it is 
 - a clarification (by putting CLARIFICATION: in the subject field),
 - an issue with a particular point (by putting ISSUE: in the subject field),
 - disagreement with the conclusion (by putting CONCLUSION: in the subject 
   field)

INTRODUCTION
============

There is background information on the security issues around
MIPv6's use of the routing header in draft-savola-ipv6-rh-ha-security-01.txt.
This note explores how to move forward on the routing header issue.

Today in IPv4, firewalls block IPv4 source routes by default.
The original motivation for this was that the TCP/IPv4 implementations reverse 
the source route received in a SYN and use it for the connection. This means 
that if source routes are allowed and hosts do any form of access control 
based on the source IP address (such as UNIX r* commands) they could be 
trivially spoofed.

In an IPv6 world the situation is different.
IPv6 nodes MUST NOT reverse an unauthenticated (with IPsec) routing header.
Thus routing headers can't be used to spoof IP address based access control.
(Of course, this doesn't mean that IP address based 
access control is good security - it is still a bad and grossly insufficient 
form of security - but folks might end up doing it when porting applications
from IPv4 to IPv6).

When there is an IPv6 firewall in place and it wants to prevent inside node A
from communication externally (for a subset or all protocols/port numbers) 
while allowing inside node B to communicate externally (for those 
protocols/ports) it needs to ensure that a routing header can't be used to 
reach node A via node B (where B might be a host or a router).

ALTERNATIVES
============

There seem to be three fundamentally different ways to approach this:
1. Make the inside nodes (hosts and routers) be "safe" enough in their 
   handling of routing headers that the firewall can avoid specific checks 
   on the presence of the routing header as well as the IP addresses contained 
   in the RH.

2. Make the firewall understand the routing headers and filter based on 
   their content.

3. Try to simplify things by not using Routing Headers for MIPv6

Make RH "safe enough"
---------------------

The implications of approach #1 seem to be draconian for other use of 
the routing header.
Not only can hosts not process routing headers and send the packet out (the 
same or a different interface), but internal routers cannot process routing 
headers either. 
If a router processes the routing headers then the above A/B scenario can be 
used to bypass the firewall policy for host A by source routing packets via 
the router B to A.

Thus the implications of #1 are likely to be that all hosts and routers must 
not process any routing headers and forward the packet. The only routing 
header  processing that would be allowed would be for a MN to process a RH 
where the packet doesn't leave the MN.

Thus in effect routing headers would not be very useful for the initially 
intended purpose; they would only be useful for the MIPv6 usage.

Make the firewall RH aware
--------------------------

When looking at #2 we need to understand what type of filtering a
firewall would need to have to prevent the A/B bypass while still allowing
MIPv6 to function.

There are several things needed for MIPv6 to function.
We need to be able to allow:
A. CNs inside the firewall need to be able to use RH to send to MNs outside 
   the firewall.
B. "visiting" MNs i.e. MNs who have a Home Address outside the firewall 
    and a CoA inside the firewall.
C. "local" MNs i.e. MNs where both the HoA and CoA are inside the firewall.

[Note that in general allowing A, B, and/or C might be subject to site's
firewall policy in general. Hence the use of "need to be able to allow" above.]
 A above doesn't cause any problems since allowing outbound RH through 
the firewall doesn't cause problems with the simple rules that A can't 
communicate externally.
However, if the firewall rules are more complex as in A only being able 
to communicate with a specified external IP address then there are issues 
if that external node is a MN and A would use a routing header when sending
to the MN.

The case B looks like an external entity sending a packet with a destination
being inside the firewall with the subsequent hop (in the RH) being outside
of the firewall.

Possible rules for a firewall to apply in approach #2 for packets
inbound to the site would be:
1. If the destination address is not inside the firewall then
	the firewall would presumably drop it
2. If there is no RH or an RH with zero elements then
	follow non-MIPv6 firewall policy
3. If the RH has more then one element then
	treat it as a non-MIPv6 routing header (whatever policy that is subject
	to)
4. If one element RH with the address in the RH being external to the site
   allow it (assuming "visiting" MNs are allowed)
5. If one element RH with the address in the RH being internal verify
   that the address in the RH is allowed to communicate externally with
   the protocol/port number. If so allow the packet with the RH.

The above firewall rules are somewhat complex and they can't, by the
very nature of the routing header, prevent source routing.
For instance, rule #4 means that packets can be source routed through
the site and back out again, and rule #5 allows some internal source routing.
Thus this approach assumes that there isn't a perception that IPv6 firewalls
need to block actual source routing while allowing the MIPv6 use of routing
headers. There is also a concern that the existing IPv4 firewall behavior 
of blocking source routing might be carried forth into IPv6 firewalls.
Should this happen there is a failure case where route optimization
is established through a Binding Update but the data packets, with the RH,
are dropped. If the CN somehow decides to discard the binding cache entry
and send through the HA, it is likely that this would anew result in a 
Binding Update.
Thus if this approach is taken it would seem prudent to make MIPv6 robust
against packets with RH being discarded.

Define a MIPv6 specific thing instead of using RH
-------------------------------------------------

An open question is to what extent approach #3 would make things significantly
simpler. The non-RH packet format could be to e.g. define a new destination
option, define a new extension header, define a new routing header type,
or use IPv6_NO_SRC as specified in 
draft-deering-ipv6-encap-addr-deletion-00.txt.
The following discussion doesn't assume any particular of the above 
encodings - it just assumes that it is a different encoding than the 
current routing header so that the firewall can have different policies
for source routing and MIPv6.

For all the encodings it is assumed that the rules are that
1) only a single address is contained in the encoding (just like a single
   element routing header), and
2) the receiving node never forwards the packet after processing it.

The encoding that is most consistent with the Home Address Option would
be to define a destination option carrying the Home Address for the
destination. This could be name the alternate (or "outer"?
"upper layer"?) destination address option.
If this approach is taken it might make sense to rename the Home
Address Option to have a similar name e.g. the Alternate Source Address Option.
 RECOMMENDATION
==============

The design team is leaning towards #3 at the moment. One
reason for this is that this would remove any suspicion that firewall
administrators have for the use of the Routing Header and
which might consequently lead to disabling MIPv6 because of these
fears. Also, the firewall rules necessary to process the Routing
Header are complex and accidental disabling of MIPv6 might also
occur. The use of the Routing Header for other purposes would
also not be affected. There are also drawbacks in alternative #3.
One such issue is that existing MIPv6 implementations have to
be changed. We feel that this drawback is offset by the expected
wider usability of MIPv6 as a result. This change will also imply
a substantial document modification for the MIPv6 I-D. This
does not appear to be a structural change, however, and in
general we feel that direct procedure is easier to describe than
attempting to describe some additional rules to constrain the use
of the Routing Header. Finally, alternative #3 might lead us to
depend on the external work such as the new tunnel encapsulation
work at IPNG. The design team feels that we should stay away
from these non-MIPv6 solutions due schedule issues as well
as in the interests of making a self-contained RFC.

---

---

From: Francis Dupont <[email-masked]>
Date: Fri, 25 Jan 2002 11:13:33 +0100

IMHO and if there is a consensus about the solution #3 (my opinion
is this is the best solution if this is implemented carefully)
I believe we should not propose a new non-final extension header.
So if other points show a strong interest for IPv6_NO_SRC stuff,
we should use it. If not, a new routing header type is the simplest
so the best solution. Of course in the last case a type value
should be proposed ASAP.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Fri, 25 Jan 2002 11:22:54 +0100

Currently some IPv6 implementations don't safely deal with RH,
for instance they blindly forward by default packets with RH
in the host mode. The IPv6 WG should warn ASAP implementers
that RFC 1122 section 3.3.5 security considerations apply
without possible harm to Mobile IPv6 (fine consequence of approch #3).
I don't know how this recommendation should be broadcasted.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Fri, 25 Jan 2002 13:35:40 +0200

>I don't know how this recommendation should be broadcasted.

Right. Perhaps we can make a some sort of announcement
somewhere, but little further down the road this recommendation
must find itself to the IPv6 host requirements document.

By the way, there already is some safety text in this direction
at the cellular host requirements draft
(draft-manyfolks-ipv6-cellular-host-02.txt).

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 25 Jan 2002 09:35:21 -0800

hi,

I agree with the Design Team's recommendation. And I would prefer
changing it to a destination option. (True Destination Address??)

>  RECOMMENDATION

Agree completely on the last point. and going by the last point,
a destination option seems to be the best thing to do (IMO).

regards
Vijay

---

From: Francis Dupont <[email-masked]>
Date: Sat, 26 Jan 2002 15:02:53 +0100

>...

=> a new destination option doesn't work well for a mobile router.
IMHO we should keep the "routing" element from Routing Headers
(so I am still in favour of either a new type of RH or Steve
Deering's special cases of tunnels.

Regards

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Jan 2002 00:49:40 +0200 (EET)

> must find itself to the IPv6 host requirements document.

I can make a very short draft (~2 pages including the disclaimers :-) on
the issue before IETF53 as a placeholder until the requirements draft
appears, and if ipv6wg deems it appropriate, present the issue.

-- 
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: Mon, 28 Jan 2002 14:36:02 +0100 (CET)

> so the best solution. Of course in the last case a type value

Francis,
You didn't comment on the relative preference of defining a new
destination option. Perhaps the writeup wasn't clear on the different
alternatives for implementing #3. The ones I know of are:
 - New destination option
 - IPv6_NO_SRC extension header type
 - Some other new extension header type just for the additional destination
addr
 - New routing header type 

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jan 2002 14:41:22 +0100 (CET)

> I don't know how this recommendation should be broadcasted.

I think it makes sense to discuss this just on the ipng mailing list,
but the actual discussion depends on whether MIPv6 will use RH or not
so it makes sense to wait until the WG has consensus on that topic.

The above section in RFC 1122 says among other things:

         To define the rules restricting host forwarding of source-
         routed datagrams, we use the term "local source-routing" if the
         next hop will be through the same physical interface through
         which the datagram arrived; otherwise, it is "non-local
         source-routing".

         o    A host is permitted to perform local source-routing
              without restriction.

         o    A host that supports non-local source-routing MUST have a
              configurable switch to disable forwarding, and this switch
              MUST default to disabled.

In private mail some folks have questioned the wisdow of recommend 
this "local source routing" in IPv6, and that level of discussion 
belongs in the IPv6 WG.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jan 2002 15:29:38 +0100 (CET)

> Deering's special cases of tunnels.

While mobile routers and mobile networks are out of scope I think it would be 
useful to try to understand what you think is the requirement here because
deering/zill tunneling and a new RH type seems to have rather different
properties.

Is the requirement that a mobile router should be able to (or always)
remove this "routing element" from the packet before delivering them to
MNs behind the MR?

Deering/zill tunneling would potentially allow that (assuming the tunnel
terminates at the MR) but destination options or new RH type would
not allow that as far as I can tell.

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Jan 2002 10:54:01 -0800 (PST)

>               MUST default to disabled.

   Under what conditions would a user not be crazy to
   enable it?

		Mike

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jan 2002 14:58:28 +0100 (CET)

>    Under what conditions would a user not be crazy to

Parsing problems. I'm assuming you're asking why would anybody ever
enable this switch.

Perhaps there is a site which internally is using traceroute -g for hosts
today (i.e. the NOC does a traceroute -g when the debug problems) and they
want to preserve this. So they use their automagic management tools to 
automatically turn on the switch in all of their hosts.

But mostly this is a way to handle exceptions to the norm, with the norm
being that hosts not forward source routed packets.

But, this is a discussion for the ipv6 WG.

  Erik

---

From: "Pascal Thubert" <[email-masked]>
Date: Tue, 29 Jan 2002 18:37:03 +0100

<Erik>Is the requirement that a mobile router should be able to (or always)
remove this "routing element" from the packet before delivering them to
MNs behind the MR?
</Erik>

I understand that this discussion is a bit out of scope, yet it would be
beneficial if Mobile Nodes and Mobile Routers could as much as possible
behave consistently. I agree that mobile Router may want to hide the
mobility to Static Nodes. But the point here seems more that a Mobile Router
may attach to a Mobile Network of another MR in a nested configuration. This
recursively builds a graph of Mobile Routers. A solution which finally
builds allows the CN/HA to send a RH with all the VIA MRs of the nested
networks would be best from the MR standpoint...

Pascal Thubert

---

From: Francis Dupont <[email-masked]>
Date: Tue, 29 Jan 2002 18:48:49 +0100

> Deering's special cases of tunnels.
   
   While mobile routers and mobile networks are out of scope

=> they are out of scope but we should not impede future works about them
(we are in a "matter of taste" case so any argument should be accepted).

   I think it would be 
   
=> tunnels, degenerated tunnels (Deering/Zill) and RH are routing devices
(this is my first argument against DO which is not a routing device).
None of them have a "end node" property like a DO, i.e. the action
of the routing device can finish before the real destination.
This is my second argument against DO which has not this feature
(which can be very useful for mobile routers or networks).
I can see a deep difference between tunnels and degenerated tunnels
but I agree there is one between tunnels and RH: RH has a history feature,
i.e. after its action it is possible to know what happens. This feature
can be useful for security, for instance with ingress filtering a tunnel
must be integrated in the whole routing system in order to be taken into
account (a recurrent problem with tunneling :-), RH gives the previous
intermediate source... This is the second "small" argument in favor
of RH, the first one is of course the deployment/procedure simplicity.

=> I can't see a general case where this removal is useful.

=> IMHO the "end node" property is far more important (in the down side)
than the history property (where RH is better than DO because RH type 0
was designed to be reversible).

But today I believe we should invest more to reach a consensus about
approach #3...

Regards

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Jan 2002 20:52:04 +0200 (EET)

> appears, and if ipv6wg deems it appropriate, present the issue.

Attached is a draft I wrote.  Originally I didn't want to add my view of 
the issue (because then reaching consensus might be more difficult), but 
in the end put it in an appendix.

Any comments?  Disagreement?

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 29 Jan 2002 12:25:18 -0800

Hello Francis,

> was designed to be reversible).

Routing headers should not be reversed unless there is a good
reason to do so.  But I think you would also agree with this;
I just wanted to make it clear.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jan 2002 22:54:07 +0100 (CET)

> networks would be best from the MR standpoint...

Yes, I think this is MONET material.

And the issue whether and how stationary hosts "riding" in a mobile network
are kept unaware of the movement of the monet while mobile nodes attached
in the same place can be made aware of it seems challenging - but for MONET
to figure out.

But your point about nesting might be worth-while thinking about.
I don't think routing headers are ideal for nesting - the receiving
host would end up with a packet that contains N routing header with each
of them having segments_left=0.

It would seem cleaner if the (nested) mobile routers could in fact
remove this information - which would argue for something that looks more
like IPV6_NO_SRC tunneling.

But I have a hard time understanding how we can take arguments like this
into account given that we don't yet know much about the assumptions and
requirements for the monet set of problems.

Can a credible argument be made that one of the ways to carry the address
is more flexible i.e. might be more malleable once we know more about monets?
Or is there some other way we can take the monet factor into account?

  Erik

---

From: "Pascal Thubert" <[email-masked]>
Date: Wed, 30 Jan 2002 11:51:24 +0100

<Erik>
And the issue whether and how stationary hosts "riding" in a mobile network
are kept unaware of the movement of the monet while mobile nodes attached in
the same place can be made aware of it seems challenging - but for MONET to
figure out.
</Erik>

The thing is that a Mobile Node may ride a Mobile Network. You'll get a hard
time optimising the path if the models diverge.

<Erik>
But your point about nesting might be worth-while thinking about. I don't
think routing headers are ideal for nesting - the receiving host would end
up with a packet that contains N routing header with each of them having
segments left=0.
</Erik>

I did not mean that the nested Mobile Networks would necessarily lead us to
several RHs one after the other. I meant we want a single RH with as many
segments as nested networks, for the CoAs of the Mobile Routers and the CoA
of the final CN if any.

Say that all the intermediate MRs exchange BUs with the CN, for example
using T. Ernst's proposal (draft-ernst-mobileip-v6-network). The CN could
recursively realizes that the Mobile Networks are nested, and builds a RH
accordingly. I do not necessarily favour that idea because of the burden on
the CN, the BU traffic involved, and the time to converge, but at least it's
possible. What do you think?

Pascal Thubert

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jan 2002 14:03:45 +0100 (CET)

> possible. What do you think?

We're deep in Monet land at the moment but I'll respond in any case.

For the case when the whole path is route optimized you are right that the CN
could construct a RH listing all the CoAs.

But when only part of the path is optimized e.g. the CN knows what train the
MN is in (the HoA of the MR) but it doesn't know the current location
of the train (the CoA of the MR) then the CN can only construct something
that goes to the HoA of the MR and the MR's HA will need to nest by including
something which carries the CoA of the MR. 
If RH is used for all of this it seems like there might be multiple RH
headers - but perhaps RH can't be used in this way because of path MTU
issues and instead encapsulation must be used from the HA(MR) to the MR.

  Erik

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Wed, 30 Jan 2002 15:39:18 +0100

Hi,

Comments concerning #2 (ie. about firewall and RH).

IMO, there could be two FW policies :
1. Policy based on MIPv6-H@
This case, IMHO ,is the simplest policy  but the most complex to
administrate: the FW checks the last @ in the RH
2. Policy based on MIPv6-Co@
In this case, the FW checks the last address in the RH (ie. RH-@[Segments
Left]). If this is a MIPv6-H@ (ie. not topologically correct), then it
checks the RH-H@[SL-1] and then resolves the case regarding its policy.

Comments are welcome :-)

PS : I am not a FW vendor, so I think it would be better if some FW guys
could give their opinions.

Regards.

JMC.

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

> -----Message d'origine-----
> De : [email-masked]
> [mailto:[email-masked]]De la part de Erik Nordmark
> Envoye : mercredi 23 janvier 2002 21:35
> A : [email-masked]
> Objet : [mobile-ip] Routing headers: design team recommendation
>
>