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

From: [email-masked]
Date: Fri, 25 Jan 2002 16:28:05 -0600

I agree and am in favor of the DTs recommendation for replacing the
RH with a new DO.

-Basavaraj

>  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: Sat, 26 Jan 2002 15:28:03 +0100

=> another argument about a new Destination Option:
 - if we don't specify where to put the DO we'll get a mess
 - if we specify the DO must be before any IPsec header (same
   case than current HAO) we have no difference with a new RH type,
   only more complexity...
 - if we specify the DO must be after any IPsec header in order
   to be able to protect it using ESP for instance, we'll mess
   the SADB lookup which is done using the destination address.
IMHO we should only conclude we'd like a new mechanism and let
the choice to the IPv6 WG (this will give us more time for other
points too).

Regards

[email-masked]

PS: no mechanism has an advantage for efficiency, all are 24 byte long.

---

From: "Jari T. Malinen" <[email-masked]>
Date: Sat, 26 Jan 2002 17:57:57 -0800

>  - if we don't specify where to put the DO we'll get a mess

Agreed, the spec needs to tell where it is.

>    case than current HAO) we have no difference with a new RH type,

Hmm.. both use a known header type and are resolved in the next
octet (RH type or DO type). For packet input these seem equally
complex. If it really is the case FW admins do not want any RHs
in their domains, it may be administratively simpler let them
drop RHs and use another known header. Then they do not need
to worry so much details of this part of IPv6 :-) A downside
is that this is then a confession RHs cannot be used too much.
If the FW admin constraint is considered important, I tend to
favor the use of a DO near the place of current HAO.

> PS: no mechanism has an advantage for efficiency, all are 24 byte long.

Agreed.

BR,

-Jari

---

From: "Jari T. Malinen" <[email-masked]>
Date: Sat, 26 Jan 2002 20:25:01 -0800

> > PS: no mechanism has an advantage for efficiency, all are 24 byte long.

..that there should be no significant difference in 
protocol message efficiency.

BR,

-Jari

---

From: Francis Dupont <[email-masked]>
Date: Sun, 27 Jan 2002 16:00:20 +0100

drop RHs and use another known header.

=> in fact you'll force firewalls to scan DOs... I prefer to use
another RH type in order to make the decision easy (IMHO this
feature is a routing one so a RH has to be used).
 I have some arguments in favour of the routing basis of this feature:
 - the first one is the special case of a tunnel, i.e. this feature
  is an optimization of a tunnel where the inner and the outer sources
  are the same (so only destination addresses are needed).
 - if the end of the tunnel is a mobile router, the final destination
  is behind the router so a DO doesn't work (the missing thing is
  the capacity of a RH to advance from an intermediate destination to
  the next one).
 - if you implement ingress filtering based on unicast RPF, you have
  to deal with two cases:
   * internal forwarded packets (M_LOOP flag in KAME) which should be
    always accepted.
   * for other packets you take the source, compute the route to it
    and verify the route is through the input interface of the packet.
    The source is in the IPv6 header if there is no routing header:
    with a routing header the source is the last intermediate router
    (the segleft + 1 field when there is one).
To refuse to accept this routing basis should give only confusion and
extra complexity.

Regards

---

From: "Jari T. Malinen" <[email-masked]>
Date: Sun, 27 Jan 2002 22:53:45 -0800

Francis Dupont wrote:
>    >    case than current HAO) we have no difference with a new RH 
>    >    only more complexity...
> 
> => in fact you'll force firewalls to scan DOs...

Wouldn't this depend on whether there is a reason to block
MIPv6-specific traffic, which we hopefully after all these
changes shouldn't have? A Destination Header, on the other
hand, can already be skipped. So I suspect this does not
automatically force this scanning, one may want to do it
for other reasons, though. And, since a HAO is a DO, it would
make the situation "symmetric". Also, the discussions demonstrate
how many subtle issues there are, hence a mobility-specific
"end node tunneling" option should isolate the mobility case from
unforeseen problems (security etc) present in options that
have more generic uses. Mobility-specific extra limitations
to processing could be added in the future without jeopardizing
other uses or adding semantical confusion. It's a compromise.

> I prefer to use
>   is an optimization of a tunnel where the inner and the outer
>   sources are the same (so only destination addresses are needed).

Seems like it, yes, though this might be considered a semantical
difference rather than something where the actual format matters.

>  - if the end of the tunnel is a mobile router, the final
>   destination is behind the router so a DO doesn't work (the
>   missing thing is the capacity of a RH to advance from an
>   intermediate destination to the next one).

I agree here but want to mention that this applies only to a
route-optimized or triangle mobile router case, another
way of doing it without this affecting is discussed in a draft,
http://search.ietf.org/internet-drafts/draft-kniveton-mobrtr-00.txt
with the use of bidirectional tunneling. If MN is the initiator
of connection, it can even with the current MIPv6 draft use bidir
tunneling, a MN is not mandated to insert HAOs. So DO is
not a showstopper for mobile routers, in some cases it may be
a limitation. It is, however, not well understood, if RH-based
mobile routing to middle nodes securitywise is desired. But you
have a point here, "end node tunneling" causes a limitation to
some speculative future scenarios of optimized routing.

>  - if you implement ingress filtering based on unicast RPF, you
>   have to deal with two cases:
>    * internal forwarded packets (M_LOOP flag in KAME) which should
>      be always accepted.
>     with a routing header the source is the last intermediate
>     router (the segleft + 1 field when there is one).
> To refuse to accept this routing basis should give only confusion
> and extra complexity.

I agree there is a routing basis and that it is a compromise
with a possibility for some extra confusion both ways. To not go
beyond this I just conclude that I do not have a strong position
either way, both RH type 2 and new DO have their pros and cons
and both seem doable.

BR,

-Jari

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 28 Jan 2002 09:20:12 -0800

Hello Basavaraj,

While I think a new Destination Option will work fine,
I also think the Routing Header would work fine.  If protocol
cannot be built using the Routing Header, then it should
be removed from the IPv6 protocol specification.

It is a huge waste of time for us to build according to
the IPv6 specification, only to be told later that the
specs were "just kidding" -- e.g., because of firewall
administrative bias.

Regards,
Charlie P.

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Mon, 28 Jan 2002 18:45:09 +0100

Hi,

just one question : are there others cases (eg. protocols) where RH are used
?

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 Charles E.
> Perkins
> Envoye : lundi 28 janvier 2002 18:20
> A : Basavaraj Patil (NTC/Dallas)
> Cc : [email-masked]
> Objet : Re: [mobile-ip] Routing headers: design team recommendation
>
>
> Hello Basavaraj,
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 28 Jan 2002 10:21:01 -0800

I thought it was pretty obvious. the new destination option
has to be before the fragment header and after the routing 
header. it makes no sense having it after the fragment header
(if ever fragmentation is done for a packet).

Vijay

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Mon, 28 Jan 2002 19:47:53 +0100

Excuse me but I think I missed an episode :
1. at first, RH is said to be dangerous [Why not ...]
2. after, one idea to replace RH functionality is to create a new DO [Why
not ...]
3. and now, it is proposed to place this new DO between the fragment header
and the ... RH [!?!]

Regards.

JMC.

> [mailto:[email-masked]]De la part de Vijay
> Devarapalli
> Envoye : lundi 28 janvier 2002 19:21
> A : [email-masked]
> Objet : Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team
> recommendation
>
>

---

From: "Jari T. Malinen" <[email-masked]>
Date: Mon, 28 Jan 2002 11:20:23 -0800

Jean,

> 3. and now, it is proposed to place this new DO between the fragment header

Seems a bit funny, doesn't it. However, what does not meet the
eye are the ordering rules for a packet as compared to what
is actually in the packet. RH issue seems to be rather thoroughly
analyzed in the security recommendations..

BR,

-Jari

---

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

> be removed from the IPv6 protocol specification.

Charlie,

I think the routing header works fine for doing source routing i.e. specifying
the addresses for different routers (or sets of routers using anycast
addresses) to indicate the path that packets will take.

While the mechanism could be used to specify multiple IP addresses assigned
to the same node as done in MIPv6, this overloading might have some issues
as the writeup points out.

So I don't see what this has to due with the usefulness of the routing header
in general.

> specs were "just kidding" -- e.g., because of firewall

Your wording makes it look like you think that this is some proclamation
from a higher authority, which is not the case.

The email I sent was trying to capture the issues that have been discussed
in the WG for some time to see if there is concensus about the direction
of the thinking in the design team. Thus there isn't an "us" and "them" here.
The folks on the design team as well as the working group want to see
MIPv6 finished and deployed. If we identify deployment concerns around
firewalls it is better to resolve those sooner rather than later.

  Erik

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Tue, 29 Jan 2002 15:12:38 +0100

Hi,

another question : is RH case really a MIPv6 problem or an IPv6 problem ?

Regards.
JMC.

> [mailto:[email-masked]]De la part de Jari T.
> Malinen
> Envoye : lundi 28 janvier 2002 20:20

---

From: Francis Dupont <[email-masked]>
Date: Wed, 30 Jan 2002 09:47:31 +0100

just one question : are there others cases (eg. protocols) where RH
   are used ?
   
=> two examples:
 - (theory) the selection of an intermediate ISP, i.e. to go from
   the West coast to the East coast you choose to go through Chicago,
   Saint-Louis, Memphis or New Orleans by a RH with the subnet anycast
   address of the selected ISP.
 - (practice) traceroute6 -g (there are two (not three :-) standard
   applications with IPv6 RH support: traceroute6 and telnet (in order
   to understand the syntax for telnet, you have to read (and sometimes
   to fix) the source.

Regards

PS: the first usage is potentially critical (BTW is this kind of features
mandatory in the USA since ISPs are regulated as telecom operators?)

---

From: Francis Dupont <[email-masked]>
Date: Wed, 30 Jan 2002 11:01:21 +0100

=> I agree but this means there is no difference from the IPsec
point of view between a new DO and a new RH type (i.e. this
withdraws a possible argument in favour of a new DO).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 30 Jan 2002 12:08:55 +0100

=> not exactly, RH is said to need a careful usage so MIPv6 use and
other uses interfere in careful usage requirements (i.e. if we fix it
for MIPv6 we impede other uses).

=> there are 4 propositions, one is a new DO.

=> there is an issue about the position of the DO header with the DO...
This shows a new RH type is a good alternative to a new DO.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 31 Jan 2002 18:03:23 +0100 (CET)

>    case than current HAO) we have no difference with a new RH type,

If the ADA as well as the HAO are destination options before any
IPsec header, why does this add complexity over just having the
HAO before the IPsec header (and e.g. RH type 1 instead of ADA).

If you point is about comparing the two approaches:
 - both addresses as destination options (HOA and ADA)
 - both addresses using Deering/Zill tunneling
then I understand that the latter is simpler when it comes to IPsec
interaction.

But if HAO remains a destination option it seems like there would be less
complexity if ADA is also a destination option.
What am I missing?

>    the SADB lookup which is done using the destination address.

If we go the destination options path presumably we want HAO and ADA
work the same way (they are really inverses of eachother - somebody
suggested naming them Alternate Source Address and Alternate Destination
Address respectively).

> the choice to the IPv6 WG (this will give us more time for other

In the interest of time I'm concerned about getting the technical parts 
well specified  so I'll ignore all comments that say that certain
things should be done in other WGs :-)

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 31 Jan 2002 18:26:39 +0100 (CET)

>   are the same (so only destination addresses are needed).

The fact that it is a special case of a tunnel clearly argues for
IPv6_NO_SRC (but there might be other reasons for that being undesirable).

But I don't see how this leads to RH as being a good alternative.
A destination options header with either a HOA, ADA, or both options
looks a lot more like Deering/Zill tunneling than HOA, RH, or both.

The "symmetric" application of RH to the complete space of HOA and ADA
would just use RH e.g. in this fashion:
Packet sent from CN to MN
	src = CN
	dst = CoA
	rh segleft=1, addrs = HoA
Packet sent from MN to CN
	src = HoA
	dst = CN
	rh segleft=0, addrs = CoA
	Thus conceptually this packet was sent by HoA source routed via CoA
	to CN. The source route was processed by the MN decrementing segleft
	to zero and swapping the addresses.
Packet sent between MN1 and MN2
	src = HoA1
	dst = CoA2
	rh segleft=1, addrs = CoA1, HoA2
	Thus conceptually this packet was sent from HoA1 via CoA1, CoA2 to HoA2
	with the sending MN1 advacing the source route by one.

NOTE: The above doesn't work with ingress filtering at all hence
it is completely academic.
But it seems like it would be the conceptually clean way 
to apply RH in this space.

On to more practical matters.

Do people see strong arguments for/against handling the "source HoA" and the
destination "HoA" using the same mechanism?

For instance, using HAO/ADA destination options for both is using the same
mechanism. Also using Deering/Zill tunneling for both is the same mechanism.
But using destination options for HAO and RH for the other are different 
mechanisms.
Does it make any difference e.g. in IPsec related complexity?

   Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 31 Jan 2002 10:38:12 -0800

> destination "HoA" using the same mechanism?

Perhaps they are essentially different problems.

The Home Address Option is not used for routing.  It's used
to identify the mobile node, when the default use of the routable
IP address would lead to the "wrong answer".

The Routing Header is used for routing.  It provides an address
(namely, the care-of address) that has to be used for routing, but
that at the same time should be made invisible to any higher-level
protocols.

One shouldn't impose symmetry on the handling of addresses that
are to be used for different purposes entirely.

> Does it make any difference e.g. in IPsec related complexity?

I think it will be better to entirely remove the authentication
of the Binding Update from the domain of IPsec.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 31 Jan 2002 19:25:52 +0100

=> this is less complex to add 2 to the RH type than to specify
a new DO. The argument was about ADA or RH with IPsec: there is
no difference so IPsec cannot be used in order to decide between them.

=> if we go to a symmetric solution (which is not the case of new RH),
I agree these will be the two alternatives. But I am far from to be
convinced that Deering/Zill tunneling is simpler when it comes
with IPsec, I am afraid we fall again into the "transport mode applied
to a tunnel is *not* tunnel mode" (issue raised but not solved at the
last IETF meeting, just wait a bit to get Mike Thomas' reaction :-).

=> this is the symmetric argument: IMHO it is weak.

   What am I missing?
   
=> context: does IPsec consideration make a difference?

   
=> you are free to waste your time how you like (:-).

Regards   

PS: the complexity argument is a real one: what is the time needed
to add 2 to the type in the RH code?

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 31 Jan 2002 14:11:27 -0800

Hello again folks,

I made a totally irrelevant statement, which I would like
to point out was irrelevant in context.

Discussing the choices for replacing Routing Headers,

> of the Binding Update from the domain of IPsec.

which has zero bearing on the discussion.  Of course, any
solution which is selected for inserting the care-of
address as a routing point for packets destined for the
mobile node has to also be compatible with IPsec solutions
for protecting the payload.

Regards,
Charlie P.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 31 Jan 2002 16:15:47 -0800

> Does it make any difference e.g. in IPsec related complexity?

as far as I know, no difference at all.

Vijay