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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 17 Aug 2001 17:52:14 +0200

>    
>    2. There are some issues to be resolved if IPsec is to be used. 
>        Mainly this is related to the recent discussions on IPsec selectors
>        and their granularity. 
>    
> => there are two extra issues:
>  - the authentication/authorization problem and the lack of a global PKI
>    (not a real IPsec problem)
>  - the cost/performance of using IPsec (this seems more a IKE problem
>    than a general IPsec problem IMHO but do we agree about that?)
> 
	=> I do.

>    Before London, we agreed that (2) can be solved in 2 different ways:
>    
>       A. Use a new Ext Header value for MIPv6 BUs. This will not 
>           involve any modifications to the IPsec implementations.
>       
> => note this extension header must be final (and of course UDP with
> a well known port does the job in 256 time cheaper way :-).
> 
	=> Sure. I was just trying to minimise the impct on MIPv6 
	  implementations. Since everything is already Kernel based.

	Thanks,
	Hesham

>    Of course both A and B rely on eliminating piggybacking of the BUs. 
>    
> => Yeh!
> 
>    Problem (1) is addressed by several proposals. Needless to say that
>    1 and 2 are not dependant on each other (or need not be).
>    
>    So the questions that should be answered IMO are:
>    
>    1. Do we want to completely disallow the use of IKE ?
>    
> => no, if we have already a phase 1 it will be stupid to do
> something different than a phase 2 to get SAs.
> 
>    2. Do we want to completely disallow the use of IPsec ?
>    
> => please don't!
> 
>    I guess based on the WG concensus this should be reflected
>    in the draft so we can get on with our implementations.
>    
>    What do people think ?
>    
> => see above.
> 
>    My answer to both questions is No. I do believe that there will
>    be cases where strong authentication will be required. Since 
>    there are ways of allowing the use of both IKE (as an option)
>    and IPsec (whether its AH or ESP) then I don't see why we can't
>    reuse them. 
>    
> => I agree.
> 
> Regards
> 
> [email-masked]

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sat, 18 Aug 2001 18:10:48 +0200

> > 1. Relying on IKE only as a key exchange mechanism is not 
> >    acceptable (This was discussed several times and I think we 
> >    all agree on this assumption)
> 
> I think the placement of "only" above can be a source of confusion -
> IKE is only ("nothing but") a key exchange mechanism as far as I know.
> 
> Did you really mean
> 	Relying on IKE as the only key exchange mechanism used to secure
> 	Mobile IPv6 is not acceptable ...
> 
	=> That's what I meant, thanks. 

> Presumably these questions are solely in the context of
> securing MIPv6 or perhaps just securing the BUs, or perhaps just securing
> the BUs with CNs?.
> 
	=> Yes only for securing BUs. I wasn't intending to segregate
	the HA BU from the CN BU. For instance using a MIPv6-specific 
	mechanism to replace  IKE can still utilise IPsec for securing 
	the BUs. 

> I can see folks wanting to use IKE and IPsec to build VPNs to mobile nodes.
> Thus I think we need more context in order for folks to agree
> what the questions mean.
> 
	=> Right, so what I meant to say was that :
	Should we disallow IKE from being "optionally" used ?
	Should we disallow the use of IPsec at all ? 

	An answer of No to the second question would imply that 
	IPsec will be THE mechanism used for authenticating BUs
	with any other key exchange mechanism (IKE, BAKE, HA cookies .....etc)

	Please note that there is no distinction between the HA and CN BUs
	above. For example you can still use IKE with another CN
	(if you can establish an SA). It could be a CN that you already 
	know would require strong authentication (eg. a server at your corporate
	or at your home network).

	Hesham

---

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

> 	  implementations. Since everything is already Kernel based.

Just a note that it would not be impossible to build UDP based protocols in
kernel. But why does the Mobile IP signaling _need_ to be in the kernel in
the first place?

> >    Of course both A and B rely on eliminating piggybacking 

This is not true at all. There is always the case when there is no IPsec SA
required for the payload itself and there would be absolutely no harm done
by piggybacking. Only when the payload and the BU need different SAs could
piggybacking not be done.

	Jarno

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 21 Aug 2001 10:23:21 +0200

> kernel. But why does the Mobile IP signaling _need_ to be in the kernel in
	=> It's not a matter of why it needs to be in the kernel, it already _is_ 
	in the kernel. It's quite natural to have it in the kernel if the signalling
	does not require any upper layer protocols. At least that's how 
	the implementations I saw and worked with do it.

> piggybacking not be done.
	=> Yes but you can't design a standard that only works sometimes. 

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 21 Aug 2001 13:35:26 +0200

> 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
> 
> If the spec allowed for this, would it be broken in some way?
> 
> Sure this is a performance optimization only, and the degree of the benefit
> depends heavily on the type of L2's in both ends, feature interaction with
> HC, etc., but if done right there is nothing that would make the standard
> "only work sometimes". It is quite customary that standards have options
> that are not always used.
> 
	=> The question is whether this complexity you mention above
	(L2 interaction, HC implications, Path MTU ....etc) are worth 
	the hassles. There is no foreseen benefit really if you're
	using ROHC for example. Do you think the perceived gain 
	actually outweighs the processing headache ?
	If it does then what you're suggesting would make a lot of sense.

	Hesham

---

From: [email-masked]
Date: Thu, 23 Aug 2001 00:16:03 +0300

Wolfgang wrote:
> 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, ...

The assumption for this discussion has been that the SPD entries for the BU
and for the payload can be separately identified (with the new next header
value). From this perspective the problem you describe does not arise.

	Jarno

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 23 Aug 2001 00:13:05 +0200

> All that complexity of figuring out when it is worthwhile and possible to
> piggyback lies on the engineer implementing piggybacking. If you rather not
> bother, then do not piggyback. There is no added complexity for the
> recipient.
> 
	=> The only question unanswered (at least to me) is the one 
	Erik posted on the topic (TCP connections expecting all 
	packets to be protected). Other than that what you're saying
	makes sense.

> Also, if you'd *know* piggybacking has absolutely no benefit, why'd you tell
> your competitors that :-?
> 
	=> Don't worry I won't say everyting :)
	I just want to see  good spec become an RFC.

	Hesham

---

From: [email-masked]
Date: Thu, 23 Aug 2001 02:57:43 +0300

Hesham,

As you see from my reply to Erik's message, there may be something in there
relating to the IPsec selectors for Next Headers other than transport
protocols. I don't know if that is a show-stopper for piggybacking or not.

What do you think?

	Jarno

> -----Original Message-----
> From: Hesham Soliman (ERA) [mailto:[email-masked]]
> Sent: 23. elokuuta 2001 1:13
> To: [email-masked]'
> Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus 
> 
>

---

From: [email-masked]
Date: Thu, 23 Aug 2001 18:13:43 +0300

Erik wrote:
> > There still is the case where the BU has it's own, embedded
authentication
> > mechanism (non-IPsec). Packets with those could also carry regular
transport
> > messages and associated IPsec headers for their protection. In this case
I
> > can't see any additional complexity from piggybacking for the recipient.
> 
> Agreed from the perspective of IPsec.
> (There are still PMTU, ROHC? issues etc with piggybacking.)
> 

These issues burden the sender choosing to piggyback, not the innocent
receiver.

	Jarno

---

From: [email-masked]
Date: Thu, 23 Aug 2001 20:22:05 +0300

Michael,

As long as Mobile IPv6 is implemented in the L3 (IP option) headers, there
is nothing extra receivers need to do to *accept* piggybacking, it just
falls out naturally. Actually, you need more text in the spec to disallow
piggybacking. And if this is done, why to keep Mobile IPv6 at L3?

(Kernel/user space considerations should be out of scope for IETF)

It seems that IF IPsec is used to protect the BU, BU would really need to be
implemented as a transport protocol, or on top of some existing transport
protocol. In this case piggybacking would indeed require some additional
support (ref. Erik's recent mail), which I do not support.

On the other hand, if the mechanism in draft -14 is used for BU protection,
piggybacking falls out naturally again.

Actually the discussion should be about BU piggybacking in the e.g. TCP
packet, not the other way around. This way it is easy to see that DSCP, flow
label, etc. should NOT be changed by inclusion of the BU.

If the BU needs some specific diffserv treatment, then it should be sent out
by itself.

	Jarno

> From: ext Michael Thomas [mailto:[email-masked]]
> Sent: 23. elokuuta 2001 19:56
> To: [email-masked]
> [email-masked] writes:
>  > Hesham wrote:
>  > > > 
>    That's not completely true: if there is a requirement
>    that *all* receivers accept piggybacking, then they
>    share the burden. 
> 
>  > Seriously, you should piggyback only if you think it's 
> worth the effort.
> 
>    I think we have an inversion of priorities going on
>    here (and throughout the rest of the IETF, for that
>    matter). The question should not be framed as
>    if it's not a big deal, throw it in, it should
>    be framed as why do we absolutely, positively
>    _have_ to have this feature. The net is getting
>    far too complicated, and the law of unintended
>    consequences brought to the fore far too often.
> 
>    It's already been shown that there's a great
>    deal of possibility for unintended consequences
>    with piggybacking -- consequences I'll add
>    which are quite possible regardless of whether
>    IPsec is used or not. Unless somebody can show
>    some concrete wins which cannot be achieved in
>    any other way than L3 piggybacking, we should
>    be prudent and defer that discussion for
>    another day when we know more.
> 
> 	       Mike
>