Subject: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 17 Apr 2008 09:21:51 +0100

Hi all,

Here is the clarification text for IKEv2/IPSEC and DSMIPv6
interactions. In particular, the text clarifies the behavior when the
MN is connected to an IPv4 network, which RFC4877 does not cover.

Thanks to Pasi for his review and his help with defining the required
SPDs; also thanks to Wassim and Hesham for their review.
Hesham will fold the following text appropriately into the DSMIPv6
draft following a hopefully quick review from the group.

Best Regards
George
P.S.: I will have intermittent connectivity Friday-Sunday.

-----------------------------------------------------------------------------------------------------------------------
DSMIPv6 defines a number of possible data encapsulations depending on
the MN's connectivity and MN's and HA's configuration. These
encapsulations and the signaling required to establish them, are
straight forward when the MN is connected to an IPv6 capable network.
Some clarification is, however, needed for IKEv2/IPSEC operations when
the MN is connected to an IPv4-only network.

1. IKEv2 operation for securing DSMIPv6 Signaling over IPv4

RFC4877 defines how IKEv2 is used for Mobile IPv6 and RFC4306 includes
information about how IKEv2 runs over IPv4/UDP for NAT Traversal. A
DSMIPv6 MN connected to an IPv4-only network then,  needs to follow
the procedures described below.

To establish an SA for the protection of BU/BA messages, the DSMIPv6
MN and the HA SHOULD implement the following IKEv2 compatible
procedure:

        Mobile Node                      Home Agent
        -----------                      ----------
       IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
        UDP (500, 500) HDR, SAi1, KEi, Ni
          NAT-D, NAT-D -->
                            <--    IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
                                    UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ]
                                               NAT-D, NAT-D

        IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
        UDP (4500,4500) <non-ESP Marker> HDR, SK
           {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr}
                                -->

                              <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
                                   UDP (4500,Y) <non-ESP Marker> HDR*#, SK
                                       {IDr, [CERT,] AUTH, SAr2, TSi, TSr}

The SPDs are as shown in RFC 4877 Section 7.2.1

       mobile node SPD-S:
         - IF local_address = home_address_1 &
              remote_address = home_agent_1 &
              proto = MH & local_mh_type = BU & remote_mh_type = BAck
           Then use SA ESP transport mode
           Initiate using IDi = user_1 to address home_agent_1

       home agent SPD-S:
         - IF local_address = home_agent_1 &
              remote_address = home_address_1 &
              proto = MH & local_mh_type = BAck & remote_mh_type = BU
           Then use SA ESP transport mode

where home_address_1 is the MN's registered IPv6 home address and
home_agent_1 is the IP address of the home agent

The above should result in BU/BA messages with the following encapsulations:
   Binding update received by the home agent:
  IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
    UDP header (sport=X, dport=DSMIPv6)
      IPv6 header (src=V6HOA, dst=HAADDR)
        ESP Header in Transport Mode
          Mobility header
            BU [IPv4 HAO]
             IPv4 CoA option
		   (+ other as needed)

At the home agent, following UDP de-tunneling the Binding Update is
delivered to the IPSEC module as shown below:

       IPv6 header (src=V6HOA, dst=HAADDR)
         ESP Header in Transport Mode
           Mobility header
             BU [IPv4 HAO]
              IPv4 CoA option
                (+ other as needed)

The Binding Update following IPSEC processing is delivered to the
DSMIPv6 home agent module as follows:

       IPv6 header (src=V6HOA, dst=HAADDR)
         Mobility header
           BU [IPv4 HAO]
            IPv4 CoA option
              (+ other as needed)

The Binding Acknowledgement sent by the home agent module to the IPSEC
module is as follows:

        IPv6 header (src=HAADDR, dst=V6HOA)
            Mobility Header
              BA ([IPv4 ACK], NAT DET)
               (+ other as needed)

The Binding Acknowledgement send by the HA to the MN is as follows:

  IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
    UDP Header (sport=DSMIPv6, dport=Y)
       IPv6 header (src=HAADDR, dst=V6HOA)
         ESP Header in Transport Mode
           Mobility Header
             BA ([IPv4 ACK], NAT DET)

2. IKEv2 operation for securing DSMIPv6 Data over IPv4

To secure data traffic when the MN is located on an IPv4 only network,
the MN MUST establish a child_SA for that purpose. The procedure is as
follows:

        Mobile Node                      Home Agent
        -----------                      ----------
UDP (4500,4500) <non-ESP Marker> HDR, SK
   {[N], SA, Ni, [KEi],[TSi, TSr]}    -->

                                <-- UDP (4500,Y) <non-ESP Marker> HDR, SK
                                      {SA, Nr, [KEr], [TSi, TSr]}

If no NAT is detected, the encapsulation used will be:
   IPv4 (source_addr=v4CoA, dest_addr=HAAddr)
     ESP
      IP (source_addr=HoA, set_addr=CNAddr)
        Upper_layer_HDR
where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA

If NAT is detected, the encapsulation used will be
   IPv4 (source_addr=v4Addr, dest_addr=HAAddr)
      UDP (sport=X, dport=4500)
       ESP
         IP (source_addr=HoA, set_addr=CNAddr)
           Upper_layer_HDR
where v4CoA may be the external IPv4 address of the NAT, IP is either
IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA

The SPD for data decryption whether NAT is detected or not is set as
follows. Note that this rule is designed to match all data from the MN
to nodes other than the HA. This is done so that this rule does not
overlap with the earlier rule securing BU/BA signaling between the MN
and the HA.

      Mobile Node SPD-S:
	- IF local_address = home_address &
	     remote_address != home_agent &
           proto=any
	  Then use SA ESP tunnel mode
   	Initiate using IDi = user_1 to address home_agent_1

       home agent SPD-S:
      - IF local_address != home_agent &
              remote_address = home_address &
              proto = any
        Then use SA ESP tunnel mode

where home_address is the MN's registered IPv6 or IPv4 home address
and home_agent is the IPv6 or the IPv4 address of the home agent.
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 21 Apr 2008 19:21:54 +1000

Folks,

Does anyone have any comments on George's proposal below?  Please  
speak now because I want to update the draft and submit ASAP.

Hesham

---

From: "Premec, Domagoj" <[email-masked]>
Date: Mon, 21 Apr 2008 12:59:18 +0200

>         IP (source_addr=HoA, set_addr=CNAddr)
s/set_addr/dest_addr/
domagoj

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hesham Soliman
> Sent: 21. travanj 2008 11:22
> To: George Tsirtsis
> Cc: mext
> Subject: Re: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions
> 
> Folks,
> 
> Does anyone have any comments on George's proposal below?  
> Please speak now because I want to update the draft and submit ASAP.
> 
> Hesham
> 
> ----------------------------------------------------------------------
> > -------------------------------------------------
> >                                   UDP (4500,Y) <non-ESP 
> Marker> HDR*#, 
> > SK
> >                                       {IDr, [CERT,] AUTH, 
> SAr2, TSi, 
> > TSr}

---

From: <[email-masked]>
Date: Mon, 21 Apr 2008 14:50:47 +0200

A few comments.

As a result of section 1's IKE exchanges, the NAT box has the mappings

                                       new   new
          src   dst                    src   dst
         ----  ----                   ----  ----
    UDP   500   500    maps to    UDP    X   500
    UDP  4500  4500    maps to    UDP    Y  4500

The following BU and BA packets will then create the mapping

    UDP DSMIP DSMIP    maps to    UDP    Z  DSMIP

calling for a change in the UDP headers of the BU and BA packets.

For section 1's IKE exchanges, the following details might be considered

 * Use N(USE_TRANSPORT_MODE) 
 * Not clear what *# means in HDR*#
 * Have a statement, that the transport CHILD_SA might already have
   been made in the previous foreign network (v4 or v6), or might
   have been made proactively in the home network.  Thus the 
   illustrated exchange is only for the case of a full re-negotiation.
 * Although also used in RFC 4877, the 
   "local_mh_type = BU & remote_mh_type = BAck" cannot be true, as
   as only one MH type is supplied in a BU or BA.  Probably not
   worth to effort to change.

For section 2's IKE exchange, this exchange could also have been made
proactively, and then only require installation when moving to the
foreign IPv4 network.  Thus the illustrated exchange is only for the
case of re-negotiation.

Christian

> Behalf Of George Tsirtsis
> Sent: 17. april 2008 10:22
> To: mext
> Subject: [MEXT] IKEv2/IPSEC and DSMIPv6 interactions
> 
> Hi all,
> 
> interactions. In particular, the text clarifies the behavior 
> when the MN is connected to an IPv4 network, which RFC4877 
> does not cover.
> 
> Thanks to Pasi for his review and his help with defining the 
> required SPDs; also thanks to Wassim and Hesham for their review.
> Hesham will fold the following text appropriately into the 
> DSMIPv6 draft following a hopefully quick review from the group.
> 
> Best Regards
> George
> --------------------------------------------------------------
> ---------------------------------------------------------
> DSMIPv6 defines a number of possible data encapsulations 
> depending on the MN's connectivity and MN's and HA's 
> configuration. These encapsulations and the signaling 
> required to establish them, are straight forward when the MN 
> is connected to an IPv6 capable network.
> Some clarification is, however, needed for IKEv2/IPSEC 
> operations when the MN is connected to an IPv4-only network.
> 
> 
> RFC4877 defines how IKEv2 is used for Mobile IPv6 and RFC4306 
> includes information about how IKEv2 runs over IPv4/UDP for 
> NAT Traversal. A
> DSMIPv6 MN connected to an IPv4-only network then,  needs to 
> follow the procedures described below.
> 
> To establish an SA for the protection of BU/BA messages, the 
> DSMIPv6 MN and the HA SHOULD implement the following IKEv2 compatible
> procedure:
> 
>         Mobile Node                      Home Agent
>         -----------                      ----------
> Marker> HDR*#, SK
> SAr2, TSi, TSr}
> At the home agent, following UDP de-tunneling the Binding 
> Update is delivered to the IPSEC module as shown below:
> 
> The Binding Acknowledgement sent by the home agent module to 
> the IPSEC module is as follows:
> 
> To secure data traffic when the MN is located on an IPv4 only 
> network, the MN MUST establish a child_SA for that purpose. 
> The procedure is as
> follows:
> 
>         Mobile Node                      Home Agent
>         -----------                      ----------
> The SPD for data decryption whether NAT is detected or not is 
> set as follows. Note that this rule is designed to match all 
> data from the MN to nodes other than the HA. This is done so 
> that this rule does not overlap with the earlier rule 
> securing BU/BA signaling between the MN and the HA.
> 
>       Mobile Node SPD-S:
> where home_address is the MN's registered IPv6 or IPv4 home 
> address and home_agent is the IPv6 or the IPv4 address of the 
> home agent.

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 21 Apr 2008 14:04:57 +0100

Hi Christian,

Thanks for your comments, see inline...

>  As a result of section 1's IKE exchanges, the NAT box has the mappings

GT> It is not clear to me if the above is an observation or whether
you are suggesting something specific. I think the text already shows
all this and the fact that the UDP header changes (if NAT exists) does
not affect the IKEv2 SA for the BU/BA.

>   * Use N(USE_TRANSPORT_MODE)

GT> Use that where? the packet formats already indicate ESP Transport mode.

>   * Not clear what *# means in HDR*#

GT> The notation is used in RFC3947 to indicate a modified header and
I failed to remove it from one place as I copy/pasted text around, so
Hesham should remove the "*#".

>    illustrated exchange is only for the case of a full re-negotiation.

GT> I think you are right, this is worth adding.

>  foreign IPv4 network.  Thus the illustrated exchange is only for the

GT> Again, I agree.

Thanks
George

---

From: <[email-masked]>
Date: Mon, 21 Apr 2008 15:24:29 +0200

Thanks.  I have clarified my statements inline.
Christian 

> Sent: 21. april 2008 15:05
> To: Kaas-Petersen Christian
> Cc: [email-masked]
> you are suggesting something specific. I think the text 
> already shows all this and the fact that the UDP header 
> changes (if NAT exists) does not affect the IKEv2 SA for the BU/BA.
> 

In "1. IKEv2 operation for ..." I read the lines

 (a)   UDP(500,X) HDR, SAr1, KEr, Nr, ...
 (b)   UDP(4500,Y) <non-ESP Marker> HDR*#, SK...
 (c)   UDP header (sport=X, dport=DSMIPv6) ...
 (d)   UDP Header (sport=DSMIPv6, dport=Y)

and I asked myself, is the X in (a) the same X as in (c), and is
the Y in (b) the same as the Y in (d), and I believe
the answer is no (which I tried illustrate in the NAT table),
so I suggest X in (c) replaced by Z and the Y in (d) replaced by Z.

> GT> Use that where? the packet formats already indicate ESP 

Insert, such that

    IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
    UDP (4500,4500) <non-ESP Marker> HDR, SK
        {IDi, [CERT+], [CERTREQ+], [IDr], AUTH, N(USE_TRANSPORT_MODE),
         SAr2, TSi, TSr}

Christian

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 21 Apr 2008 14:30:37 +0100

OK I am fine with all of that. Hesham can incorporate all this in the draft.

Thanks
George

---

From: <[email-masked]>
Date: Tue, 22 Apr 2008 12:40:09 +0300

Looks quite good; couple of comments in-line:

> From: George Tsirtsis
> Sent: 17 April, 2008 11:22
> To: mext
> interactions. In particular, the text clarifies the behavior when
> the MN is connected to an IPv4 network, which RFC4877 does not
> cover.
> 
> includes information about how IKEv2 runs over IPv4/UDP for NAT
> Traversal. A DSMIPv6 MN connected to an IPv4-only network then,
> needs to follow the procedures described below.
> 

As Christian already pointed out, this needs N(USE_TRANSPORT_MODE).
Also, a sentence saying that the contents of TSi/TSr are described
below (in the SPD entries) wouldn't hurt.

>                               <-- IPv4(source_addr=HAADDR, 

N(USE_TRANSPORT_MODE) here, too (and just "HDR" instead of "HDR*#"?)

>         ESP Header in Transport Mode

Perhaps use sport=Z, since the port is not likely to be the same
as above?

>          ESP Header in Transport Mode

I would suggest explicitly saying that this packet comes with
additional information that is needed later to process the BU
correctly. E.g.
      
         + additional information: V4ADDR, Z
  
>        IPv6 header (src=V6HOA, dst=HAADDR)

         + additional information: V4ADDR, Z

>         IPv6 header (src=HAADDR, dst=V6HOA)

         + additional information: V4ADDR, Z, force vanilla UDP encaps

>          ESP Header in Transport Mode

dport=Z

> the MN MUST establish a child_SA for that purpose. The procedure is as

IP header should be shown here, too. TSi/TSr are not optional when 
creating  an ESP child SA, so remove the brackets [].

> IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA

sport=Y. Should also mention that this shows the packet as
seen by HA (not as sent by the MN).

> and home_agent is the IPv6 or the IPv4 address of the home agent.

Best regards,
Pasi