Re: [Lwip] [IPsec] Suggestions in draft-mglt-lwig-minimal-esp

"Valery Smyslov" <svanru@gmail.com> Thu, 20 July 2017 09:25 UTC

Return-Path: <svanru@gmail.com>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8206A13170E; Thu, 20 Jul 2017 02:25:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level:
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY6kucT1lhxq; Thu, 20 Jul 2017 02:25:39 -0700 (PDT)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD413127735; Thu, 20 Jul 2017 02:25:38 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id m86so2666943lfi.4; Thu, 20 Jul 2017 02:25:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=T1i4Y0mwbiItrBvNnkYpNF+H3oltPiOjGROoBuNbTpw=; b=EU3PgHk5nTUwJf18tR9lJOAP9W1mlAQc4UkBLNGEheXyi6ScoIuT45M2isnOBoIh4M XzSjhQZxPNJxvkIgvTRk+cKCxCSMyH+gSIiuQUISvsxNcvvAZP1DZPQg5eRDGV0b+qsm WluoemwjcyLDE8Ylzdmfnb7kF4rP10t8WVaCdNvbj+MEEdnfpjtJSRTuW06Atfb0+saq VKjXZunU6r24JfGXs2GjS0RxU5MTHrWT5iPH313QoP8NgYDxAQLS69YYl5OmYwdGKV7W czGceg5Bh75yg10gTHfYvKJrKFQ3FKsH44gEz4Q2htGqloEJ5iDZw8QANHMGmMqfy3pj iHbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=T1i4Y0mwbiItrBvNnkYpNF+H3oltPiOjGROoBuNbTpw=; b=Ml9/mzVG+Pyt2b7WJ2WMDraF8tXJg+PK9O3FtZUi//fcxFKIGwU8audyDS+Op5mr9v jqrBUyBgPbLVw/BqyngzjtkY1sAvUPk/uXY6tzym33s6b1Ozc3chHPziB1af87wg3YPP EqDoZA/dsfyXvDZdGOcOrLH0eIKClPjd+Ro3RVGoa+u8t1guUYRmiaGwzpf7NqIWNJhf tJxUqaoqNQnX5hH2JtBnSh+nYyElJ1h6J+C8jdnXpRlmbA2Aq6YFK0H61v36kSlISArP WKiIHVb2Zo85MYeM41MU3WQJCz3C7O/h4B8LLc/PLo/uUSM0RfDIKvp5LUhB+IBQddhs bjeg==
X-Gm-Message-State: AIVw111WOCbs5Wb8T/dn+Fr5RKm6LnbtngYPtSzX7xSe2FNY6xvtUP9y 7IjdqaPF9nI0DJra
X-Received: by 10.25.150.130 with SMTP id y124mr1001719lfd.202.1500542736804; Thu, 20 Jul 2017 02:25:36 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o82sm388850lfb.85.2017.07.20.02.25.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Jul 2017 02:25:35 -0700 (PDT)
From: Valery Smyslov <svanru@gmail.com>
To: 'Tobias Guggemos' <guggemos@nm.ifi.lmu.de>, 'Raja ashok' <raja.ashok@huawei.com>, draft-mglt-lwig-minimal-esp@ietf.org
Cc: 'IPsecme WG' <ipsec@ietf.org>, lwip@ietf.org
References: <FDFEA8C9B9B6BD4685DCC959079C81F5E22F9321@BLREML503-MBX.china.huawei.com> <002d01d30133$9895a460$c9c0ed20$@nm.ifi.lmu.de>
In-Reply-To: <002d01d30133$9895a460$c9c0ed20$@nm.ifi.lmu.de>
Date: Thu, 20 Jul 2017 12:25:37 +0300
Message-ID: <04ec01d3013a$2616dd80$72449880$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_04ED_01D30153.4B6BB6A0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLaRXNs9kiJ+OmSgshTmcu8j2ZopAKlDwEdoDi64wA=
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/HMRd5gtpTxl-N0RytMUvoKzG4JA>
Subject: Re: [Lwip] [IPsec] Suggestions in draft-mglt-lwig-minimal-esp
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Lightweight IP stack <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jul 2017 09:25:41 -0000

Hi,

 

IP fragmentation is a Bad Thing in general and it is better to

avoid it. With TCP traffic the TCP/IP stack

usually sends only unfragmented IP packets, so this is usually

not a problem (especially if you fool the stack that the MTU

is a bit smaller than real, so the packet is still within real MTU

size after applying ESP header/trailer/padding/ICV and external IP header).

 

The problem is worse with UDP. In this case it is an application

that decides how much data it wants to send in each datagram and there could

be fairly large UDP datagrams, that have to be IP fragmented.

In tunnel mode they can be either pre-fragmnted (before applying IPsec),

or post-fragmented (fragment the resulting ESP packet).

In transport mode it is not possible to pre-fragment packets.

 

In general, I think that pre-fragmenting is a bit better, than post-fragmenting.

So you’d better to apply ESP to each of IP fragments and send whole IP packets,

than apply ESP to a whole packet and then send it as a set of IP fragments.

In this case you at least verify each internal IP fragment on receiver,

before sending it to IP stack. In the other case you have to reassemble 

all the fragments before you can verify the ESP packet, and this gives

an attacker a nice target for DoS attack. However, the justification 

is weak, since the IP packets can always be fragmented en route (unless 

you set Don’t Fragment bit).

 

Regards,

Valery.

 

 

From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tobias Guggemos
Sent: Thursday, July 20, 2017 11:39 AM
To: 'Raja ashok'; draft-mglt-lwig-minimal-esp@ietf.org
Cc: IPsecme WG; lwip@ietf.org
Subject: Re: [IPsec] Suggestions in draft-mglt-lwig-minimal-esp

 

Hey Ashok,

thanks for your feedback.

For your first comment I tend to agree and I think we can add this to the draft!

For the second, I agree with your assumption that tunnels might appear in constrained scenarios (it’s actually one of our main
goals for ipsec/esp). However, I’m not sure if this recommendation to not use fragmentation is valid on a security side, why I’d
like to give the question to the ipsecme WG, if that does not open any other security issues? Or if there is anything else to
consider on that?

Thanks

Tobias

 

Von: Raja ashok [mailto:raja.ashok@huawei.com] 
Gesendet: Freitag, 14. Juli 2017 16:22
An: draft-mglt-lwig-minimal-esp@ietf.org
Cc: lwip@ietf.org
Betreff: Suggestions in draft-mglt-lwig-minimal-esp 

 

Hi Daniel & Tobias,

 

I gone through the lwIG draft for ESP. I am having some doubts and suggestions which are listed below. Please check and provide your
comments.

 

1)     For replay protection, RFC 4303 suggests to use 32 or 64 bit window. I feel in this draft, we can recommend to use 32 bit
window for replay protection.

 

2)     Tunneled ESP msg with fragmented IP header (in ESP payload) may leads to DoS vulnerability for a constraint receiver. RFC
4303 is suggesting this fragmentation as optional. So I feel we can mention as fragmentation and reassembly is not required to
support in tunneled IP header. As it can be handled by the IP header which carries ESP msg. I hope tunneled ESP msg might be
required in some scenarios of constraint devices also.

 

Regards,

Ashok

 

  _____  

Company_logo

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com 

  _____  

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!