Subject: [mobile-ip] IKE question: How should HA know the 'if interface=tunnel interface...'

From: "Jimmy Zhang" <[email-masked]>
Date: Sun, 1 Jun 2003 08:02:20 -0700

Hi, 

We have the following policy table: (cited from mipv6haipsec draft #5)

"
  mobile node SPD OUT:
    - IF interface = IPv6 tunnel to home_agent_1 &
         source = home_address_1 & destination = any &
         proto = MH
      THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
                              local phase 1 identity = user_1

  home agent SPD IN:
    - IF interface = IPv6 tunnel from home_address_1 &
         source = home_address_1 & destination = any &
         proto = MH
      THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
                              peer phase 1 identity = user_1
"

When mobile node initiates IKE phase 2 negotiation with HA to establish
the IPsec SA for return routability test, it only sends information like
source, destination and protocol to HA in IKE message phase 2 ID
payload. The MN has the HOTI packet to trigger this negotiation, so MN
has its own way from HOTI to determine the interface information. 

However, how should HA know the interface part "IF interface = IPv6
tunnel from home_address_1"?

If HA doesn't know this information, it is very likely to pick the wrong
policy, and will reject the security association proposals.

Thanks,

Jimmy
http://www.elmic.com

---

From: Francis Dupont <[email-masked]>
Date: Sun, 01 Jun 2003 23:50:39 +0200

=> we (authors) had a long discussion about the "interface" issue but
with no conclusion because according to the RFC 2401, SPDs are per
interfaces... Fortunately this part of the document is only an example,
the mandatory specification is the packet layouts and the behaviors,
so it is not critical to get a perfect wording here (but if you
have suggestions...).

Regards

[email-masked]

---

From: "Jimmy Zhang" <[email-masked]>
Date: Sun, 1 Jun 2003 18:59:52 -0700

Yes, according to RFC 2401, SPDs are per interface, however, that is
REAL interface. It is very natural to have different SPDs on different
interfaces because you are going to send & receive on different
interface too. If you send/receive packet on interface 1, you must use
SPD of interface 1; if you send/receive packet on interface 2, you must
use SPD of interface 2. I don't think RFC 2401 allows us to send/receive
packet on interface 1, however apply the SPD of interface 2. 

'SPDs are per interface' is true, I think, only when you send/receive
per interface. If you send/receive on the same interface, but want to
apply different SPDs, the peer has no way to determine which interface
you are talking about, given the current IKE message exchanges.

Here our situation is that, we are going to send/receive packet on home
agent's one same interface (the interface IKE runs on), however,
sometimes we need apply the real interface SPD, such as the policy to
protect BU and BA, and sometimes we need apply the virtual interface SPD
such as the policy to protect HOTI and HOT, IMHO, IKEv1 just doesn't
have that luxury to tell which is which. The only information IKE phase
2 responder knows are source address/source port, destination
address/destination port, protocol, there is no interface. This question
is not perfect wording or not, but doable or not doable.

We should at least add one notify payload to IKEv1. The purpose of this
notify payload is to let the peer know that 'this SA proposal is not for
the interface on which you receive this negotiation, but some interface
else, please query your SPD of that interface before you reject me'. We
extend the idea of proxy negotiation here to include proxy service for
another interface. When the peer receives this notification, it knows
that it should query the SPD of that mentioned interface, and then
process the SA proposal accordingly.

Proxy service for different interfaces is maybe useful for IPsec/IKE
itself too, especially for router which may have multiple SPDs for
multiple interfaces.

Just my wide ideas,

with best regards,

Jimmy

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Sunday, June 01, 2003 2:51 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [mobile-ip] IKE question: How should HA know the 
> 'if interface=tunnel interface...' 
> 
> 
>  In your previous mail you wrote:
> 
> => we (authors) had a long discussion about the "interface" 
> issue but with no conclusion because according to the RFC 
> 2401, SPDs are per interfaces... Fortunately this part of the 
> document is only an example, the mandatory specification is 
> the packet layouts and the behaviors, so it is not critical 
> to get a perfect wording here (but if you have suggestions...).
> 
> Regards
>

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 3 Jun 2003 09:39:23 -0700

Jari & list -

I've discussed this in some depth with Jin Zhang (his desk is approx. 15
feet from mine ;-), we looked at the detailed discussion logged between
Jari, Francis, etc. for issue #306 to understand more of the background.
I agree with Jin, the basic problem with using IKE to protect payload
packets and return routability tunneled between the MN and the HA is:

When the MN initiates IKE, it has the packet that triggered IKE,
therefore it knows what interface it is sending that packet on
(specifically, the MN-to-HA tunnel interface).

However, on the receiving end of this scenario (i.e. the HA), when it
recieves the IKE proposal from the MN, the HA does not have the packet
that triggered IKE (since that is a packet the MN is sending, and IKE
hasn't completed yet for that packet to be sent), therefore it doesn't
know that it should be looking up interface-specific SPD entries on the
HA-to-MN tunnel interface to prepare the response to the MN's IKE
proposal, as Francis said:

"=> the only issue with this is the SPD is applied to the wrong
interface:
on a HA the SPD must be applied to the home link interface, *not* to the
HA-MN tunnel interface."

This is the crux of the problem. In the case of manual keying, both the
MN and the HA have the packet (there is no IKE negotiation required
first, to setup to use the SAs), therefore it is possible in the manual
keying case for both the HA and the MN to be able to identify the
sending interface for the packet as being the HA-to-MN (or MN-to-HA)
tunnel and use the interface-specific SPD entries. So, with manual
keying, this complex SPD scenario described in
draft-ietf-mobileip-mipv6-ha-ipsec-05.txt to protect payload and return
routability packets tunneled between the MN and the HA is workable
albeit painful for those of us whose IPsec implementations do not
currently support interface-specific SPD entries.

Thanks.
- Ed Remmell
Elmic Systems, USA
http:/www.elmic.com

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jimmy Zhang
> Sent: Sunday, June 01, 2003 7:00 PM
> To: [email-masked]
> Subject: RE: [mobile-ip] IKE question: How should HA know the 
> Yes, according to RFC 2401, SPDs are per interface, however, 
> that is REAL interface. It is very natural to have different 
> SPDs on different interfaces because you are going to send & 
> receive on different interface too. If you send/receive 
> packet on interface 1, you must use SPD of interface 1; if 
> you send/receive packet on interface 2, you must use SPD of 
> interface 2. I don't think RFC 2401 allows us to send/receive 
> 'SPDs are per interface' is true, I think, only when you 
> send/receive per interface. If you send/receive on the same 
> interface, but want to apply different SPDs, the peer has no 
> way to determine which interface you are talking about, given 
> the current IKE message exchanges.
> 
> Here our situation is that, we are going to send/receive 
> packet on home agent's one same interface (the interface IKE 
> runs on), however, sometimes we need apply the real interface 
> SPD, such as the policy to protect BU and BA, and sometimes 
> we need apply the virtual interface SPD such as the policy to 
> protect HOTI and HOT, IMHO, IKEv1 just doesn't have that 
> luxury to tell which is which. The only information IKE phase 
> address/destination port, protocol, there is no interface. 
> This question is not perfect wording or not, but doable or not doable.
> 
> We should at least add one notify payload to IKEv1. The 
> purpose of this notify payload is to let the peer know that 
> 'this SA proposal is not for the interface on which you 
> receive this negotiation, but some interface else, please 
> query your SPD of that interface before you reject me'. We 
> extend the idea of proxy negotiation here to include proxy 
> service for another interface. When the peer receives this 
> notification, it knows that it should query the SPD of that 
> mentioned interface, and then process the SA proposal accordingly.
> 
> Proxy service for different interfaces is maybe useful for 
> IPsec/IKE itself too, especially for router which may have 
> multiple SPDs for multiple interfaces.
> 
> Just my wide ideas,
> 
> with best regards,
> 
> Jimmy
> 
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.486 / Virus Database: 284 - Release Date: 5/29/2003
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.486 / Virus Database: 284 - Release Date: 5/29/2003

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 3 Jun 2003 10:22:18 -0700

typos in draft-ietf-mobileip-mipv6-ha-ipsec-05.txt:

sections 5.3.2 "Return Routability Signaling" and 5.3.4 "Payload
Packets" have come incorrect verbage, from section 5.3.2:

"  mobile node SPD OUT:

  mobile node SPD IN:
    - IF interface = IPv6 tunnel from home_agent_1 &
         source = any & destination = home_address_1 &
         proto = MH
      THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
                              local phase 1 identity = user_1

  home agent SPD OUT:
    - IF interface = IPv6 tunnel to home_address_1 &
         source = any & destination = home_address_1 &
         proto = MH
      THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
                              peer phase 1 identity = user_1

  home agent SPD IN:
    - IF interface = IPv6 tunnel from home_address_1 &
         source = home_address_1 & destination = any &
         proto = MH
      THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
                              peer phase 1 identity = user_1"

In the case of mobile node SPD IN, "outer destination = home_agent_1"
for the ESP tunnel is incorrect, the source (not destination) address in
the outer tunnel header is home_agent_1 and the outer destination is the
MN's care-of address.
In the case of home agent SPD OUT, "outer destination = home_address_1"
is incorrect, this should be the MN's care-of address. In the case of
home agent SPD IN, "outer destination = home_address_1" is incorrect,
the source address in the outer tunnel header is the MN's care-of
address (not home_address_1) and the outer destination is home_agent_1.

Section 5.3.4 has the same problems.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

---

From: Francis Dupont <[email-masked]>
Date: Wed, 04 Jun 2003 12:03:42 +0200

=> they are not typos, they are side-effects of the "interface =
IPv6 tunnel" stuff...

=> the traffic filter is for the inner header. I share your concern
but we have no good solution because of the per-interface SPD requirement
of RFC 2401.

=> same cause, same effect.

Thanks

PS: this is in fact an IPsec issue: this should be discussed and if
possible solved in/by the IPsec WG.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 04 Jun 2003 15:55:40 +0200

=> I agree: the packet is produced by the mobility code and we can
assume some kind of ad-hoc processing.

   
=> I haven't changed my mind: the real problem is the spurious
"per-interface SPD" requirement and its strange (IMHO) interpretation.

=> such implementations are not conformant... But the issue is not
a mobility issue, as Jin and me have discussed, IPsec/IKE has the same
issue in a dynamic environment, for instance when one can't assume
the incoming interface of all traffic.

Thanks

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 4 Jun 2003 17:43:40 -0700

Francis -

> => I haven't changed my mind: the real problem is the 
> spurious "per-interface SPD" requirement and its strange 
> (IMHO) interpretation.
> 
> => such implementations are not conformant... But the issue 
> is not a mobility issue, as Jin and me have discussed, 
> IPsec/IKE has the same issue in a dynamic environment, for 
> instance when one can't assume the incoming interface of all traffic.

I was thinking about this some more... and I have an idea:

When the MN does IKE with the HA for the purpose of securing Return
Routability, it uses its home address as the source address for the IKE
exchange. This causes the IKE exchange to use the MN-to-HA tunnel.

When the HA then receives the IKE proposal from the MN, it will have
been tunneled to the HA over the MN-to-HA tunnel. The HA can then detect
that the MN's IKE proposal was received on this tunnel interface, and
then the HA uses that information when creating the SAs associated with
this IKE exchange to create them in the per-interface SPD associated
with the MN-to-HA tunnel interface. So, the fact that the IKE is
tunneled over the MN-to-HA tunnel indicates to the HA that the SAs
created by that IKE exchange should be scoped to that tunnel interface.

Thanks.
- Ed Remmell
Elmic Systems USA, Inc.

Best of Show Winner, ESC 2003
Click on the link and take a look!
http://cmp.iconvention.com/escshowdaily/v33/index.cvn?ID=10183

---

---

From: Francis Dupont <[email-masked]>
Date: Sun, 08 Jun 2003 15:40:09 +0200

=> this doesn't work because IKE will establish the SAs with
the home address in the external header when we want the care-of address.
And the IKE exchange won't use the MN-to-HA tunnel because the HA
is a CN (so packets will get a HAO or a RH2).

Regards

PS: there is no problem other than the wording: the home registration BU
has set the proper SPD entry (it comes from the care-of address so from
the right interface).

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 9 Jun 2003 10:04:15 -0700

Frances -

> the home address in the external header when we want the 
> care-of address. And the IKE exchange won't use the MN-to-HA 
> tunnel because the HA is a CN (so packets will get a HAO or a RH2).

Yes, you are correct.

Thanks.
- Ed

---

---

From: Jari Arkko <[email-masked]>
Date: Sat, 28 Jun 2003 22:50:16 +0300

(Returning to this old issue.)

I realize the decision is problematic for the home agent.
But I'd like to note that there appears to be enough
information in the IKE proposal packets to make the
decision, assuming the implementation can take advantage
of this. Section 4.4 states the following:

       The security associations for protecting Binding Updates and
       Acknowledgements are requested for the Mobility header protocol in
       transport mode and for specific IP addresses as endpoints.  No
       other selectors are used.  Similarly, the security associations
       for protecting prefix discovery are requested for the ICMPv6
       protocol and the specific IP addresses, again without other
       selectors.  Security associations for payload and return
       routability protection are requested for a specific tunnel
       interface and either the payload protocol or the Mobility header
       protocol, in tunnel mode.  In this case one requested endpoint is
       an IP address and the other one is a wildcard, and there are no
       other selectors.

That is, the proposals will be different in other respects
as well as the interface. But it does require some support
from the implementation.

My proposal is that we should let this suffice for the
moment. There's going to be opportunities for creating
a tighter, better integration to IKE in the future, such
as when we define how Mobile IPv6 and IKEv2 should work
together.

--Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 30 Jun 2003 16:53:15 -0700

Jari -

Well, seeing how there doesn't appear to be a good alternative (besides
waiting for IKEv2), I guess we don't have much choice.

Thanks.
- Ed

> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Saturday, June 28, 2003 12:50 PM
> To: Ed Remmell
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; 'Odile Lapidus'
> information in the IKE proposal packets to make the decision, 
> assuming the implementation can take advantage of this. 
> Section 4.4 states the following:
> 
> as when we define how Mobile IPv6 and IKEv2 should work together.
> 
> --Jari
> 
> 
> ---

---