Subject: [IPsec] Comments to the draft-nir-ipsecme-erx-07.txt

From: Tero Kivinen <[email-masked]>
Date: Sun, 4 Nov 2012 04:26:44 +0200

In Introduction section (1) there is text saying:

----------------------------------------------------------------------
   Bringing these two technologies together allows a remote access IPsec
   client to create multiple tunnels with different gateways that belong
   to a single domain, as well as using the keys from other contexts of
   using EAP, such as network access within the same domain, to
   transparently connect to VPN gateways within this domain.
----------------------------------------------------------------------

I think that is missing one possible use for the EAP Re-authentication
Protocol, then one that has been proposed for example in the IEEE
802.11ai. I.e the possibility that the client does full EAP with AAA
backend only once, and then reuses that authentication later to
recreate the IPsec connection when it was lost for some reason
(network problems, device suspending, going out of range etc).

I.e. use it in similar ways as resumption protocol can be used, but
now the state is stored in the AAA backend, not in the SGW.

In section "3. Protocol Outline" there is text saying:

----------------------------------------------------------------------
   The responder sends the EAP payload content to a backend AAA server,
   and receives the rMSK and an EAP-Finish/Re-auth message.  It then
   forwards the EAP-Finish/Re-auth message to the Initiator in an EAP
   payload within the first IKE_AUTH response.
----------------------------------------------------------------------

There is possibility that even when the client has ERX connection
still up, but the backend AAA server might have already destroyed it.
This means that it is possible that when initiator sends the first
EAP_Initiate/Re-Auth message to the SGW, which forwards it to the AAA
server, the AAA server will NOT respond with EAP-Finish/Re-auth
message, but simply starts normal full EAP. This should be explained
here. It does not really change the actual protocol flow, as AAA
server will send EAP packet back, and then the initiator and responder
will exchange some number of EAP packets before responder sends the
EAP-Finish to initiator and they do the final AUTH exchange.

If it is not mentioned here, some implementations might assume they
always get EAP-Finish/Re-auth back and not work if the AAA server goes
through the full EAP exchange.

In section "4. ERX_SUPPORTED Notification" there is text saying:

----------------------------------------------------------------------
   o  Protocol ID (1 octet) MUST be 1, as this message is related to an
      IKE SA.
----------------------------------------------------------------------

This is wrong. The RFC 5996 in section 3.10 says:

----------------------------------------------------------------------
   o  Protocol ID (1 octet) - If this notification concerns an existing
      SA whose SPI is given in the SPI field, this field indicates the
      type of that SA.  For notifications concerning Child SAs, this
      field MUST contain either (2) to indicate AH or (3) to indicate
      ESP.  Of the notifications defined in this document, the SPI is
      included only with INVALID_SELECTORS and REKEY_SA.  If the SPI
      field is empty, this field MUST be sent as zero and MUST be
      ignored on receipt.
----------------------------------------------------------------------

I.e. the Protocol ID MUST be sent as zero if the SPI field is empty. 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Sun, 4 Nov 2012 22:53:20 +0200

I have forwarded this to the IETF, and left out the IPsec mailing list on purpose, so that future messages are not copied here.

Please reply to that list.

Yoav

Begin forwarded message:

From: Yoav Nir <[email-masked]<mailto:[email-masked]>>
Subject: Re: Comments to the draft-nir-ipsecme-erx-07.txt
Date: November 4, 2012 3:52:21 PM EST
To: Tero Kivinen <[email-masked]<mailto:[email-masked]>>, IETF list <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]> Wu" <[email-masked]<mailto:[email-masked]>>

Forwarding to the IETF mailing list, which is the proper home for this discussion.

On Nov 3, 2012, at 10:26 PM, Tero Kivinen wrote:

I.e. the Protocol ID MUST be sent as zero if the SPI field is empty.
--
[email-masked]<mailto:[email-masked]>

Scanned by Check Point Total Security Gateway.