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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
