Subject: RE: [mobile-ip] mipv6-ha-ipsec and the old method comparison

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 30 Oct 2002 03:21:53 +0100

Keiichi, 

I completely agree. 100%. I would also reiterate that if BW is an 
issue (payload traffic). Header compression will compress the HAO. 

Hesham

  > -----Original Message-----
  > From: [email-masked] [mailto:[email-masked]]
  > Sent: Tuesday, October 29, 2002 9:07 AM
  > To: [email-masked]
  > Subject: [mobile-ip] mipv6-ha-ipsec and the old method comparison
  > 
  > 
  > Hi,
  > 
  > I re-read the mipv6-ha-ipsec draft and think again what is merit and
  > demerit compared with the old method.
  > 
  > Bellow is the (long) summary of comparison of those two methods.
  > (Also, I note my opinion inline quoted by [my opinion]).
  > 
  > If I misread the draft, please correct me.
  > 
  > 
  > --------------------------------------------------
  > 
  > (Note: I only talk about MN<->HA tunneling case.  MN<->HA transport
  > mode case looks no problem to me.)
  > 
  > (Note2: I do not talk about the safety of the draft.  I 
  > hope the ipsec
  > wg will give us many thoughtful/helpful opinions)
  > 
  > 
  > Method 1: The proposed method by the draft mipv6-ha-ipsec.
  > Method 2: The method defined before.
  > 
  > - Consideration about packet overhead
  > 
  > 	Method 1 can save 24 bytes for DSTOPT or RTHDR2 in the below
  > 	cases:
  > 		- RR signaling (MN to CN via HA)
  > 		- RR signaling (CN to MN via HA)
  > 		- Payload with IPsec tunnel (MN to CN via HA)
  > 		- Payload with IPsec tunnel (CN to MN via HA)
  > 
  > 			(for detailed packet formats, please see the
  > 			end of this mail)
  > 
  > 	[My opinion] In the above 4 bullets, first two are less
  > 	significant because there are not so many signaling packets.
  > 	Last two may concern.  However, the last two are not major
  > 	cases.  Basically, MN<->CN traffic is not protected.  Even if
  > 	we protect the path between MN<->HA, the HA<->CN path never be
  > 	protected.  Also, when the CN supports RO, the entire path is
  > 	not protected because the packets between MN<->CN never go
  > 	through HA.
  > 
  > 	[My opinion] I think the main purpose of the desire to protect
  > 	MN<->HA tunnel is for a kind of a company VPN like usage.  Of
  > 	course it is important area, but when we think the future of
  > 	mobile ipv6, the number of users of mobile nodes of personal
  > 	users is greater than that of company VPN users, though this
  > 	is just my opinion (or expectance)
  > 
  > 	[My opinion] I think the overhead is not a problem.  I wander
  > 	it is important to protect only MN<->HA path for normal
  > 	payload traffic.  And, most of the traffic is ether:
  > 		- Payload (MN to CN via HA)
  > 		- Payload (CN to MN via HA)
  > 	Both of them do not have overhead.
  > 
  > 
  > - SA/SPD database handling
  > 
  > 	In Method 1, we can manage SA/SPD database as described in the
  > 	draft mipv6-ha-ipsec.  Whereas, in Method 2, there are no need
  > 	for managing SA/SPD entries from the mobile ipv6 stack.
  > 	Because SA is created between HA and HoA not between HA and
  > 	CoA.  HoA is not changing.
  > 
  > 	In Method 1, we need to define some IPsec APIs for managing
  > 	SA/SPD database.  In MEthod 2, we can use the ipsec stack as
  > 	is.
  > 
  > 	[My opinion] Mehotd 1 is possible technically.  For example,
  > 	our project has both IPsec and mobile ipv6 stacks, I think our
  > 	project are able to implement such APIs.  But I doubt it is
  > 	possible for all cases.  For example, there are some groups
  > 	who are not developping IPsec but developping mobile ipv6.
  > 	Or, consider to purchase IPsec stack and implement mobile ipv6
  > 	on it.  In such cases, the interaction is more difficult.
  > 
  > 	[My opinion] I don't think it a good idea to have close
  > 	relationship between IPsec and mobile ipv6.  They are
  > 	logically on the different layer.  Mobile ipv6 should be one
  > 	of applications of IPsec.
  > 
  > 
  > - The number of SAs/SPDs
  > 
  > 	I will try to describe them for static keying using *BSD's
  > 	setkey like notation.  (just to confirm if I can do both
  > 	methods in my=BSD environment.)
  > 
  > 	In Method 1:
  > 		Both MN and HA:
  > 			add HoA HA  esp SPI1 tunnel-mode espalgo+pass
  > 			add HA  HoA esp SPI2 tunnel-mode espalgo+pass
  > 
  > 		MN:
  > 			spdadd MN ANY proto=MH dir=out
  > 				esp tunnel/CoA-HoA/unique:SPI1;
  > 			spdadd ANY MN proto=MH dir=in
  > 				esp tunnel/HoA-CoA/unique:SPI2;
  > 
  > 		HA:
  > 			spdadd ANY MN proto=MH dir=out
  > 				esp tunnel/HoA-CoA/unique:SPI2;
  > 			spdadd MN ANY proto=MH dir=in
  > 				esp tunnel/CoA-HoA/unique:SPI1;
  > 
  > 		Note: CoA in the SPD entries is updated at each time
  > 		the MN moves to a new network.
  > 
  > 	In Method 2:
  > 		Both MN and HA:
  > 			add HoA HA  esp SPI1 tunnel-mode espalgo+pass
  > 			add HA  HoA esp SPI2 tunnel-mode espalgo+pass
  > 
  > 		MN:
  > 			spdadd MN ANY proto=MH dir=out
  > 				esp tunnel/HoA-HA/unique:SPI1;
  > 			spdadd ANY MN proto=MH dir=in
  > 				esp tunnel/HA-HoA/unique:SPI2;
  > 
  > 		HA:
  > 			spdadd ANY MN proto=MH dir=out
  > 				esp tunnel/HA-HoA/unique:SPI2;
  > 			spdadd MN ANY proto=MH dir=in
  > 				esp tunnel/HoA-HA/unique:SPI1;
  > 
  > 	(As I have not tested/implemented Method 1, I'm not sure it is
  > 	OK or not, but anyway,) Both methods have the same number of
  > 	SA/SPD.  Method 2 needs no additional task whereas Method 1
  > 	needs to be updated when the MN gets a new CoA.
  > 
  > 	[My opinion] Method 2 is simpler.  It doesn't require
  > 	additional task for both IPsec and mobile ipv6.
  > 
  > 
  > - Packet format comparison
  > 
  > 	Followings are the wire format of tunneled packet.  If we uses
  > 	Method 1, the MN and HA only manage CoA<->HA tunnel.  Whereas,
  > 	in Method 2, the MN and HA must manage two tunnels.  One is
  > 	for CoA<->HA, the other is HoA<->HA(not on wire, but logically).
  > 
  > 	[My opinion] Method 1 is simpler.  It only manage one tunnel.
  > 
  > 	Method 1:
  > 		RR signaling (MN to CN via HA)
  > 			IP (src=CoA, dst=HA)
  > 			ESP
  > 			IP (src=HoA, dst=CN)
  > 			Mobility (HoTI)
  > 
  > 		RR signaling (CN to MN via HA)
  > 			IP (src=HA, dst=CoA)
  > 			ESP
  > 			IP (src=CN, dst=HoA)
  > 			Mobility (HoT)
  > 
  > 		Payload (MN to CN via HA)
  > 			IP (src=CoA, dst=HA)
  > 			IP (src=HoA, dst=CN)
  > 			Upper Layer
  > 
  > 		Payload (CN to MN via HA)
  > 			IP (src=HA, dst=CoA)
  > 			IP (src=CN, dst=HoA)
  > 			Upper Layer
  > 
  > 		Payload with IPsec tunnel (MN to CN via HA)
  > 			IP (src=CoA, dst=HA)
  > 			ESP
  > 			IP (src=HoA, dst=CN)
  > 			Upper Layer
  > 
  > 		Payload with IPsec tunnel (CN to MN via HA)
  > 			IP (src=HA, dst=CoA)
  > 			ESP
  > 			IP (src=CN, dst=HoA)
  > 			Upper Layer
  > 
  > 	Method 2:
  > 		RR signaling (MN to CN via HA)
  > 			IP (src=CoA, dst=HA)
  > 			DSTOPT(HoA)		<- difference
  > 			ESP
  > 			IP (src=HoA, dst=CN)
  > 			Mobility (HoTI)
  > 			
  > 		RR signaling (CN to MN via HA)
  > 			IP (src=HA, dst=CoA)
  > 			RTHDR2 (HoA)		<- difference
  > 			ESP
  > 			IP (src=CN, dst=HoA)
  > 			Mobility (HoT)
  > 
  > 		Payload (MN to CN via HA)
  > 			IP (src=CoA, dst=HA)
  > 			IP (src=HoA, dst=CN)
  > 			Upper Layer
  > 
  > 		Payload (CN to MN via HA)
  > 			IP (src=HA, dst=CoA)
  > 			IP (src=CN, dst=HoA)
  > 			Upper Layer
  > 
  > 		Payload with IPsec tunnel (MN to CN via HA)
  > 			IP (src=CoA, dst=HA)
  > 			DSTOPT (HoA)		<- difference
  > 			ESP
  > 			IP (src=HoA, dst=CN)
  > 			Upper Layer
  > 
  > 		Payload with IPsec tunnel (CN to MN via HA)
  > 			IP (src=HA, dst=CoA)
  > 			RTHDR2 (HoA)		<- difference
  > 			ESP
  > 			IP (src=CN, dst=HoA)
  > 			Upper Layer
  > 
  > 
  > ---
  > Keiichi SHIMA
  > IIJ Research Laboratory <[email-masked]>
  > KAME Project <[email-masked]>
  >

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Thu, 31 Oct 2002 11:51:19 +0900 (JST)

Hi Hesham,

From: "Hesham Soliman (EAB)" <[email-masked]>

> issue (payload traffic). Header compression will compress the HAO. 

Though I'm not familier with HC, but yes.  It will compress the HAO.
In this case, the overhead problem will be less significant.

---
Keiichi SHIMA