Subject: [IPsec] Review of section 1 of the draft-ietf-ipsecme-ikev2bis-06.txt

From: Tero Kivinen <[email-masked]>
Date: Thu, 14 Jan 2010 14:05:23 +0200

This is my first part of my review of ikev2bis document. This includes
changes based on going through section 1.

----------------------------------------------------------------------
Section 1 defines following terms: IKE SA, Child SA, message, request,
response, and exchange. The document uses sometimes "reply" instead of
"response", so I think it should be consistent in its use of terms.
This means that following uses of "reply" should be changed to
"response".

- Section 1.4.1 Deleting an SA with INFORMATIONAL Exchanges
  change
  
  "Normally, the reply in the INFORMATIONAL exchange will contain
   delete payloads for the paired SAs going in the other direction"

  with

  "Normally, the response in the INFORMATIONAL exchange will contain
   delete payloads for the paired SAs going in the other direction"

- Section 2.1. Use of Retransmission Timers
  change

  "IKE is a reliable protocol, in the sense that the initiator MUST
   retransmit a request until either it receives a corresponding reply
   OR it deems the IKE security association to have failed and it
   discards all state associated with the IKE SA and any Child SAs
   negotiated using that IKE SA. "

  with
  
  "IKE is a reliable protocol, in the sense that the initiator MUST
   retransmit a request until either it receives a corresponding
   response OR it deems the IKE security association to have failed
   and it discards all state associated with the IKE SA and any Child
   SAs negotiated using that IKE SA. "

- Section 2.6.  IKE SA SPIs and Cookies
  change

  "An attacker can forge multiple cookie responses to the initiator's
   IKE_SA_INIT message, and each of those forged cookie replies will
   trigger two packets: one packet from the initiator to the responder
   (which will reject those cookies), and one reply from responder to
   initiator that includes the correct cookie."

  with

  "An attacker can forge multiple cookie responses to the initiator's
   IKE_SA_INIT message, and each of those forged cookie replies will
   trigger two packets: one packet from the initiator to the responder
   (which will reject those cookies), and one response from responder
   to initiator that includes the correct cookie."

- Section 2.23.1.  Transport Mode NAT Traversal
  change

  "When the client receives the server's reply to the Child SA, it will
   do similar processing."

  with

  "When the client receives the server's response to the Child SA, it
   will do similar processing."

  and change

  "If transport mode for the SA was selected (that is, if the server
   included USE_TRANSPORT_MODE notification in its reply):"

  with

  "If transport mode for the SA was selected (that is, if the server
   included USE_TRANSPORT_MODE notification in its response):"

- Section 3.15.1.  Configuration Attributes
  change

  "INTERNAL_IP4_NETMASK - The internal network's netmask. Only one
   netmask is allowed in the request and reply messages"

  with

  "INTERNAL_IP4_NETMASK - The internal network's netmask.  Only one
   netmask is allowed in the request and response messages"

  and change

  "Note that no recommendations are made in this document as to how an
   implementation actually figures out what information to send in a
   reply."

  with

  "Note that no recommendations are made in this document as to how an
   implementation actually figures out what information to send in a
   response."

- Section 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET
  change

  "A different possible reply would have been this:"

  with

  "A different possible response would have been this:"

  and change

  "That reply would mean that the client can send all its traffic
   through the gateway, but the gateway does not mind if the client
   sends traffic not included by INTERNAL_IP4_SUBNET directly to the
   destination (without going through the gateway)."

  with

  "That response would mean that the client can send all its traffic
   through the gateway, but the gateway does not mind if the client
   sends traffic not included by INTERNAL_IP4_SUBNET directly to the
   destination (without going through the gateway)."

  and change

  "then the gateway's reply might be:"

  with

  "then the gateway's response might be:"

- Section 4.  Conformance Requirements
  change

  "Every implementation MUST be capable of responding to an
   INFORMATIONAL exchange, but a minimal implementation MAY respond to
   any INFORMATIONAL message with an empty INFORMATIONAL reply"

  with

  "Every implementation MUST be capable of responding to an
   INFORMATIONAL exchange, but a minimal implementation MAY respond to
   any INFORMATIONAL message with an empty INFORMATIONAL response"

In other cases the "reply" should be kept as it is now, as it does not
refer response message.

----------------------------------------------------------------------

The document also uses both "Child SA" and "IPsec SA" quite often, and
I think they are meant to mean same...

----------------------------------------------------------------------

In section 1.2 there is one instance of "IKE_INFORMATINAL exchange",
which should be "INFORMATIONAL exchange" instead.

----------------------------------------------------------------------

In section 1.3 at the end there is text talking about the
NO_ADDITIONAL_SAS. The current text is in the generic CREATE_CHILD_SA
section thus it covers all 3 use cases for CREATE_CHILD_SA (creating
new IPsec SAs, rekeying old IPsec SAs and rekeying IKE SA). The text
there is written to cover only new IPsec SAs, but I think it should
also cover rekeying IKE SA cases (section 4 conformance requirements
makes it quite clear you can return NO_ADDITIONAL_SAS to any
CREATE_CHILD_SA exchange including IKE SA rekey).

This means the text should be changed from

   The responder sends a NO_ADDITIONAL_SAS notification to indicate that 
   a CREATE_CHILD_SA request is unacceptable because the responder is
   unwilling to accept any more Child SAs on this IKE SA.  Some minimal
   implementations may only accept a single Child SA setup in the
   context of an initial IKE exchange and reject any subsequent attempts
   to add more.

To

   The responder sends a NO_ADDITIONAL_SAS notification to indicate that
   a CREATE_CHILD_SA request is unacceptable because the responder is
   unwilling to accept any more Child SAs on this IKE SA. This notify can
   also be used to reject IKE SA rekey. Some minimal implementations may
   only accept a single Child SA setup in the context of an initial IKE
   exchange and reject any subsequent attempts to add more.

----------------------------------------------------------------------

Section 1.3.1 now talks about the USE_TRANSPORT_MODE,
ESP_TFC_PADDING_NOT_SUPPORTED and NON_FIRST_FRAMENTS_ALSO notifications,
and says they can be included, but the packet figure does not include
them. Adding them to the figure would be easy, but the problem is that we
currently say that you should follow the order of payloads from the
figures (altough we do refer to section 2 not section 1, but this is one
of the open issues).

So depending what we decided on the payload order and figures, it might
be better to add one extra ", [N]" to the figure before SA payload.

Also there is one more notify payload which can be included and which
affect negotiation, i.e. the IPCOMP_SUPPORTED notification which is
covered in the 2.22. Perhaps forward reference should be added to there.

Also the section 1.3.1 has text which perhaps should be removed:

   Failure of an attempt to create a Child SA SHOULD NOT tear down the
   IKE SA: there is no reason to lose the work done to set up the IKE
   SA.  When an IKE SA is not created, the error message return SHOULD
   NOT be encrypted because the other party will not be able to
   authenticate that message.  See Section 2.21 for a list of error
   messages that might occur if creating a Child SA fails.

This section 1.3.1 is talking about the CREATE_CHILD_SA not initial
IKE_AUTH, thus this section is not needed here. The section 1.2 already
has text about the Child SA failing during the initial exchange, so this
how paragaraph needs to be removed.

----------------------------------------------------------------------

Section 1.3.3 should make it clear that the first N payload in the figure
is the N(REKEY_SA), i.e the diagram should be changed to:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SK {N(REKEY_SA), SA, Ni, [KEi],
       TSi, TSr}   -->

Also this section should say that other notifications explained in the
1.3.1 can also be included in this exchange, i.e. if transport mode SA
was rekeyed then this CREATE_CHILD_SA rekeying that SA needs to include
USE_TRANSPORT_MODE notification. Some kind of reference back to the 1.3.1
should be enough.

----------------------------------------------------------------------

Section 1.4 says that

	INFORMATIONAL exchanges MUST ONLY occur
   after the initial exchanges and are cryptographically protected with
   the negotiated keys.

This does not match the 1.5 which says we can send INFORMATIONAL
exchanges also outside the IKE SA.

Perhaps this needs to be changed to:

	Normally INFORMATIONAL exchanges MUST ONLY occur
   after the initial exchanges and are cryptographically protected with
   the negotiated keys (see Section 1.5 for exceptions).

----------------------------------------------------------------------

Section 1.5 needs some reordering and the text in section 1.5 vand 2.21.4
needs to be combined, now we have about the same text in two places.

The first paragraph of the 1.5 talks about the INVALID_IKE_SPI even
though it does not say it explictly, the second paragraph talks about
INVALID_SPI and then in third paragraph it says that "there are two cases
when one-way message is sent: INVALID_IKE_SPI and INVALID_SPI", just like
this would be new thing, but the previous paragraphs have already talked
about this. This is confusing, so I think this section requires bit of
reordering and rewording. Also it might be useful to actually move all
this text to section 2.21.4 and remove this whole section (remember
to update references).

Especially the fact that exchange type is copied from the request in
the INVALID_IKE_SPI case is missing from the 2.21.4 and should be
added there and also the last paragraph about INVALID_SPI text in the
1.5 is something that is not that clearly explained in the 2.21.4 so
that also needs to be kept (and/or moved).

----------------------------------------------------------------------

Section 1.6 is way too far from the beginning. We have already used
those terms 40 times before this section comes up, so it would be much
better that this section would be in the beginning of the document,
not at the page 20... Perhaps it should be moved to subsection 1.0.1
and move other defined terms there too.
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 14 Jan 2010 11:34:30 -0500

> exchanges also outside the IKE SA.

I think that section 1.5 is pretty careful to distinguish between 
informational messages (sent outside the IKE SA) and informational 
exchanges (which occur only within the context of an IKE SA).  I'm 
inclined to keep the Section 1.4 text as it is.  If you prefer, though, 
I'd be ok with clarifying Section 1.4 to say "INFORMATIONAL exchanges (to 
be distinguished from INFORMATIONAL messages sent outside the context of 
an IKE SA) . . ."

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:
Tero Kivinen <[email-masked]>
To:
[email-masked]
Date:
01/14/2010 07:06 AM
Subject:
[IPsec] Review of section 1 of the      draft-ietf-ipsecme-ikev2bis-06.txt

 

  with

  with

  with

  with

  and change

  with

  with

  and change

  with

  with

  and change

  with

  and change

  with

  with

To

   Initiator                         Responder

Section 1.4 says that

Section 1.6 is way too far from the beginning. We have already used
those terms 40 times before this section comes up, so it would be much
better that this section would be in the beginning of the document,
not at the page 20... Perhaps it should be moved to subsection 1.0.1
and move other defined terms there too.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 15 Jan 2010 10:31:17 +0200

> be distinguished from INFORMATIONAL messages sent outside the context of 

That change looks even better than my proposed one...
-- 
[email-masked]

---

From: Raj Singh <[email-masked]>
Date: Sat, 16 Jan 2010 17:52:04 +0530

*
*

*
*

Section 1.2.  The Initial Exchanges

   Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
   exchanges (known in IKEv1 as Phase 1).  These initial exchanges
   normally consist of four messages, though in some scenarios that
   number can grow.  All communications using IKE consist of request/
   response pairs.  We'll describe the base exchange first, followed by
   variations.  The first pair of messages (IKE_SA_INIT) negotiate
   cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
   exchange [DH
<http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-05#ref-DH>].

It would be better to say

   Communication using *IKEv2* always begins with IKE_SA_INIT and IKE_AUTH
   exchanges (known in IKEv1 as Phase 1).  These initial exchanges
   normally consist of four messages, though in some scenarios that
   number can grow.  All communications using IKE consist of request/
   response pairs.  We'll describe the base exchange first, followed by
   variations.  The first pair of messages (IKE_SA_INIT) negotiate
   cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
   exchange [DH
<http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-05#ref-DH>].

Even though IKE has been used before this section where it is meant as
IKEv2. So, also we can say like. "IKE and IKEv2 has been used
interchangeably".

But some place IKE is refer'd as generic protocol. So, mentioning IKE,
IKEv1 and IKEv2 need to be done.

Thanks & Regards,

Raj