Re: [IPsec] IKE fragmentation

"Valery Smyslov" <svanru@gmail.com> Wed, 13 March 2013 14:31 UTC

Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E6F21F8DEB for <ipsec@ietfa.amsl.com>; Wed, 13 Mar 2013 07:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.948
X-Spam-Level:
X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=2.651, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jTvKCnO9Qqu for <ipsec@ietfa.amsl.com>; Wed, 13 Mar 2013 07:31:05 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1CA121F8DDD for <ipsec@ietf.org>; Wed, 13 Mar 2013 07:31:04 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id n8so1000665lbj.31 for <ipsec@ietf.org>; Wed, 13 Mar 2013 07:30:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=u6xTTP5OACqjacGXWTpAdqb8eKXXryillQ2WYv81np4=; b=MeJ+a1ZKBYyK0xrq0UjEzxQ3rSzxdLJK+CPhaC6cowvHTuX0ze7nq+zE9240mUDAV6 2ed5BXiNxoBaRyd+xNIGQ+EloqrEcT7sKQTlSiLBB5E1hnWDK7hQSNABv1yyqSPzHnQ0 Xh8mYRX6RS24uvRXSxbE6z6RopaGTwMdUiG5DmsR2nY2bPM5jDJPWUDSxJF5DMAdOQ2M +eAkt356FdKSUU2JuKMe9ZRYopDitnHzlZmw56t8K56VCB6MX0fNULef1RjvKFcwvKKb laKTKl5up8Hmvqh2GMRb/OJR24rnEIMRs22N396A9k3eVEbZVnBGNTOuBiyBOfMMIB8Y aEYA==
X-Received: by 10.152.104.199 with SMTP id gg7mr17645363lab.14.1363185059558; Wed, 13 Mar 2013 07:30:59 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id fm8sm6975556lbb.17.2013.03.13.07.30.57 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Mar 2013 07:30:58 -0700 (PDT)
Message-ID: <4C4F5DE0838E4DCFBAE31A02D7ED5D33@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Paul Wouters" <paul@nohats.ca>
References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <alpine.LFD.2.03.1303130941040.27437@nohats.ca>
Date: Wed, 13 Mar 2013 18:31:12 +0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Cc: ipsec@ietf.org, Tero Kivinen <kivinen@iki.fi>
Subject: Re: [IPsec] IKE fragmentation
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2013 14:31:06 -0000

Hi Paul,

>> As for IKEv2, I don't know how Cisco is doing fragmentation in this case
>> (it seems to have support for it), but if it is done similarly to IKEv1,
>> than I prefer our own solution - 
>> draft-smyslov-ipsecme-ikev2-fragmentation.
>> The main difference is that in Microsoft/Cisco solution (for IKEv1)
>> the whole encrypted ISAKMP message is fragmented,
>> leaving each fragment unauthanticated untill message get reassembled
>> and its authentity could be verivied. This opens door for
>> a very simple DoS attack on receiver.
>
> How is that a DOS attack? In our implementation of the IKEv1
> fragmentation, we limit the number of fragments to 16. We will
> only need to do any crypto when we received the IKE packet
> marked as "last". Then we do crypto once on the assembled packet
> and throw it away when crypto fails.

If attacker sends you a forged fragment, you cannot determine this
untill you get reassembled the whole message. When you determine
this you have to discard all received fragments (as you don't know
which of them is bogus) and wait for retransmission. For attacker
it is enough to send you forged fragments with rather low rate
to have a good chance to prevent you from communication with your peer.

I think this is kind of DoS attack as Initiator is denied to get desired 
service (IPsec).

>> In our proposal each fragment is encrypted and authenticated
>> individually, that allows receiver to distinguish valid fragments
>> from bogus, thus preventing from abovementioned DoS attack.
>
> But I can send lots of small forged fragments and you will do lots
> of crypto on them for _each_ forged fragment. I think you will end
> up using a lot more cpu and the attacker needs a lot less bandwidth.

ICV check is (must be) very fast, and you cannot avoid this attack
even without fragmentation - attacker can send you
forged regular messages and you will have to do ICV check
for each of them. I don't think fragmentation makes this worse.

> I actually do like the IKEv1 version. It's very simple. And uses
> the exact same code path apart from a little buffer where we store
> some fragments (with sane limits). The only oddness is that
> fragmentation ID that serves no purpose, as you cannot really have
> two different packets fragmented in flight for a single exchange.
> (well you can, but they are going to be identical anyway)
>
> While implementing the IKEv1 version, I did wonder about what should
> trigger fragmentation. For instance, if both parties have send and
> received the vendorid, and one side sends fragments, should the
> other side fully indepedantly wait for failure/retransmit before
> using fragments, or take the hint that if the path is broken one
> way, it is likely broken in the other way as well? It seems that
> being a little aggressive here can really help the IPsec SA to
> establish much faster - especially since our own retransmit time
> is 20 seconds, which is something we are now consideraing lowering
> a lot.

I think that responder should start replying with fragments
immediately after it receives first fragmented message from initiator,
but not before this event. It is initiator who is responsible
for retransmissions and it is his/her responsibility to
switch on fragmentation.

> Our implementation also does not handle the first packet of an
> exchange to be fragmented, because we have no state to store the
> fragments for. In practise this does not matter because the first
> packet is never large enough to need fragmentation.

We do the same.

> Paul

Regards,
Valery.