Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking)

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Mar 2002 12:01:11 +0100

I just tried putting together the format of the new extension
   header.

=> we have to agree FIRST if this is a final or a non-final header.
BTW "a new extension header" is ambiguous but more for non-final,
and IPsec selectors don't work with non-final.

   1. New Extension Header Order
   
              IPv6 header
              Hop-by-Hop Options header
              Destination Options header (1)
              Routing header
              Destination Options header (2)
              Fragment header
              Authentication header
              Encapsulating Security Payload header
              Mobility Options header
              Destination Options header (3)
              upper-layer header
   
   	   (1) for options to be processed by the first destination
                  that appears in the IPv6 Destination Address field
                  plus subsequent destinations listed in the Routing
                  header.
   
=> should make clearer than (1) implies there is a routing header.

Regards

[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 01 Mar 2002 11:25:17 -0800

Hi Francis

> and IPsec selectors don't work with non-final.

This is a very crucial question. This needs to be resolved before 
we can proceed with piggybacking. If transport protocol is strictly
speaking the only thing one interprets as possible for selector
protocol number, this enforces non-piggybacking.

But, if we can use mobility protocol besides transport protocol,
this would require an implementation clarification on how you
locate this protocol number by 2401.

If you look at 2401, it says how to locate a transport number
and describes a loop from which you bail out when you found
a transport number. It is not talking about what it returns
otherwise. Specifying we return it by position or by role
gives two ways of returning it affecting the fundamentals of
piggybacking rules. By position one could use current spec
this way. Now it says 'scan to the end or until you hit unknown
or ESP'. This would need clarification for mobility header: If
one reaches no next header when locating transport
protocol, use previous protocol if mobility protocol. That
would use the same byte you normally read for transport.

Returning a value by role changes some assumptions and may not
work so well. Mobility header can't be always transport because
you would not reach the actual transport in case you piggyback.
Defining it as unknown does kind of work but would have the
same problem from the exact transport search: you bail out
with the unknown value too early and do not see the actual
transport when you do piggyback.

So to have no change requirement to IPsec standards and minimal
implementation interpretation requirement would call returning
it by position. We could mandate this interpretation for this
header and it would have minimal or no effect to current
implementations. The interpretation should be placed in
MIPv6 spec as one sentence giving the extra exit condition
for 2461 transport protocol search loop. We could call it
is a transport protocol by position, that is, when it is the
last header in the packet.

In other words, when using mobility, IPsec implementations should
allow for the use of last non-no-next-header value in this case.

Vijay

---

From: Markku Savela <[email-masked]>
Date: Fri, 1 Mar 2002 22:00:09 +0200

Existing IPSEC combined with piggybagging will never work. Forget it!

It can be made to work only with big addition into policy selector
logic.

Consider a policy

   remote_port=25, protocol=TCP
      -> "use protection 1"

If you add piggybacking mobile IP to this, you have to define
additional selector

(2)   remote_port=25, protocol=TCP, "piggypack-selector"
     -> "use protection 2"

And to cater for traffic, that happens to go clear normally, you also
need

(3)   "piggypack-selector" -> "use protection 3"

In above, it doesn't matter whether we are using (a) new extension
header or (b) the original idea of destination option. In both cases
something new has to be added to the IPSEC selectors. [There is no way
any automatic algorithm can derive "protection 2" and "protection 1"
from the "protection 1". They must be explicitly told in policy!].

In (a), we need a selector mechanism that allows us to list a sequence
of headers or prototocols, which if present, match the selector
(e.g. instead of allowing just "transport protocol", we need a list of
protocols which may be transport or not).

     (2) MIP6-protocol-number TCP remote_port=25 -> ...
     (3) MIP6-protocol-number -> ...

In (b) we need a selector which has a protocol number with
subparameters

     (2) DOP(BU-option) TCP remote_port=25 -> ...
     (3) DOP(BU-option) -> ..

(Actually, if we go with this "subparameter-idea", the ports are just
parameters to the TCP protocol matcher. For ICMP, subparameters would
the type and code).

I was always uncomfortable with the selector talking about "transport
protocol". Just matching the given list of protocols (if any) with the
packet is much cleaner. Selector matches, if all listed protocols are
found matching while chasing the extension headers, before end of
chain is reached.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 02 Mar 2002 13:43:22 +0100

=> it is, RFC 2401 is not ambiguous this time:

      - Transport Layer Protocol: Obtained from the IPv4 "Protocol" or
        the IPv6 "Next Header" fields.  This may be an individual
        protocol number.  These packet fields may not contain the
        Transport Protocol due to the presence of IP extension headers,
        e.g., a Routing Header, AH, ESP, Fragmentation Header,
        Destination Options, Hop-by-hop options, etc.  Note that the
        Transport Protocol may not be available in the case of receipt
        of a packet with an ESP header, thus a value of "OPAQUE" SHOULD
        be supported.
        [REQUIRED for all implementations]

        NOTE: To locate the transport protocol, a system has to chain
        through the packet headers checking the "Protocol" or "Next
        Header" field until it encounters either one it recognizes as a
        transport protocol, or until it reaches one that isn't on its
        list of extension headers, or until it encounters an ESP header
        that renders the transport protocol opaque.

So piggy-backing and IPsec are essentially not compatible...
(the only hack which could work is to define a new no-next-header
dedicated to mobility).

=> and modify all the existing IPsec implementations? NO!

   otherwise.

=> your English and mine are not the same (:-).

   This would need clarification for mobility header:

=> no, you can not make the mobility header both final and non-final!

   Mobility header can't be always transport because
   you would not reach the actual transport in case you piggyback.

=> this is the problem:
 - for IPsec they MUST be final (aka transport)
 - for piggy-backing they MUST be non-final

   it by position.

=> NO!

=> I *strongly* object and if your "solution" is accepted by
the mobile-ip WG I'll ask the IESG to consult ipv6 and ipsec WGs.

Regards

PS: this problem was discussed many times in the last two years.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 02 Mar 2002 13:57:55 +0100

=> I agree but some of us seem to be ready to twist IPsec and IPv6...

=> basically what is needed is multi-protocol policy selector,
something which is hard to specified, hard to implement, likely
very inefficient and a nightmare to configure...
(PS: (a) is the real multi-protocol, (b) is even worse, this is
sub-parameter selector).

=> the ICMP example shows the subparameter-idea is very limited
because if it is easy to associate a service to port selectors,
this is not the case for ICMP type&code: for instance to give
a different protection to Neighbor Discovery you need 4 or 5 rules
(multiplied by source/destinations). Profiles should be better
but they need to be specified far before to be usable in the real world
between different implementations...

=> this is more powerful but too complex to handle and to use.
I am very uncomfortable with anything which can increase the IPsec
complexity, and this feeling seems to be shared by many people.

Thanks

---

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 02 Mar 2002 15:41:24 -0800

hi Markku and Francis,

Jari Malinen and I had sent a writeup to the design team describing
when you can piggyback and when you cant, when you have IPSec
turned on. We concluded that piggybacking is possible only in two
cases out of four. Heres a table from the writeup

           Table 1. Piggybacking with IPsec

	  IPSec policy for    IPSec policy
           Mobility header     for Payload    Can piggyback
      1.       no                 no              yes
      2.       no                 yes             yes
      3.       yes                no              no
      4.       yes                yes             no

 From the table, the sender does not piggyback at all whenever the
mobility extension header has an IPSec policy.

For handling the first two cases, there is no need for any change
to RFC 2401 or the existing IPSec implementations. Please let me
know if I am wrong.

One more thing, Markku, we are NOT asking for any changes to
RFC 2401. If anything that we propose requires changes to
IPSec, we will immediately drop the idea. Do not worry :)

I will address protecting Mobility extension header (in a
non-piggybacked packet) with IPSec in a separate mail. Looks
like we are interpreting RFC 2401 protocol selector scan
differently.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Sun, 03 Mar 2002 14:24:35 +0100

=> the mobility extension header can have an IPsec policy only
if it is final, i.e. not an "extension" header. Sorry but this
was discussed along the last two years: you are only losing your time.

=> the cases 1 and 2 have no "IPsec policy for Mobility header"
so they could work with current IPsec.

=> so drop the idea of an IPsec policy for a non-final header.

=> please don't twist IPsec in order to fill your needs.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Mar 2002 09:56:00 +0200

> transport when you do piggyback.

Yes, but defining the header as unknown would work for the
case where piggybacking is not used by the peers. It is only
the piggybacking case that needs special treatment. Given
that we have been assuming that the sender is responsible
for figuring out that there are no IPsec policies related
to the payload or the BU, this would seem to indicate that
we don't have a problem at all. That is,

   policy(MH) == pass AND policy(payload) == PASS

     IMPLIES

   policy(MH+paylod) == pass.

Now, if MH is unknown as far as RFC 2401 is concerned,
this means that IPsec will treat the MH+payload packet
is it would have treated the MH alone. But since the
action in both cases is pass, this does not seem to
have an impact.

Of course, in order to do the above, an implementation
that wants to use piggybacking needs to have an API
between MIPv6 and IPsec in order to figure out if
the policy lookups really return pass.

Conclusion (at this stage, without reading the rest
of the thread yet): separate MH header, unknown treatment
from RFC 2401, and optional piggybacking support would
seem to solve the issue.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Mar 2002 10:11:10 +0200

> very inefficient and a nightmare to configure...

I don't think this is the intention from anyone. I thought
most people had the opinion that we should NOT extend
IPsec or specify a complicated mechanism to cover both
BUs and payloads.

HOWEVER, what is being debated now is whether we could still
use piggybacking in *some* cases (and define it as optional
so not everyone has to implement it if they don't want to,
and do it in a separate RFC so the little details that have
be done right don't delay the main MIPv6 RFC). The basic
approach is checking from MIPv6 code that there are no
"troublesome" policies, and proceeding with piggybacking
only if there aren't.

(Francis, could you take a look at my previous e-mail
to the list and comment whether the analysis is right?
I know you have a lot of experience on this particular
issue so I'd appreciate your comments on it.)

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Mar 2002 10:14:29 +0200

>           Mobility header     for Payload    Can piggyback

Isn't line 2 incorrect? If there's a policy for the
payload, the the 'MH is unknown for RFC 2401' approach
doesn't work anymore, and the packet would go unprotected.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 04 Mar 2002 10:17:26 +0100

=> don't forget this API can not be assumed to exist.

=> I believe you haven't measured the consequences:
 - IPsec support is mandatory for all compliant IPv6 implementations
 - the API is not available or not used in many implementations
 - so stupid but immediate solution is to disable piggy-backing
   support on every Mobile IPv6 implementations on platforms
   which support IPsec, i.e. on at least all compliant platforms.
In fact you give the choice to piggy-backing supporters between to
disable piggy-backing and/or to wait for the API. I am not a
piggy-backing supporter but this is so unfair that I shan't follow you
on this path.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 04 Mar 2002 10:34:09 +0100

=> so we agree that for IPsec a terminal (aka final) "protocol"
is required.

=> I have personally no objection to make piggy-backing
unfeasible but we know we'll never reach a consensus this way.

=> I believe I have an idea which can be accepted by IPsec
and piggy-backing folks...

Thanks

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Mar 2002 12:09:41 +0200

> => don't forget this API can not be assumed to exist.

I have not forgotten this. That is precisely my
point about the piggybacking thing being optional
and preferably also in a separate document. So, those
who *do* want to take cost can do so, but don't have
to bother other folks.

>  - the API is not available or not used in many implementations

So, zero your bit mask and don't worry about it...

> piggy-backing supporter but this is so unfair that I shan't follow you

Well, I'm really not a fan of piggybacking either but I'm trying
to find a way for this WG to move ahead. It seems at least that
we agree that the choices are:

1. No piggybacking.
2. Piggybacking in a special case, with an API (optional)
(3. Modify IPsec is not an option)

I think you favor option 1. I'm between options 1 and 2,
but I have this feeling that the WG could close this issue
and move forward if we picked 2. That does not seem to
cost anything to folks who don't want piggyback.

After this explanation, would you Francis be prepared to
accept also option 2, or do you think we should try to
find consensus for option 1?

Jari

---

From: Markku Savela <[email-masked]>
Date: Mon, 4 Mar 2002 12:38:32 +0200

Apparently alternatives are

  1) no piggyback, a new TRANSPORT level protocol number for BU

or, controversial (?)

  2) back to original Mobile IPv6 draft as is, with clarification that
     accepting certain options (like BU) may be configured to require
     that packet was protected by IPSEC (similar to neigbour
     discovery).

     Accompanied with strong "SHOULD" for requiring that all
     communcations are protected with sufficient level IPSEC (whether
     BU is present/piggybacked or not).

Neighbor discovery RFC 2461 seems to "get away" with such wording
easily, its left up to policies whether IPSEC is used or not. (Of
course, in mobile IP IPSEC is more important. Though, ND with a set of
manual SA's would be nice for building "virtual private WLAN" :-)

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 04 Mar 2002 23:29:53 -0800

That never occurred to me. (using MH is unknown for RFC 2401
approach). I dont think I want to use that method. Will get
back to this later... Connectathon is going on. sorry.....

Vijay