Subject: [IPsec] yet more ikev2bis issues

From: Yoav Nir <[email-masked]>
Date: Wed, 10 Feb 2010 18:17:45 +0200

Hi all.

Again we have some more issues:

Issue #147 - Allowing limited retransmission of one-way IKE messages
====================================================================
Either in 2.1 or in 1.5 we should say something about allowing limited retransmission of the rare one-way IKE messages, for reliability.

How about the following new paragraph at the end of 2.1:
   The retransmission policy for one-way messages is somewhat different
   from that of regular messages. Since no acknowledgement is ever sent,
   there is no reason to gratuitously retransmit. Since all these 
   messages are errors, it makes sense to send them only once per
   "offending" packet, and retransmit is further offending packets are
   received. Still, it makes sense to limit retransmissions of such 
   error messages.

Issue #149 - Use of "SA" and "SA pair"
======================================
2.8: "The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the new SA." this should really be "...on the new SA's dual SA" (or better wording thereof) since there's a pair of SAs, and we are determining the state of one based on the other. In general I think we are using the terms SA and SA Pair interchangeably, which is rather confusing.

The term "dual SA" does not appear anywhere in the draft. OTOH section 1.4.1 has the term "half of an SA pair". How about
   The responder can be assured that the initiator is prepared to
   receive messages on an SA if either (1) it has received a
   cryptographically valid message on the other half of the SA 
   pair, or (2) ...

Issue #165 - Incorrect wording on Transform Attributes
======================================================
3.3.5: "Attributes described as fixed length MUST NOT be encoded using the variable-length encoding." This cannot be correct, a new 4-octet attribute will have to be encoded as variable-length. It won't fit into the other format.

I agree with this. How about:
   The only currently defined attribute type (Key Length) is fixed
   length; the variable-length encoding specification is included only
   for future extensions.  Attributes described as fixed length MUST NOT
   be encoded using the variable-length encoding, unless that length 
   exceeds two bytes. Variable-length attributes MUST NOT be encoded as
   fixed-length even if their value can fit into two octets.  NOTE: This 
   is a change from IKEv1, where increased flexibility may have 
   simplified the composer of messages, but certainly complicated the 
   parser.

Issue #166 - Clarify INVALID_SELECTORS notification
===================================================
3.10.1: INVALID_SELECTORS is underspecified. It should be rate limited (I suppose), also, how long is the packet fragment included in the notification? In addition, Sec. 2.21.2 implies that it is sent during Child SA negotiation, which is not what 3.10.1 is saying.

I'm pretty sure that this needs to be removed from 2.21.2, but we need alternative text suggestion for 3.10.1.

Issue #167 - IPv6 config attributes
===================================
3.15.1: "With IPv6, a requestor MAY supply the low-order address octets it wants to use." This means to me that you *don't* provide all 16 octets. But according to the table, the field is a fixed-length 16 octets!

Tero suggested we leave the text as-is, and live with the implication that you send the full 128 bits, with only the suffix meaningful (or the prefix being a suggestion). I'm fine with that, so unless someone objects...

Please send comments to the list.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Feb 2010 14:26:30 +0200

Yoav Nir writes:
> Either in 2.1 or in 1.5 we should say something about allowing
> limited retransmission of the rare one-way IKE messages, for
> reliability. 
> 

That text looks good.

> 2.8: "The responder can be assured that the initiator is prepared to
> cryptographically valid message on the new SA." this should really
> be "...on the new SA's dual SA" (or better wording thereof) since
> there's a pair of SAs, and we are determining the state of one based
> on the other. In general I think we are using the terms SA and SA
> Pair interchangeably, which is rather confusing. 
> 
> The term "dual SA" does not appear anywhere in the draft. OTOH
> section 1.4.1 has the term "half of an SA pair". How about 

"Other half" is ok, as would be leaving this text as it was, as I do
not think there is that big confusion about the issue.

> 3.15.1: "With IPv6, a requestor MAY supply the low-order address
> octets it wants to use." This means to me that you *don't* provide
> all 16 octets. But according to the table, the field is a
> fixed-length 16 octets! 
> 
> Tero suggested we leave the text as-is, and live with the
> implication that you send the full 128 bits, with only the suffix
> meaningful (or the prefix being a suggestion). I'm fine with that,
> so unless someone objects... 

Yes. If someone wants some better text to explain situation better,
then is better to provide text... 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Feb 2010 14:27:32 +0200

Yoav Nir writes:
> 3.3.5: "Attributes described as fixed length MUST NOT be encoded
> using the variable-length encoding." This cannot be correct, a new
> 4-octet attribute will have to be encoded as variable-length. It
> won't fit into the other format.

Yes, the fixed length should be changed to TV format. and
variable-length needs to be changed to TLV format.

>    simplified the composer of messages, but certainly complicated the 

I think it is better to change the way I proposed in the list earlier:

   The only currently defined attribute type (Key Length) is using TV
   encoding; the TLV encoding specification is included only for
   future extensions. Attributes described as using TV encoding MUST
   NOT be encoded using the TLV encoding. Attributes described as
   using TLV encoding MUST NOT be encoded as using TV encoding even if
   their value can fit into two octets. NOTE: This is a change from
   IKEv1, where increased flexibility may have simplified the composer
   of messages but certainly complicated the parser.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Feb 2010 14:27:55 +0200

Yoav Nir writes:
> 3.10.1: INVALID_SELECTORS is underspecified. It should be rate
> limited (I suppose), also, how long is the packet fragment included
> in the notification? In addition, Sec. 2.21.2 implies that it is
> sent during Child SA negotiation, which is not what 3.10.1 is
> saying. 
> 
> I'm pretty sure that this needs to be removed from 2.21.2, but we
> need alternative text suggestion for 3.10.1. 

Yes, it needs to be removed from 2.21.2.

As those incoming packets are already authenticated, the attack with
lots of packets having invalid selectors can only be done by the
authenticated entity, and it can only trigger one INVALID_SELECTORS
notification for each packet it sends (which will then require other
end to process that IKE message and send reply back).

Also as in normal case the IKE window is either 1 or quite small, that
means if there is lots of packets having invalid selectors, then there
will be automatic rate limitation, as the IKE SA window will be full
of those messages...

I do not really think we need to explictly mention that those packets
are rate limited as those are not unprotected packets which trigger
those errors to be sent.

I would expect most implementations already have internal rate
limitation between the (kernel) IPsec ESP packet processing engine and
the (usermode) IKEv2 module.

Also I do not necessarely see need for adding text about how much data
to include, as this data is mostly for debugging purposes only and
only for cases where either end is not following the specification
(i.e. are sending packets which were not agreed on before hand).

I do not really expect implementations to check the packet inside in
any other way than just to dump it to audit log or debugging console.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 11 Feb 2010 14:29:37 +0200

There's a typo in the proposed text to #147: "is further" -> "if further".

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tero Kivinen
> Sent: Thursday, February 11, 2010 14:27
> To: Yoav Nir
> Cc: 'ipsec'
> Subject: [IPsec] yet more ikev2bis issues
> 
> Yoav Nir writes: