Re: [RFC][PATCH][XFRM][0/5] extension for XFRM databases

[jamal <hadi@cyberus.ca>]

Hello,

On Fri, 2007-02-02 at 20:25 +0900, Shinta Sugimoto wrote:

> In the design phase, we sorted out the requirements as below:
> 
> (1) Overhead of userland <-> kernel interaction message exchange
>     should be kept minimum.
> (2) There should not be too much requirement for user application
>     to leverage the feature (dynamic update of endpoint).  More
>     specifically, we don't want to expect the user application to
>     have detailed information of IPsec security association
>     (i.e. SPI).
> (3) There should not be negative impact on the existing software
>     which is based on PF_KEYv2 (RFC2367).
> 
> Firstly, if we use the existing messages for updating SPD and SAD,
> we simply need 2 pairs of request/response exchange between the
> userland and kernel for updating a single endpoint.  This is not
> ideal from the perspective of (1).

Ok, if i understand you correctly:
Instead of having from userland one message for updating SAD and another
for updating SPD, you have a single message which updates both?

> Secondly, we need to be careful about updating the endpoint address
> because it may invoke unexpected signaling (ACQUIRE) to the user
> application.  Imagine you update SPD and SAD sequentially while there
> is an outbound flow going on.  The kernel may end up with triggering
> the userland application by unexpected ACQUIRE message due to the
> absence of SAD entry.  In order to avoid this problem, we need a sort
> of atomic update of SPD and SAD entries.  XFRM_MSG_MIGRATE is designed
> and implemented in a way that unexpected ACQUIRE would never occur.
> 

Ok, this is sensible - it could be achieved with two multipart messages
in netlink; but a single message is better.

> Thirdly, we also need to pay attention to the PF_KEYv2 spec.
> XFRM_MSG_UPDSA is derived from SADB_UPDATE message in PF_KEYv2.
> According to the spec, the semantics of SADB_UPDATE is to add a new
> security association with the information provided by previous
> SADB_GETSPI message.  We think it's not a good idea to overload
> the semantics of SADB_UPDATE message because it may confuse legacy
> software from the perspective of (3).  Moreover, caller of
> SADB_UPDATE should specify SPI, source address, and destination
> address, which is a bit problematic from the perspective of (2).
> 


We really dont have this issue with xfrm side.
I think that PF_KEYv2 is just a dinosaur that needs to be extinct.
Continuing to bandaid around it is converting into a mammoth.
I found your first two explanation more reasonable, but not this one.

> From the above reasons, we decided to extend XFRM/PF_KEYv2 for
> dynamic update of the endpoint.  Please note that the mechanism is
> useful not only for Mobile IPv6 but also for Mobile VPN scenario.
> 

Can you explain what you mean by this last part? There are many ways to
achieve mobile VPN - is the end client aware?

> Does this make sense?

Yes, I think I see the logic behind your design. To be 100% convinced,
depends if your answer to the first question i asked is "yes".

cheers,
jamal