Subject: [mobile-ip] Routing headers - part 2

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Feb 2002 22:32:24 +0100 (CET)

The MIPv6 security design team is trying to resolve the issues
around routing headers as used by MIPv6. 
Now we've come to the part about what the packet format should be.

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
============

The co-chairs have stated that there is consensus to switch from
using Routing Header type 0 to some other "packet format" that is
less likely to cause confusion e.g. in firewalls with RH type 0.

The purpose of changing it from RH type 0 is to make mobile-ip less
vulnerable to the attacks described in 
draft-savola-ipv6-rh-ha-security-01.txt by making it possible for
firewalls to tell the difference between MIPv6 and general source 
routing, and making it less likely to cause confusion.

The basis for comparing these alternatives does not take into
account issues relating to Mobile Routers or Mobile Networks because
it isn't clear what the architecture will be for such things, to what
extent they will use route optimization, and how such optimizations would
be effected by the choices made for Mobile IPv6.

The evaluation of the proposals takes into account short term issues
like the ease at which existing implementations can be modified
but also tries to look at longer term issues like the architecture and
the complexity of the complete system.

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

The previous email suggested 4 different ways to carry the HoA towards 
the mobile node:
1. Use a new destination option
2. Use a new routing header type
3. Use IPv6_NO_SRC from draft-deering-ipv6-encap-addr-deletion-00.txt
4. Use a new extension header type 

New destination option
----------------------

The idea is that a new destination option, perhaps named Alternate Destination
Address, would be defined. That option would contain the IPv6 HoA for
packets destined towards a mobile.
The specification would need to ensure that processing the HAO
doesn't cause the destination address field to be rewritten and
later the packet be forwarded out of the node.

The size of the option would be 18 bytes including type and length
and the size of the destination options header containing such an
option would be 24 bytes.

The destination options header would appear before any ESP or AH headers
but after any routing headers.
The effect of processing it would be that the IPsec SA lookup
gets done on the Home Address. 
The specification would need to state exactly what values are in what
fields when AH and ESP is run on the sender and receiver (which is
the same issue as with the HAO today).

If both a HAO and an ADA needs to be sent (for communication between two
MNs) it makes sense to require that both be present in the same
Destination Options header.
There does not seem to be any benefit of constraining the order of
the HAO and ADA in that extension header.

Pros:
1. For route optimized packets between two MNs the senders and receivers
   HoA would be contained in the same destinations options header - as
   a HAO and a ADA option respectively. This might make it easier to
   implement.
2. No dependency on another WG.

Cons:
1. This would not interoperate with existing MIPv6 implementations.
   Depending on setting of the high-order bits in the option type an ICMP
   error could me made to appear at the sender which will aid in diagnosing
   when talking to an old implementation.
2. Path MTU - an implementation needs to be aware of the local issue
   when the IP layer adds stuff to the packet without the transport layer
   being aware of it. Making the transport layer aware solves this.

Neutral:
1. An CN implementation needs to add a different bag of bits when
   it finds a BCE for the destination, but this is a fixed bit pattern
   followed by the HoA so it shouldn't be hard.
2. IPsec interaction the same as for HAO.
3. The ADA option does not nest e.g. when there are nested route optimizations.
   But the HAO does not nest either.

Unknown:
1. The option is not removable before the packet reached the endpoint.
   While this seems to be potentially useful for Mobile Routers/Networks
   there isn't enough understanding of nested route optimization in
   the Monet space to make any determination.
2. A MN sending presumably needs to do the "should I add HAO" and "should I
   add ADA" close to each other in the code so that it can determine the
   size of the necessary Destinations options header.
   This might effect the implementations. Today implementations can decide
   whether a RH needs to be added separately from deciding whether a HAO
   needs to be added, even if the total size needs to be taken into
   account for PMTU adjustments.

Summary:
Well-understood and relatively small change.

New routing header type
-----------------------

The idea is to define Routing Header type 1 to be a constrained
routing header than can only contain exactly one IP address.
Nodes that receive packets with such a RH MUST NOT forward the packet
outside the node as a result of processing the RH.
And nodes receiving the RH MUST verify that the address on the RH is
the Home Address (or one of potentially multiple Home Addresses)
assigned to the node.

When both a RH type 0 and a RH type 1 header is present in the
packet the type 0 header must be before the type 1 header.

The intent is that firewalls that block Routing Header type 0
due to perceived security issues not block Routing Header type 1
due to its much more constrained specification.

Pros:
1. Small and easy change to MIPv6 implementations.
2. No dependency on another WG.

Cons:
1. A sender implementing RH type 1 can't interoperate with a MIPv6 receiver
   using the current RH type 0. The packets will be dropped and ICMP 
   parameter problem message will be sent packet which helps diagnose such
   a problem.
2. Path MTU - an implementation needs to be aware of the local issue
   when the IP layer adds stuff to the packet without the transport layer
   being aware of it. Making the transport layer aware solves this.

Neutral:
1. Does "nest" i.e. can be applied recursively. But the HAO does not nest
   hence there doesn't seem to be any benefit.

Unknowns:
1. There might be some concern that the "be conservative what you accept"
   firewall default configurations and/or firewall administrators will fail to 
   understand that RH type 0 and RH type 1 are conceptually different things.
   Hence all RH independent of type might get tossed.
2. The assumption is that the IPv6 WG will not object to defining a new routing
   header type with the above semantics.

Summary:
Well-understood and minimal change to implementations.
Predicting the behavior of firewall implementors and administrators 
is very hard.

Use IPv6_NO_SRC
---------------

The idea is to specify that instead of RH the IPv6_NO_SRC
Deering/Zill tunneling header specified in 
draft-deering-ipv6-encap-addr-deletion-00.txt should be used.

There might not be any benefit to do this unless HAO is also replaced
by IPv6_NO_DST tunneling and that the case of traffic between two
MNs (where logically 4 addresses need to be in the packets) is handled
using IPv6-in-IPv6 tunneling (RFC 2473).
Thus the IPv6_NO_SRC and IPv6_NO_DST can conceptually be viewed as an
optimization saying 16 bytes in the packets when only 3 IP addresses
need to be communicated.

Pros:
1. Fits well with existing practise for tunneling e.g. between HA and MN
   as well as IPsec tunneling.
   But the benefit of this are probably limited unless HAO is also
   replaced by IPv6_NO_DST tunneling.
   Thus the total complexity might be the smallest (least amount of code)
   if this is used instead of RH and HAO.
2. Nests i.e. can be applied recursively for both source and destination, but
   it isn't known if nesting will ever be needed or required.

Cons:
1. A sender implementing this can't interoperate with a MIPv6 receiver
   using the current RH type 0. The packets will be dropped and ICMP 
   payload type unknown messages will be sent packet which helps diagnose such
   a problem.

Neutral:
1. Path MTU - an implementation needs to be aware of the local issue
   when the IP layer does tunneling. But current IP-in-IP tunneling
   software (e.g. for MIPv4 and IPsec) already handle this.

Unknowns:
1. Adds a dependency on the IPv6 WG finishing and advancing the specification
   of IPv6_NO_SRC in a timely manner.
   If the MobileIP WG thinks this is critical presumably this can help
   speed up the process.
2. Exact IPsec interaction needs to be specified.
   (There were some open issues on this discussed in IPv6 WG in SLC.)
3. Implementations often do tunneling as a pseudo-device driver, in which case
   there are some unknowns in terms of the effect on the structure
   of an implementation.
   While the transmission of these headers based on BCE entries can be
   done without any relationship with existing tunneling code in an
   implementation, encapsulated packets that are received are likely to
   end up in such a tunneling device driver piece of code. (At least for
   MN to MN communication where the RFC 2473 would be used.)
   Thus any such tunneling pseudo-device driver would need to interact
   with the Mobile IP code in order to verify whether it is ok to
   decapsulate a given packet.

Summary:
It might very well be that this approach would lead to the least amount
of code in an implementation and conceptually the cleanest.
But there are unknowns in terms of the actual impact on actual implementations
as well as open issues about the specification which would make this
a risky approach.

New extension header type
-------------------------

The idea is to define a new extension header that will just contain
the ADA (if the new extension header would be capable of carrying both
the ADA and the HAO this proposal would be identical to using Deering/Zill
tunneling.)

The order between this extension header and a destination options header
with a HAO need some care in an implementation.

Pros:
1. Unlike IPv6_NO_SRC this could be done without a dependency on any other WG.

Cons:
1. Lots

Summary:
All the pain and little gain - this doesn't seem to make any sense.

RECOMMENDATION
==============

The use of D/Z tunneling seems to be the best long-term answer.
However, there are significant unknowns both in terms of finishing
the specification as well as understanding the impact on implementations.
Also, the potential for D/Z tunneling to be used for other purposes
than MIPv6 creates some potential concerns for firewalls.

The design team recommends that future work, e.g. in the area of Mobile
Networks, look into D/Z tunneling (after they've decided what problems need
to be solved of course).

If a new destination option is chosen it seems like the "Home Address Option"
would be the ideal name for such an option, but that name is already
taken. Thus in this case the DT recommends that instead of definiting
a new option called ADA (alternative destination address) instead 
the existing HAO option *code* should be renamed to SHAO (for "Source HAO") 
and a new option *code* be allocated for a DHAO ("Destination HAO) both 
using the existing HAO option *format* specified in the mipv6 draft.

The tradeoff between RH type 1 and a new destination option is far from
obvious. The summary of this is that a new RH type is a trivial code change
but that there are some concerns in the area of firewall interaction, while
a new DO causes some more code changes but can be clearly labeled as
"MIPv6" i.e. should not be accidentally filtered by firewalls.

The design team recommends using a new destination option instead
of a new routing header type.

The WG chairs would like to obtain WG views and consensus on the following
two choices:
Please respond with motivation for the ones you don't AGREE with:
1. New Destination Option (AGREE/DISAGREE/CAN LIVE WITH)
2. New RH Type 1 (AGREE/DISAGREE/CAN LIVE WITH)

ACKNOWLEDGEMENTS
================

The MIPv6 working group and its many members have contributed to
this writeup. In particular discussions with Francis Dupont, Pekka Savola, 
Charlie Perkins, and Jari T. Malinen have helped clarify the issues.

---

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Feb 2002 22:19:48 +0100

New routing header type
   -----------------------

=> ARGH!!! The type 1 is already allocated by IANA to NIMROD,
cf http://www.iana.org/assignments/ipv6-parameters !
Why do you believe we talked about type 2?

Regards

[email-masked]

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 12 Feb 2002 15:47:51 -0800

Erik,

Thanks for the writeup. To participate to forming
the WG opinion,

my favorite is the RH type 2 due to minimal change and 
since I disagree that the semantical similarity to RH T0
for fw admins would be big enough issue for them to drop
RH T2 as well. Comparing to DO, fw implementors and users
need to know something about the new DO, too.

AGREE with having RH T2 but with the above disagreement on
a con being significant. DISAGREE that we'd need to have
a new DO.

BR,

-Jari

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 09:57:20 +0100

New routing header type
   -----------------------
   
   The idea is to define Routing Header type 1 to be a constrained...

   Unknowns:
   
   Summary:
   ...
   
=> this statement is unfair because the new type (>= 2) is defined
only in order to get the proper behavior. BTW it assumes firewall
implementors are very lazy because to check the type of a RH is
very trivial when the existence of a RH is taken into account.
(note there is no publicly available IPv6 firewall with RH support)
Or the same kind of statements should be added to other alternatives
(all should be dealt with by firewalls).

Regards

---

From: Pekka Savola <[email-masked]>
Date: Wed, 13 Feb 2002 11:04:32 +0200 (EET)

> need to know something about the new DO, too.

Checking for RH type needs to be there..

-- 
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: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 10:14:37 +0100

=> look at my previous message for my motivation (the level of
the firewall concerns of the new RH type is not justified IMHO).

=> CAN LIVE WITH

   2. New RH Type 2 (AGREE/DISAGREE/CAN LIVE WITH)
   
=> AGREE

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 13 Feb 2002 07:15:21 -0800

Hello folks,

Here are my responses.

>    1. New Destination Option (AGREE/DISAGREE/CAN LIVE WITH)

Won't kill me.  I've already sent out quite a lot of motivation about
why I would not like this option.

>    2. New RH Type 2 (AGREE/DISAGREE/CAN LIVE WITH)

Agree, unless we can have RH type 0 instead which is easier.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 17:28:21 +0100

=> from the advanced API draft:

       /* Routing header */
       struct ip6_rthdr {
         uint8_t  ip6r_nxt;        /* next header */
         uint8_t  ip6r_len;        /* length in units of 8 octets */
         uint8_t  ip6r_type;       /* routing type */
         uint8_t  ip6r_segleft;    /* segments left */
           /* followed by routing type specific data */
       };

A firewall needs to look at ip6r_nxt (in order to process the next
header or the payload), at ip6r_len (in order to find the next header
or the payload). To stop there, i.e. not to look at ip6r_type, can
be considered as an insult to firewall programmers (note you can't
use the backward compatibility argument because no publicly available
IPv6 firewall deals with routing headers, i.e. do something else than
skip/ignore the header in payload chasing).

Regards

---

From: Pekka Savola <[email-masked]>
Date: Wed, 13 Feb 2002 18:58:34 +0200 (EET)

On Wed, 13 Feb 2002, Francis Dupont wrote:
> be considered as an insult to firewall programmers 

Code itself isn't difficult, but people may argue they don't want a every 
possible knob and detail to be checkable.. syntax for e.g. ip6fw(8) is 
rather complicated already :-)

>(note you can't

Incorrect: ip6fw can drop packets which contain RH (or any header type).

---

From: Alexandru Petrescu <[email-masked]>
Date: 13 Feb 2002 20:07:52 +0100

Erik Nordmark <[email-masked]> writes:
> The basis for comparing these [Routing Header] alternatives does not
> take into account issues relating to Mobile Routers or Mobile
> Networks because it isn't clear what the architecture will be for
> such things, to what extent they will use route optimization, and
> how such optimizations would be effected by the choices made for
> Mobile IPv6.

Hi Erik.  A monet architecture that source routes through the MR looks
very natural to me since IPv6 offers RH type 0.  But if Mobile IPv6
uses type 2 instead, then monet's will have to choose between either
type 0 or type 2.  Or eventually generate a new type 3 for monets.

At the same time, I guess the firewalling argument holds in the monet
environments too.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 20:45:46 +0100

=> the idea is to avoid this new knob.

   
=> yes, I look at the code (I checked with ipf) and the IPv4 option
filter code was translated into an IPv6 header filter code.
IMHO you may insult the authors, this is really laziness!
BTW it seems there will be a good majority for can live with ADA,
agree with RH type 2.

Thanks

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 18:21:29 +0100 (CET)

> BTW it seems there will be a good majority for can live with ADA,

This lazyness factor is part of my concern (that others disagree with).

There is a risk (how big it is can be debated) that IPv6 firewalls
assume that
	IPv6 routing headers = IPv4 source routing
and have a single on/off knob.

If we instead have ADA (and HOA) as DOs there are probably going to be
IPv6 firewalls that have a single on/off knob for IPv6 destination options.
But in that case the firewall implementors, as well as users, might be
a tad less likely to have it be turned off by default partly because
destination options is new compared to IPv4 and they might actually read 
something which says
	destination options is used e.g. for mobile IPv6
and think before disabling it.

  Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 14 Feb 2002 09:43:34 -0800

Hello Erik,

> and have a single on/off knob.

It seems pretty unlikely to me that IPv6 firewall designers,
would be on the one hand too lazy to check for another Routing
Header type, but at the same time so diligent as to check for
a wholly new destination option which is harder to detect,
since it would be a particular option within the Destination
Options header.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 18:55:40 +0100 (CET)

> since it would be a particular option within the Destination

I certainly didn't mean to imply that the firewall know about individual
destination options but I see my writing wasn't very exact.

I meant to say that the firewall knows about the destination options header
type and it might just have a single on/off knob for that header.
A firewall needs this and it probably needs to be able to look
at the header (tcp, udp, whatever) that comes after the destination
options header as well.

Does that make more sense?

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Sat, 16 Feb 2002 16:56:13 +0100

=> they can understand we introduce a new RH type for them and
be grateful?

=> up to this point I agree but the following deduction assumes
a matter of taste.

=> I am afraid we don't know and as we got no answer from a firewall
vendor I can only try to imagine what firewall implementors will like.
For the complexity of the implementations, RH type 2 is far easier
than destination option chasing.
 I don't believe in the firewall argument: if firewall implementors
understand the protocols they filter, all alternatives will be considered
as equivalent (and they are) and will receive the same kind of processing.
This is a bit different for firewall managers but or they are competent
and shall do the right thing independently of what we choose, or they
are not and they shall keep the default...

Regards