Subject: Re: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate

From: Francis Dupont <[email-masked]>
Date: Mon, 05 Feb 2007 18:01:37 +0100

In your previous mail you wrote:

   I agree. We should keep the kernel as simple as possible. But your
  approach is not simple on Linux,

=> this is not an argument.

   because Linux does not have an IP header and extension headers yet,

=> you don't need to have them, you only need to know what will be put
in them.

   It will also have to fragment the packet

=> this is more than unnecessary!

   I understand that IKE needs to know a precise CoA for MIPv6 support.
   Why is it not enough to specify that the kernel sends SADB_ACQUIRE with
   the packet like [IPv6][DSTOPT(CoA)][MH] as SADB_X_MIPV6_PACKET or
   SADB_X_MIPV6BU_PACKET?

=> this is less general so you likely have to do it one day...

   SADB_X_EXT_PACKET is general approach, but it is costy for Linux.
   I think it is conflict with the principle on Linux.
   
=> the world shall become too warm for penguins too (:-).

   I think the functionality is an extension. The IPsec policy, in the kernel
   which support your extension, should have information that whether the
   SADB_ACQUIRE needs a packet copy or not.
   
=> I am not convinced it will be a real win in the long term but you can
do what you want.

Regards

[email-masked]

PS: the idea behind the general usage of SADB_X_EXT_PACKET is
(quoting RFC 4306 page 25):

   To enable the responder to choose the appropriate range in this case,
   if the initiator has requested the SA due to a data packet, the
   initiator SHOULD include as the first traffic selector in each of TSi
   and TSr a very specific traffic selector including the addresses in
   the packet triggering the request.

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Kazunori Miyazawa <[email-masked]>
Date: Mon, 05 Feb 2007 10:57:33 +0900

Francis Dupont wrote:
>    I have a question about the PF_KEY extension draft (draft-sugimoto- 
>    mip6-pfkey-migrate).
>    
>    The draft proposes SADB_ACQUIRE message extension to include the  
>    entire (or the beginning of the) IP header that triggered the acquire  
>    message.  The reason of the extension described in the draft is to  
>    extract the CoA of an MN that is used for  IKE communication.
>    
>    The question is that, do we need to include the entire (or the  
>    beginning of the) packet to the acquire message?  If the goal is to  
>    provide the CoA information to an IKE program, then why can't we  
>    simply notify the address?
>    
> => in fact you have the choice between to decode the packet in the kernel
> or in the application. I am in favor of the first option for many
> reasons including:
>  - it is better to keep the kernel as simple as possible
>   (i.e., KISS principle)
>  - we don't know a priori what applications will need.
> 
>    Including a raw packet has two drawbacks.
>    
>    1. The IKE program that supports this extension has to parse the raw  
>    IPv6 packet to extract a CoA.
>    

I agree. We should keep the kernel as simple as possible. But your approach is not
simple on Linux, because Linux does not have an IP header and extension headers yet,
when acquiring IPsec SA. It will have to build up the packet to send SADB_ACQUIRE
message (copying the data from user space, build up extenstion headers, and add
an IPv6 header). It will also have to fragment the packet if necessary and the application
will keep fragment headers and reassemble them to decode because the fragment header is
one of the extension headers.

> => someone has to do this.
> 
>    2. Some kernel implementations do not have the final packet structure  
>    when sending an ACQUIRE message.  In these implementations, they only  
>    have abstract information  to construct the packet, and the packet  
>    will be constructed just before it is sent.  In this case, the kernel  
>    must create a packet before sending an ACQUIRE message, that is not  
>    necessary in their design.
>    
> => to give the final structure doesn't matter as the decoding code is
> supposed to be kernel dependent (even if there are no many choice and
> it is easy to get one code working for many kernels). The only key point
> is to give to the application enough information, the way they are
> organized is a detail as soon as the application knows it!
> 

I think the functionality is an extension. The IPsec policy, in the kernel
which support your extension, should have information that whether the SADB_ACQUIRE
needs a packet copy or not.

Thank you,

--
Kazunori Miyazawa

---

From: Francis Dupont <[email-masked]>
Date: Tue, 06 Feb 2007 11:23:29 +0100

It means that it is a general IPsec stuff. Why don't you discuss it in
   IPsec ML but MIPv6?

=> in fact the right list is the departed PF_KEY list...

Regards

---

From: Arnaud Ebalard <[email-masked]>
Date: Tue, 6 Feb 2007 16:36:33 +0100

Hi Francis, Hi everyone,

Le 5 févr. 07 à 02:57, Kazunori Miyazawa a écrit :

> approach is not
> when acquiring IPsec SA.

Based on the draft and initial Racoon code provided by Francis  
(developed for BSD), while implementing the MIGRATE and  
SADB_X_EXT_PACKET for Linux Kernel (2.6.16.20), ipsec-tools (0.6.6)  
and MIPL (CVS version), we (mostly Yves-Alexis in CC) also  
encountered that problem and had to reconstruct a triggering packet  
from scratch just to pass the CoA to the IKE daemon. Indeed, it is  
pretty annoying ...

IMHO, even if the problem is Linux specific, the discussion on the  
extension is still interesting. Francis, is it possible to have some  
comments on following points, just to clarify them:

o the extension wants to be generic for future protocols that would  
require a complete (obviously reconstructed in Linux case) packet to  
be passed in the SADB_ACQUIRE. IMHO, keeping it generic is  
interesting if there are many protocol that will benefit from that.  
At the moment, only MIPv6 uses it. Is there any other planned ?

o As said previously, this adds Mobile IPv6 specific code to the  
kernel to add useless information to the PF_KEY messages (and also  
XFRM in linux case)

o from the IKE daemon standpoint (racoon in our case), the MIPv6  
specific code has to process the whole packet to figure that it  
matches specific criteria and finally extract the CoA. This also adds  
code where a simple handler associated with a MIPv6-specific "non- 
error-prone" extension (like a TLV including the CoA) whould be  
sufficient

o If, at some point, some new (non MIPv6) mechanism wants to use the  
information from the SADBX_EXT_PACKET packet in the IKE daemon, the  
code that has been developed for MIPv6 will be modified (with  
possible bug addition) where another TLV could be added to deal with  
it in a generic way (like it is done in racoon at the moment for  
other extensions)

o same remark as previous point, but for the kernel.

As a conclusion, should the SADB_X_EXT_PACKET be kept generic  
(justified by its use in multiple mechanisms in the future) or  
modified to avoid complete packet inclusion where it is not necessary  
(i.e. keep only the required info).

This is probably just a silly final remark but i wonder if such a  
question has been raised when the discussion on the concept of DOI  
has been defined for IKE/IPsec ;-)

Regards,

Arnaud.

ps : i intend to spend quite some time in next monthes to update  
racoon, mipl, ipsec patches we have for MIGRATE/SADB_X_EXT_PACKET for  
current version of those kernel/userland parts. If you are interested  
of already work on it, i'll be interested to know/work with you.
_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Kazunori MIYAZAWA <[email-masked]>
Date: Tue, 06 Feb 2007 15:29:25 +0900

Hello Francis,

> => you don't need to have them, you only need to know what will be put
But does EXT_PACKET need to extract those headers, doesn't it?
The Linux kernel which support the extension must copy and build the contents
to extract the headers. No?

> => this is more than unnecessary!

I feel SADB_X_EXT_PACKET part of the current draft is too ambiguous to
understand what should be contained and what form is used.
It only describes that it contains a triggering packet. And authors
recommend enough of the beginning of it. So, what is enough?
OK, I know it is not fragmented.

> => this is less general so you likely have to do it one day...

Yes it is less general. But the draft is "PF_KEY Extension as an Interface between
Mobile IPv6 and IPsec/IKE".
I think the generality of what you mean is beyound the scope of the document
because I read that SADB_X_EXT_PACKET extension will be applied not only Moble IPv6 BU
but also other general traffic such as TCP, UDP and so on.

> => the world shall become too warm for penguins too (:-).
Is it the daemon's work? ;-)

It means that it is a general IPsec stuff. Why don't you discuss it in
IPsec ML but MIPv6?
Then you will write how to use/parse the extension for MIPv6 in your draft.

Thank you,

--
Kazunori Miyazawa

---

From: Keiichi SHIMA <[email-masked]>
Date: Wed, 7 Feb 2007 14:54:23 +0900

Hello Francis, Kazunori, all,

> but also other general traffic such as TCP, UDP and so on.

I don't like the above idea that notifying partial information to  
user space.  It requires both kernel and IKE to deal with Mobile IPv6  
specific issues.

Instead, the ACQUIRE message should notify user programs of the end  
point address for the IKE communication only when the address is  
different from the SA's endpoint address.  This makes user space  
program simpler and independent from Mobile IPv6.  The IKE program  
can just use the specified address whenever such an alternate address  
is specified in the ACQUIRE message.  There is no judgement in  
whether the packet is for MIP or not in the IKE program.

I don't oppose defining EXT_PACKET.  Such a low-level data is useful  
in some cases (I don't have any idea of such cases right now,  
anyway), similar to the raw IP socket mechanism is useful for very  
general packet processing cases.

But, in this case (suggesting a different address for IKE  
communication), I think defining a dedicated option for this purpose  
is better.

Regards,
---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
WIDE Project <[email-masked]>

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Feb 2007 09:08:26 +0100

=> in fact it is a bit more than just the CoA because one has to
recognize a home registration binding update, perhaps not generated
by the kernel, and there can be more than one home address, etc.
So we come back to the first point of this thread: what (the kernel
or the KMP) is the entity doing the decoding.

   o the extension wants to be generic for future protocols that would  
   require a complete (obviously reconstructed in Linux case) packet to  
   be passed in the SADB_ACQUIRE.

=> I don't know if we'll really need something complete but:
 - we can't know exactly what will be needed, obviously the infos
   from the kernel itself are in the PCB but not the whole PCB.
 - again the decoding should be performed by the application.
  Linux is a case where this argument is not very good because it seems
  to decode the packet or to construct it have the same complexity.

   IMHO, keeping it generic is  
   interesting if there are many protocol that will benefit from that.  
   At the moment, only MIPv6 uses it. Is there any other planned ?
   
=> IKEv2 first TS pair.

=> the purpose is to be not Mobile IPv6 specific.

=> you have two arguments here: specific/general and kernel/user mode.
For the first one the SADB_X_EXT_PACKET goal is to be reused for IKEv2.
For the second one user mode is better at the exception of Linux.

   information from the SADB_X_EXT_PACKET packet in the IKE daemon, the  
   
=> I tried to anticipate the need of a second similar extension or
decoder code.

   
   
=> the DOI was an attempt to share KMPs for other things than IPsec.
It clearly failed but perhaps not for good reasons...

=> I believe we really need an IKE/IPsec capable MIPL. This already exists
for SHISA even it is not (yet?) distributed. BTW don't forget a good
documentation with examples as the main issue is to get the right config.
I work with racoon2/IKEv2, I can help you...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Feb 2007 09:34:24 +0100

But does EXT_PACKET need to extract those headers, doesn't it?
   The Linux kernel which support the extension must copy and build the
   contents to extract the headers. No?

=> IMHO we only have to make the content of SADB_X_EXT_PACKET system
dependent with a default to the real content at this (i.e., SPD
looking up for outgoing traffic) phase.

=> this enough is application dependent and is implemented in BSD by
a sysctl tunable.

=> until the application needs something like the packet ID there is
no reason at all to fragment.

   > => this is less general so you likely have to do it one day...
   
   Yes it is less general. But the draft is "PF_KEY Extension as an
   Interface between Mobile IPv6 and IPsec/IKE".
   I think the generality of what you mean is beyound the scope of the document
   because I read that SADB_X_EXT_PACKET extension will be applied not
   only Moble IPv6 BU
   but also other general traffic such as TCP, UDP and so on.
   
=> do you argue we really need two separate documents?
I propose you ask in the IPsec list where the IKEv2 first TS should
be extracted from, if the SADB_X_EXT_PACKET is a good solution
and if yes if it needs its own document.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Feb 2007 09:43:59 +0100

Keiichi, you should have missed this, quoting RFC 4306:

   The responder is allowed to narrow the choices by selecting a subset
   of the traffic, for instance by eliminating or narrowing the range of
   one or more members of the set of traffic selectors, provided the set
   does not become the NULL set.

   It is possible for the responder's policy to contain multiple smaller
   ranges, all encompassed by the initiator's traffic selector, and with
   the responder's policy being that each of those ranges should be sent
   over a different SA.  Continuing the example above, the responder
   might have a policy of being willing to tunnel those addresses to and
   from the initiator, but might require that each address pair be on a
   separately negotiated CHILD_SA.  If the initiator generated its
   request in response to an incoming packet from 192.0.1.43 to
   192.0.2.123, there would be no way for the responder to determine
   which pair of addresses should be included in this tunnel, and it
   would have to make a guess or reject the request with a status of
   SINGLE_PAIR_REQUIRED.

*  To enable the responder to choose the appropriate range in this case,
*  if the initiator has requested the SA due to a data packet, the
*  initiator SHOULD include as the first traffic selector in each of TSi
*  and TSr a very specific traffic selector including the addresses in
*  the packet triggering the request.  In the example, the initiator
   would include in TSi two traffic selectors: the first containing the
   address range (192.0.1.43 - 192.0.1.43) and the source port and IP
   protocol from the packet and the second containing (192.0.1.0 -
   192.0.1.255) with all ports and IP protocols.  The initiator would
   similarly include two traffic selectors in TSr.

   If the responder's policy does not allow it to accept the entire set
   of traffic selectors in the initiator's request, but does allow him
   to accept the first selector of TSi and TSr, then the responder MUST
   narrow the traffic selectors to a subset that includes the
   initiator's first choices.  In this example, the responder might
   respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and
   IP protocols.

   If the initiator creates the CHILD_SA pair not in response to an
   arriving packet, but rather, say, upon startup, then there may be no
   specific addresses the initiator prefers for the initial tunnel over
   any other.  In that case, the first values in TSi and TSr MAY be
   ranges rather than specific values, and the responder chooses a
   subset of the initiator's TSi and TSr that are acceptable.  If more
   than one subset is acceptable but their union is not, the responder
   MUST accept some subset and MAY include a Notify payload of type
   ADDITIONAL_TS_POSSIBLE to indicate that the initiator might want to
   try again.  This case will occur only when the initiator and
   responder are configured differently from one another.  If the
   initiator and responder agree on the granularity of tunnels, the
   initiator will never request a tunnel wider than the responder will
   accept.  Such misconfigurations SHOULD be recorded in error logs.

So my idea is to provide "enough" of the triggering packet to KMPs as:
 - this makes the first TS pair easy to build
 - with some decoding this makes the very special and specific
   Mobile IPv6 home registration binding update case easy to recognize
and with adding a small (at the exception of Linux) code in the kernel.

Thanks

---

From: Kazunori Miyazawa <[email-masked]>
Date: Thu, 08 Feb 2007 11:47:41 +0900

> and if yes if it needs its own document.

I still regard SADB_X_EXT_PACKET as excessive framework to just notify an
application of the CoA in Home Registration Binding Update.

But I considered SADB_X_EXT_PACKET all over again from the IPsec point of view,
especially in the case of PFP, as you mentioned. I get to consider it is kind of
reasonable for a SGW, which receives packets from other nodes.

So I decided to stop arguing at the moment.

Thank you for your time and patience.

--
Kazunori Miyazawa