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

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

[Shinta Sugimoto]

Hello,

Let me issue a request for comments for the patch set developed by
the USAGI project.  The patch set aims to extend the XFRM framework
so that endpoint addresses in the XFRM databases, namely XFRM policy
and XFRM state can be dynamically updated according to a request from
user application.  This feature is required for Mobile IPv6 to follow
the security requirements specified in RFC3776.  More specifically,
the Mobile Node and Home Agent need to update the endpoint addresses
of the IPsec tunnel when the Mobile Node changes its attachment point
(Care-of Address) to the Internet.  The kernel also notifies userland
application via both Netlink and PF_KEY sockets so that user application
(e.g. IKE Daemon) could be informed of the updates appropriately.
More detailed information of motivation/rationale for this feature
can be found in the internet draft[1].

The patch set consists of following patches:

[1/5] [XFRM]: Extension to the XFRM framework for dynamic update of endpoint address(es)
[2/5] [XFRM]: User interface for handling XFRM_MSG_MIGRATE
[3/5] [XFRM]: CONFIG_XFRM_MIGRATE option
[4/5] [PFKEYV2]: Extension to the PF_KEYv2 framework for dynamic update of endpoint address(es)
[5/5] [PFKEYV2]: CONFIG_NET_KEY_MIGRATE option

Any comments/suggestions are appreciated.
Thank you very much.

[1]: http://www.ietf.org/internet-drafts/draft-sugimoto-mip6-pfkey-migrate-03.txt


Regards,
Shinta

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

[jamal]

Hello,
I think i may have understood your approach before but i am a little
lost right now, so bear with me.

Could we not achieve your goals by using (on XFRM at least)
XFRM_MSG_UPDPOLICY  and XFRM_MSG_UPDSA ?

cheers, 
jamal

On Thu, 2007-01-02 at 13:09 +0900, Shinta Sugimoto wrote:
> Hello,
> 
> Let me issue a request for comments for the patch set developed by
> the USAGI project.  The patch set aims to extend the XFRM framework
> so that endpoint addresses in the XFRM databases, namely Could XFRM policy
> and XFRM state can be dynamically updated according to a request from
> user application.  This feature is required for Mobile IPv6 to follow
> the security requirements specified in RFC3776.  More specifically,
> the Mobile Node and Home Agent need to update the endpoint addresses
> of the IPsec tunnel when the Mobile Node changes its attachment point
> (Care-of Address) to the Internet.  The kernel also notifies userland
> application via both Netlink and PF_KEY sockets so that user application
> (e.g. IKE Daemon) could be informed of the updates appropriately.
> More detailed information of motivation/rationale for this feature
> can be found in the internet draft[1].
> 
> The patch set consists of following patches:
> 
> [1/5] [XFRM]: Extension to the XFRM framework for dynamic update of endpoint address(es)
> [2/5] [XFRM]: User interface for handling XFRM_MSG_MIGRATE
> [3/5] [XFRM]: CONFIG_XFRM_MIGRATE option
> [4/5] [PFKEYV2]: Extension to the PF_KEYv2 framework for dynamic update of endpoint address(es)
> [5/5] [PFKEYV2]: CONFIG_NET_KEY_MIGRATE option
> 
> Any comments/suggestions are appreciated.
> Thank you very much.
> 
> [1]: http://www.ietf.org/internet-drafts/draft-sugimoto-mip6-pfkey-migrate-03.txt
> 
> 
> Regards,
> Shinta
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Shinta Sugimoto]

Hello,

On Thu, 01 Feb 2007 08:24:33 -0500
jamal <hadi@cyberus.ca> wrote:

> Hello,
> I think i may have understood your approach before but i am a little
> lost right now, so bear with me.

No problem.

> 
> Could we not achieve your goals by using (on XFRM at least)
> XFRM_MSG_UPDPOLICY  and XFRM_MSG_UPDSA ?

At the beginning, we consider whether the existing messages
(XFRM_MSG_UPDPOLICY and XFRM_MSG_UPDSA) can do the job.  But after
careful analysis, we reached to the conclusion that we need
something else.  Let me expand:

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).

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.

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).

>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.

Does this make sense?


Regards,
Shinta

> 
> cheers, 
> jamal
> 
> On Thu, 2007-01-02 at 13:09 +0900, Shinta Sugimoto wrote:
> > Hello,
> > 
> > Let me issue a request for comments for the patch set developed by
> > the USAGI project.  The patch set aims to extend the XFRM framework
> > so that endpoint addresses in the XFRM databases, namely Could XFRM policy
> > and XFRM state can be dynamically updated according to a request from
> > user application.  This feature is required for Mobile IPv6 to follow
> > the security requirements specified in RFC3776.  More specifically,
> > the Mobile Node and Home Agent need to update the endpoint addresses
> > of the IPsec tunnel when the Mobile Node changes its attachment point
> > (Care-of Address) to the Internet.  The kernel also notifies userland
> > application via both Netlink and PF_KEY sockets so that user application
> > (e.g. IKE Daemon) could be informed of the updates appropriately.
> > More detailed information of motivation/rationale for this feature
> > can be found in the internet draft[1].
> > 
> > The patch set consists of following patches:
> > 
> > [1/5] [XFRM]: Extension to the XFRM framework for dynamic update of endpoint address(es)
> > [2/5] [XFRM]: User interface for handling XFRM_MSG_MIGRATE
> > [3/5] [XFRM]: CONFIG_XFRM_MIGRATE option
> > [4/5] [PFKEYV2]: Extension to the PF_KEYv2 framework for dynamic update of endpoint address(es)
> > [5/5] [PFKEYV2]: CONFIG_NET_KEY_MIGRATE option
> > 
> > Any comments/suggestions are appreciated.
> > Thank you very much.
> > 
> > [1]: http://www.ietf.org/internet-drafts/draft-sugimoto-mip6-pfkey-migrate-03.txt
> > 
> > 
> > Regards,
> > Shinta
> > 
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[jamal]

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

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

[Shinta Sugimoto]

Hello Jamal,

Thank you for your feedback. Please find my comments inline.

On Fri, 02 Feb 2007 08:35:51 -0500
jamal <hadi@cyberus.ca> wrote:

> 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?

Yes.  A XFRM_MSG_MIGRATE message can update an SPD entry and associated
SAD entries (if any) at a time.

> 
> > 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?

By "Mobile VPN", I meant a VPN scenario where clients roam around
subnets and continue changing its attachment point to the Internet
(aka roadwarrior).  In such case, both client and SGW need to update
endpoint address of the security association.  When the endpoint address
of client side is updated, instead of re-establishing the security
association from scratch, the client may inform the SGW of its new
endpoint address.  This is what MOBIKE (RFC4555) does.  So, just like
in the case of Mobile IPv6, endpoint address management of IPsec
databases is necessary and XFRM_MSG_MIGRATE message can be used.

> 
> > 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".

Ok, thanks.


Regards,
Shinta

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

[jamal]

On Sat, 2007-03-02 at 09:28 +0900, Shinta Sugimoto wrote:

> Yes.  A XFRM_MSG_MIGRATE message can update an SPD entry and associated
> SAD entries (if any) at a time.
> 

Ok, you have convinced me on the need for the message.

> By "Mobile VPN", I meant a VPN scenario where clients roam around
> subnets and continue changing its attachment point to the Internet
> (aka roadwarrior).  In such case, both client and SGW need to update
> endpoint address of the security association.  When the endpoint address
> of client side is updated, instead of re-establishing the security
> association from scratch, the client may inform the SGW of its new
> endpoint address.  This is what MOBIKE (RFC4555) does.  So, just like
> in the case of Mobile IPv6, endpoint address management of IPsec
> databases is necessary and XFRM_MSG_MIGRATE message can be used.

makes a lot of sense.

Thanks for your patience Shinta.

cheers,
jamal

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

[David Miller]

Shinta-san, let me know when an updated version of your
patches are available, I'd like to include them in 2.6.21

Thank you.

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

[Shinta Sugimoto]

Dear David,

Thank you for your consideration.

Updated patches will be ready by Feb 7th (Wednesday) 22:00 JST at the latest.
Hopefully I can send them earlier, after finishing tests for the kernel
with the patch set that incorporates all the comments received.

Regards,
Shinta

On Sun, 04 Feb 2007 16:56:42 -0800 (PST)
David Miller <davem@davemloft.net> wrote:

> 
> Shinta-san, let me know when an updated version of your
> patches are available, I'd like to include them in 2.6.21
> 
> Thank you.
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html