Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus

From: [email-masked]
Date: Tue, 21 Aug 2001 16:10:38 +0300

Wolfgang wrote:
> > Jarno wrote:
> > The scenario is: 
> > 
> > - Need to send a BU to a CN
> >  - If there is an outgoing packet to the CN in a queue, and 
> >   - the packet is not associated with any SA
> >   - then can piggyback the BU with the packet in the queue
> >  - else send BU as a separate packet
> 
> But what will happen if at a later time it becomes necessary to have 
> a SA also for the payload? IPSec will detect, that there is already 
> one (with no idea, that it has been established for Mobile IP BUs), 
> which probably will not match the security policy for the payload. So 
> should the Mobile IP SA be overridden? How do you inform Mobile IP 
> about that? 
> 

The decision whether to piggyback or to send a separate packet must be done
separately for each signaling message sent by mobile IP, so I do not
understand what you mean with "at a later time".

What the actual implementation solution for resolving the possible race
condition between two SPD entries (one for Mobile IP, other for the payload)
is not important (for this discussion), and does not need to be
standardized. It suffices to state that (for example):

"Mobile IP header (TBD) may be followed by transport headers only if the
transport protocol message can be sent with the Security Association used
for protecting Mobile IP itself."

If you do not want to find a solution how to do this, never piggyback. It is
a tradeoff with possible complexity of checking the SPD in the right places,
and getting the efficiency of piggybacking. But this tradeoff should have no
interoperability consequences, so there is no need for standardizing
anything new for this.

> You won't have such problems without piggybacking.
> 

Again, this issue can be left to the implementers of to decide. No-one is
forced to piggyback. Reception of piggybacked transport PDU should happen
with current standards.

Or am I still missing something? What adverse effects you see with
piggybacking, with the assumption that the originating host knows when it
can/not piggyback?

	Jarno

---

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Aug 2001 17:01:33 +0300

It does seem that Jarno's scheme allows
piggybacking where "security allows it".
Nice idea.

Then I would also like to comment on Hesham's
original questions, do you want to completely
disallow IPsec and IKE, or do you want to
use them in some situations. Personally, I
think there are situations where we'd like
to use IPsec/IKE, and to have them protect
also the Mobile IP signalling. Of course you
have to be able to use also the PKI-less, weak
authentication in the global Internet.

Finally, I would also like to note that the solution space
for BU protection is more fine grained than "Use
IPsec for everything" and "Don't Use IPsec At All":

- Application specific protection, i.e. the use of the
  mechanism defined in the -14 version of the v6 draft.

- Existing IPsec AH with a new next header value for BUs.
  In this alternative we can use the current versions
  of IPsec AH and IP Security Architecture since BUs
  are not piggybacked to other packets. It may be possible
  to use this with Jarno's idea, allowing piggybacking
  if security isn't needed.

- IPsec AH with policy extensions. Certain extensions to
  the current requirements for security policy data bases 
  and SA selectors are needed in order to protect BUs that
  are embedded in the Destinations Options header of packets
  possibly containing also other payloads.

- Application specific protection with optional, additional
  IPsec protection. For instance, we use the -14 mechanism
  and the weak authentication  in  all  situations,  but
  apply additional also IPsec and IKE where a suitable PKI
  exists, such as in corporations. This application may
  affect simply just all packets, in which case the policy
  granularity issues are not a concern. Standard IPsec
  applies here also in this case.

Frankly, I'm not quite sure which of these alternatives
I would prefer. I kind of like the second alternative,
though the first isn't bad either. Fourth would also
be a good option, and I'm not sure people have discussed
it yet much. I don't particularly like the third option.

In all of these options, we should better document exactly
how we can do the things we want, and what the limitations
are. For instance, in the first alternative we should make
crystal clear to everyone that we won't be doing strong
authentication ever, unless the weak authentication protocols
are extended to support also strong authentication [which
would be a bad idea in my opinion]. In the fourth alternative
we need a clear section in the spec that tells people an
additional layer of security can be run in certain situations,
and exactly how.

Jari

---

From: [email-masked]
Date: Wed, 22 Aug 2001 13:27:26 +0000

> understand what you mean with "at a later time".

It's clear that a piggyback decision is done on a per-packet basis, 
but that's not what I addressed. My concern has been that sending BU 
piggybacked means that the SA to be established for this packet will 
address the security issues for the BU and the payload in the packet. 
As this SA will not be created just for one packet's lifetime, but 
last for a longer period, my comment has been that you may get into 
trouble if at a later time (when this SA is still valid) payload data 
has to be exchanged between MN and CN, which require the 
establishment of a different (from the security properties) SA. Will 
you then override the existing one, and if so will you also use the 
new one for future BUs, ... . As Erik already mentioned in an other 
email, this could easily become a source for interoperability 
problems.

> for protecting Mobile IP itself."

Concerning the use of a new extension header for MIP BUs I would 
be in favor with this approach if it provides the necessary 
granularity to differ between BUs and payload exchanged between MN 
and CN from a security perspective (using existing IPSec selectors). 
Reading the IPSec selectors chapter of the IPSec architecture (RFC 
2401) I'm not quite sure about that, as it contains: 

"     - 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.  "

You could interpret this in a way, that the granularity of the IPSec 
selectors concerning the "Next Header" fields is only used for 
transport layer protocols (e.g. TCP, UDP, ...) and not for other 
"Next Header" fields (Routing, Fragment, ..., or a possible new 
MIP BU). If this interpretation is correct, what benefits from the 
security perspective will bring an new "Next Header" field for the 
BU? Maybe some IPSec gurus could correct me.

> piggybacking, with the assumption that the originating host knows when it
Wolfgang