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

From: [email-masked]
Date: Thu, 23 Aug 2001 17:10:04 +0300

Erik wrote:
> 
> > You mean that the recipient's IPsec implementation is 
> creating new SPD
> > entries dynamically and implicitly as the side effect of a 
> IPsec envelope
> > used with the TCP SYN packet?
> 
> I think that is what I'm saying (I've though more in terms of what
> the implementation does than how this fits with the SPD concept).
> I think an example is that the SPD initially has a matching entry
> (e.g. just for TCP + the destination port) allowing IPsec or no IPsec.
> But when a new connection is created an SPD entry is created 
> which matches
> just that connection and the entry constrains the policy to be what
> was used on the SYN.
> 
> I don't know if such a scheme is discussed in RFC2401 but it 
> seems useful
> since it allows one to build servers where the client can 
> choose whether
> or not it wants to use ipsec i.e. there is less coordination needed.
> 

From my reading it does not seem to be in the 2401, I don't know if it is
somewhere else. By 2401 a SPD entry either requires IPsec or not (or tells
to drop the matching packet).

> > If a selector for Mobile IP Next Header is defined, and the 
> SA used for
> > reception of the packet specifies this selector (in which 
> case it would NOT
> > contain a selector for TCP), there is no reason for the 
> IPsec implementation
> > to create any SPD entries for the piggybacked TCP session. 
> 
> So how would you solve the above issue in that case?
>

If the selector in the SA specifies the Mobile IP Next Header value, the
implementation would have to assume that the TCP message arrived without
IPsec protection. If the source intended to use IPsec for TCP protection, it
would have not piggybacked the two messages in same packet, but separate
packets with separate SAs.
 
> > But there seems to be a related issue: the recipient should 
> be able to check
> > that the piggybacked TCP packet can indeed get in without 
> IPsec protection.
> > 
[...]
> 
> Seems like things are simpler without piggybacking.
> 

Note that all this discussion has been conditional on the assumption of
using IPsec for BU protection with a new Next Header value definition for
IPsec (either as a transport selector or something new). Now it seems to me
that with this assumption, piggybacking can not be used, unless IPsec goes
and defines the behavior I described for "in-between" next headers.

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.

Can we agree on these conclusions?

	Jarno

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Aug 2001 16:24:24 +0200 (CEST)

> and defines the behavior I described for "in-between" next headers.

My issue appears whether the BU remains as a destination option or
is in its own extension header.
But making it a separate header makes it easier to see these aspects of
the interaction with the SPD.
 
> 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.)

   Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 23 Aug 2001 10:24:46 -0700

hi,

> (There are still PMTU, ROHC? issues etc with piggybacking.)

whats are the PMTU issues? you check the data packet. if you 
can add the BU option to the packet without exceeding the
PMTU, you piggyback. otherwise you dont. you send the BU
as a separate packet. only the sender has to do this check.

its not an issue for ROHC either, we have an implementation 
here. when ROHC comes across a packet bigger than what it 
is supposed to be, it skips compressing this particular 
packet. and this packet is received in the clear. we do 
exactly this. we have run tests with a simple RTP 
application. the typical packet in the data stream 
(that is being compressed in our experiment) is 
(IPv6 header + home address option + UDP header + 
RTP header + payload). if a packet received by the 
compression engine is bigger  than this, we skip 
compression on this packet. i dont know whats the big 
deal. it works. somebody please correct me if i am 
wrong.

Vijay