Subject: Re: [IPsec] Security consideration for DTLS: Adversarial packet loss/reordering

From: Yaron Sheffer <[email-masked]>
Date: Fri, 11 Feb 2011 23:05:38 +0200

Hi Steve,

[Cross-posted to ipsecme]

I have always wondered about these sequence numbers, and the concept of 
anti-replay in IPsec.

- IPsec is architecturally a "plug-in replacement" for IP. And IP allows 
for arbitrary packet deletion, duplication and reordering.
- Anti-replay counters are giving us no end of trouble in clustered 
environments (e.g. 
http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ipsecha-protocol/).
- IPsec (unfortunately) does not have an application API, at least in 
most implementations. Such an API might indeed have put this feature to 
good use.
- And lastly, IPsec anti-replay is optional, which signifies to me that 
it's always been an iffy feature.

I have looked at RFC 4301 again (the IPsec architecture), and it 
provides only weak justification for this feature. Can you please point 
me to a more convincing reasoning?

Thanks,
	Yaron

> ------------------------------
>
> Message: 2
> Date: Thu, 10 Feb 2011 19:51:08 -0500
> From: Steven Bellovin<[email-masked]>
> Subject: Re: [TLS] Security consideration for DTLS: Adversarial packet
> 	loss/reordering
> To: Eric Rescorla<[email-masked]>
> Cc: Paul Hoffman<[email-masked]>, [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Feb 10, 2011, at 3:03 21PM, Eric Rescorla wrote:
>
>> On Thu, Feb 10, 2011 at 12:03 PM, Eric Rescorla<[email-masked]>  wrote:
>>> On Thu, Feb 10, 2011 at 11:31 AM, Paul Hoffman<[email-masked]>  wrote:
>>>> On 2/10/11 9:49 AM, Matt McCutchen wrote:
>>>>>
>>>>> Here's an issue that might be worth adding as a security consideration
>>>>> in the next version of the DTLS specification.  It may affect IPsec too;
>>>>> I haven't looked into that.  Thoughts?
>>>>
>>>> I disagree with this suggestion, at least as it is proposed.
>>>>
>>>>> DTLS does not prevent an attacker from dropping or reordering records.
>>>>> Datagram applications are generally designed to tolerate random packet
>>>>> loss and reordering, but care must be taken to ensure that adversarial
>>>>> loss and reordering cannot break the desired higher-level security
>>>>> properties.
>>>>
>>>> That "care" sounds like it is care in the DTLS-using protocol, but no
>>>> suggestion is given how such a protocol can show care. This makes the
>>>> suggestion little more than "be careful", which is not useful.
>>>
>>> DTLS does deliver order information, of course. It just doesn't impose
>>> reordering.
>>>
>>> Perhaps the take-home for DTLS itself is that it would be nice if
>>> packets came with
>>> their sequence numbers attached.
>>>
>>
>> In the API, I mean.
>>
> Given the importance of sequence numbers for IPsec, I very much agree.
>
>
> 		--Steve Bellovin, http://www.cs.columbia.edu/~smb
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Feb 2011 11:34:26 -0500

At 11:05 PM +0200 2/11/11, Yaron Sheffer wrote:
>I have always wondered about these sequence numbers, and the concept 
>of anti-replay in IPsec.
>
>- IPsec is architecturally a "plug-in replacement" for IP. And IP 
>allows for arbitrary packet deletion, duplication and reordering.
>- IPsec (unfortunately) does not have an application API, at least 
>in most implementations. Such an API might indeed have put this 
>feature to good use.
>- And lastly, IPsec anti-replay is optional, which signifies to me 
>that it's always been an iffy feature.
>
>provides only weak justification for this feature. Can you please 
>point me to a more convincing reasoning?
>
>Thanks,
>	Yaron

Can any Steve reply?

While IP allows arbitrary packet arrival, IPsec allows a receiver to limit
the extent of such OOO arrival, to enable it to detect and reject 
replay attacks. That is the rationale for AR and it is just as 
applicable in a clustered receiver context as in a single receiver 
context.

The fact that it is optional to use (not to implement) is NOT an 
indication that it is "iffy." It is an indication that not all apps 
might require its use, and some might find it in conflict with the 
app. That is a app-specific decision, not a decision to be made by an 
IPsec vendor. Use of this feature is declared via the SAD, so an 
administrative interface is one way to specify use of this feature 
based on the protocol and port #'s.

I'm sorry that AR is causing problems in clustered contexts, but that is not a
justification to not support it.

Steve