Subject: [nemo] IPsec for payload packets

From: Takaaki Moriya <[email-masked]>
Date: Thu, 15 Dec 2005 22:09:21 +0900

Hi all,

I'm new of this mailing list.
I have a question related to IPsec for payload packets.

RFC3963 refers to RFC3776 concerning the use of IPsec to protect Mobile
IPv6 signaling messages as follows.

> All signaling messages between the Mobile Router and the Home Agent
> MUST be authenticated by IPsec [8]. The use of IPsec to protect
> Mobile IPv6 signaling messages is described in detail in the HA-MN
> IPsec specification [2]. The signaling messages described in this
> document extend Mobile IPv6 messages and do not require any changes
> to what is described in [2].

As for payload packets, when ingress interface of Mobile Router is used
for its Home Address, I think that SPD/SAD for payload packets are
naturally configurated as follows.

--------------------------------------------------
| SPD             |          |  SRC     |  DST    |
---------------------------------------------------
| SA7 [MR -> HA]  |  Outer   |  MR_CoA  |  HA     |
|                 |  Inner   |  MNP     |  any    |
--------------------------------------------------
| SA8 [HA -> MR]  |  Outer   |  HA      |  MR_CoA |
|                 |  Inner   |  any     |  MNP    |
--------------------------------------------------

However, when eggress interface of Mobile Router is used for its Home
Address, I think that the following policies are needed in addition to
the above SA7 and SA8. For example, they might be used when Mobile
router itself sends some messages to CN. Is it correct ?

--------------------------------------------------
| SPD             |          |  SRC     |  DST    |
---------------------------------------------------
| SA9?[MR -> HA]  |  Outer   |  MR_CoA  |  HA     |
|                 |  Inner   |  MR_HoA  |  any    |
--------------------------------------------------
| SA10?[HA -> MR] |  Outer   |  HA      |  MR_CoA |
|                 |  Inner   |  any     |  MR_HoA |
--------------------------------------------------

I wonder some implementations might not need these additional policies
(SA9 and SA10), because they can cover these SA9 and SA10 just by using
the existing SA7 and SA8.

Thank you very much in advance.

Best Regards,
Takaaki Moriya

------------------------------------------------------------
Takaaki MORIYA
NTT Network Service Systems Laboratories, NTT Corporation, Japan
TEL: +81-422-59-2848
FAX: +81-422-59-5631
E-mail: [email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 15 Dec 2005 16:16:52 +0100

In your previous mail you wrote:

   
=> note you have at least 3 very different things:
 - what is possible in theory with RFC 2401 and IKEv1 (as these
   documents are not coherent and clearly incompatible, this can
   become a bit hairy :-)
 - what is possible in theory with 2401bis and IKEv2 (previous issues
   are supposed to have been fixed but)
 - what is possible in practice with the IPsec/IKE implementation
   you have (I consider you have the common Linux 2.6 (aka USAGI) /
   BSD (aka KAME) implementation which is well known).

   > to what is described in [2].
   
=> this is a quote from RFC 3963.
   
   As for payload packets, when ingress interface of Mobile Router is used
   for its Home Address, I think that SPD/SAD for payload packets

=> precision: "payload packets" are not always all/any protocol
(in RFC 3776 section 5.2.4 for instance you have "proto = X")

   are naturally configurated as follows.

=> these are tunnel mode SPD entries so the selectors are *only*
on the inner header. To make this works, i.e., to take the
outer header into account, the RFC 3776 uses the interface stuff
(fortunately only in examples :-).
   
   However, when eggress interface of Mobile Router is used for its Home
   Address, I think that the following policies are needed in addition to
   the above SA7 and SA8. For example, they might be used when Mobile
   router itself sends some messages to CN.

=> you may have narrower SPD entries with a higher priority, in fact,
if the traffic payload matches the signaling but with a lower security
level, you must have them (i.e., 5.2.2 has to take precedence over
5.2.4, and 5.3.2 over 5.3.4). Note that the match here is true only
when X = any (2401bis/IKEv2 is more complex but the requirement is
the same).

   Is it correct ?
   
=> yes, you may have other SPD entries...

   
=> I have to understand that "cover" can make things simpler but can
break the security too. This is a basic issue in IPsec policies: when
they overlap the strong one must be used for the intersection.

Regards

[email-masked]

---

From: Takaaki Moriya <[email-masked]>
Date: Tue, 27 Dec 2005 19:23:15 +0900

Hello Francis,

Thank you very much for your advice, and I am really sorry that I could
not reply you sooner.

I understand what you mean, but I have been considering this issue from
the viewpoint of interoperability.

Even though it is an instance, RFC 3776 section 5.2.4 mentions the
payload packets as "proto = X".  In this instance, I thought that such
additional entries(i.e. "SA9 and SA10") may be needed if eggress
interface of Mobile Router is used for its Home Address.

I mean, since RFC3963 just refers to RFC3776 regarding IPsec, I wonder
whether all the developers can expect the same (or equivalent) SPD
entries. Some people might expect such "SA9 and SA10", and others might
not.

I would appreciate it if you would let me know or would advise me.

Best Regards,
Takaaki Moriya

On Thu, 15 Dec 2005 16:16:52 +0100

-- 
Takaaki Moriya <[email-masked]>

---

From: Francis Dupont <[email-masked]>
Date: Sat, 31 Dec 2005 11:59:09 +0100

=> the answer is simple: the policies (I use this term because the formal
SPD entries don't include common things like SA sharing control) must
match or something will fail. So when there are possible choices (and
when you consider SA sharing issues there are likely some) one must
take care to configure compatible policies...
   
   entries.

=> no but all the developers should propose enough or it will be possible
to find no compatible policies...
   
Regards

[email-masked]