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

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Tue, 29 Oct 2002 17:06:55 +0900 (JST)

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: Vijay Devarapalli <[email-masked]>
Date: Tue, 29 Oct 2002 18:10:47 -0800

for reference, the old method Keiichi is referring to is at
http://people.nokia.net/vijayd/ipsec_usage.txt.

a clarification. mipv6-ha-ipsec does not change the SPD entries
through the API. it only changes the corresponding SA entry.

the following comment from Francis Dupont motivated the design 
in the current draft :-)

> => no, it is deeply stupid to add a degenerated tunnel stuff to
> an already encapsulated packet: just use the correct addresses!

some more text from Francis (this is from a private email).

> => in fact we have the choice between a direct update of SAs
> or a delete/create of SAs. As usually SPDs don't point directly
> to SAs, even in the manual mode, the second case should be more common.

regards
Vijay

ps: I am not commenting on Keiichi's mail yet. I will let others
do it first.

Keiichi SHIMA / 島慶一 wrote:
> If I misread the draft, please correct me.>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 30 Oct 2002 11:03:22 -0800

Keiichi SHIMA / 島慶一 wrote:

>         possible for all cases.  

if the API is not available, they have to just delete the current SA
and then add an SA with updated tunnel gateway address. they should
be able to do this.

Vijay

---

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

Hi Vijay,

From: Vijay Devarapalli <[email-masked]>

> through the API. it only changes the corresponding SA entry.

I thought mipv6-ha-ipsec changes SPDs but not SAs.  Did I misread?

> > an already encapsulated packet: just use the correct addresses!

I do not object to this.  If the outer header uses HoA, it is
redundant.  What we can get from the redundancy is that we can
separate ipsec and mobile ipv6.  I would think it is better to split.

> > to SAs, even in the manual mode, the second case should be more common.

From: Vijay Devarapalli <[email-masked]>
> and then add an SA with updated tunnel gateway address. they should

Does most ipsec stack provide the feature?  (Our ipsec stack does not
have such APIs(add/remove SA (or SPD)) from the kernel inside :-)

But, as I have noted in the previous mail, we are possible to
implement them (or can access directly to the SA/SPD DB in the kernel)
because we have ipsec stack of our own.

---
Keiichi SHIMA

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 30 Oct 2002 19:21:46 -0800

hi Keiichi,

> I thought mipv6-ha-ipsec changes SPDs but not SAs.  Did I misread?

it changes the SA entry.

> separate ipsec and mobile ipv6.  I would think it is better to split.

the goal from the beginning has been to avoid making changes to 
IPsec as much as possible. IMO, I think we acheived that in
the mipv6-ha-ipsec draft.

moreover, we dont want to be doing something stupid. :-)

> Does most ipsec stack provide the feature?

let others (whoever can neither have such an API nor add/delete 
SAs from the MIPv6 module) comment about this.

regards
Vijay

---

From: Fukumoto Atsushi <[email-masked]>
Date: Thu, 31 Oct 2002 15:27:18 +0900

> > Does most ipsec stack provide the feature?

For your info: In PFKEY spec, it is prohibited to change an
established SA.

[RFC2367]
   ..... if the original
   SA is an SADB_SASTATE_MATURE or DYING SA, only the sadb_sa_state
   field in the SA header and lifetimes (hard, soft, and current) may be
   changed and any attempt to change other values MUST result in an
   error return of EINVAL.

I don't know whether existing implementations enforce it.

Also, I think removing and creating an SA will not be equivalent to
modifying an existing SA if the replay protection is used and the API
does not provide a method to preserve the replay protection
information.

					FUKUMOTO Atsushi
					[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 31 Oct 2002 11:56:13 -0800

Hi,

>    changed and any attempt to change other values MUST result in an

when I read the entire section 3.1.2 of RFC 2367, it appears 
to me that the authors want to prevent somebody from changing 
essential information like the src/dst address, the key, the
algorithm information, the identity information..... for
an existing SA. I dont think they ever thought somebody would
want to change the tunnel gateway information (which IMO is
not amont the essential information in an SA).

I could be wrong....

> does not provide a method to preserve the replay protection

oh no... when I meant add and delete SA, I didnt mean you should
get rid of the current SA and create a new SA. every field from
the original SA is copied onto the new SA. only one of the tunnel
gateway addresses is changed. you should absolutely preserve the
replay protection information.

section 3.1.5 of RFC 2367 says SADB_GET returns a copy of a 
Security Association from the kernel's key table.

regards
Vijay

ps: for others, RFC 2367 gives some examples of how routing 
daemons like OSPF can interface with the kernel SADB through 
PF_KEY API. you might find it interesting to read.