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

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

Jarno, 

A cople of basic questions below for my understanding.

> > 
> > Someone (I forgot who) pointed out that even this was a problem for 
> > careful implementations of IPsec.
> > The claim (which I understand and agree with) is that
> > a TCP connection would like to use the same security policy 
> > for the lifetime
> > of the connection. If you don't then how can you use IPsec to prevent 
> > a unsecure RST packet from blowing away your connection?
> > 
> > Thus if the packet is piggyback on a TCP SYN packet the peer
> > is likely to assume that all of that TCP connection will be secured,
> > but that will not be the case since the SYN was only secured 
> > as a site effect
> > of securing the piggy-backed BU.
> > 
> 
> 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?
> 
> 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. 
> 
> 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.
> 
> Normally, inbound IPsec processing matches also the packets that came with
> no IPsec headers against the SPD to determine whether they *should* have
> come with IPsec headers.
> 
> If Mobile IP Next Header selector is implemented as Transport Layer Protocol
> selector, there is no way that IPsec inbound processing could know to look
> for another embedded transport protocol selector (e.g. TCP) to make sure
> that the SPD entry for that states "passby".
> 
> However, if a new selector parameter is defined for "in-between" Next
> Headers, then both the sender and recipient of any piggybacked transport
> protocol could check that the SPD entry matching the transport selector does
> not require IPsec processing.
> 
	=> Could you elaborate a bit on what you mean by "in between"
	headers ?

> The new selector parameter would be needed to be implemented by all CNs
> supporting route optimization (as well as the mobile nodes themselves), and
> the associated check for the SPD entry for the piggybacked transport message
> should be implemented at the same time as the new selector parameter.
> 
> By the RFC2401 only the first matching SPD entry is used for packet's IPsec
> processing ("the first matching entry is consistently selected"). This would
> need to change in case of "in-between" Next Header selectors and piggybacked
> transport protocol messages, where multiple SPD entries need to be selected
> and checked by both ends. Is this acceptable? 
> 
	=> Well I don't know about acceptable, the question is 
	more like: how easy is it to change anything in an IPsec RFC ?
	You or someone else more involved in IPsec can perhaps 
	enlighten  us. 

	Hesham

---

From: [email-masked]
Date: Thu, 23 Aug 2001 11:24:15 +0000

> From:          "Hesham Soliman  (ERA)" <[email-masked]>
> To:            "[email-masked]'" <[email-masked]>,
>                [email-masked]
> Subject:       RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus 
> Date:          Thu, 23 Aug 2001 11:11:41 +0200
> Reply-to:      [email-masked]

> 	=> Could you elaborate a bit on what you mean by "in between"

By "in-between" all IPv6 Next Headers are meant, which are no 
transport layer header, like Routing Header, Fragment Header or a 
possible new MIP Header.

> 	You or someone else more involved in IPsec can perhaps 

It's not only the new Next Header, also the processing has to be a 
little bit modified (see my comment in the previous mail). I wouldn't 
expect these modifications to be done very easy.

> 	Hesham

Wolfgang
##########################################################
##  Wolfgang Fritsche
##  Senior Project Manager 
##         
##  IABG
##  Department for Communication Networks
##  Einsteinstr. 20
##  85521 Ottobrunn
##  Germany
##  
##  Phone: +49 89 6088 2897
##  Fax: +49 89 6088 2845
##  E-Mail: [email-masked]
##  Web: www.ipv6.iabg.de, www.iabg.de
##########################################################