[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: issues from the bakeoff

To: Dan McDonald <danmcd@Eng.Sun.Com>
Subject: Re: issues from the bakeoff
From: itojun@iijlab.net
Date: Thu, 17 Jun 1999 08:57:08 +0900
cc: shacham@cisco.com, dharkins@network-alchemy.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com
In-reply-to: danmcd's message of Wed, 16 Jun 1999 09:41:37 MST. <199906161641.JAA22826@kebe.Eng.Sun.COM>
Sender: owner-ipsec@lists.tislabs.com


>> 	Well-known CPI is not very friendly with PFKEY interface (RFC2367).
>> 	RFC2367 expects unique SPI per peer (which can embed CPI in lower
>> 	2 bytes), but for well-known CPI we can't.
>Why is this an issue?
>You can treat the well-known CPI as a pre-added compression association,
>which, if you use SADB_GET, would reveal a match.  If you tried to
>ADD/UPDATE, you'd just get EEXIST.

	We need to put explicit (src, dst, cpi) set into the kernel,
	as we never specify cpi/spi from policy management routines.
	spi/cpi will be picked by the kernel.  Therefore, we need to
	configure (src, dst, cpi) explicitly (cannot be preloaded).

	For inbound direction, there is no issue - we can accept any packet
	with well-known CPI.  For outbound direction I'm sure we have issues
	to be solved.

itojun

References:

Re: issues from the bakeoff

From: Dan McDonald <danmcd@Eng.Sun.Com>

Prev by Date: Re: issues from the bakeoff
Next by Date: draft-ietf-ipsec-notifymsg-00.txt
Prev by thread: Re: issues from the bakeoff
Next by thread: Re: issues from the bakeoff
Index(es):
- Main
- Thread