IETF Logo Mail Archive

[IPsec] Regarding max limit of payloads to avoid unwanted processing.

Tero Kivinen <kivinen@iki.fi> Wed, 22 February 2017 14:30 UTC

Return-Path: <kivinen@iki.fi>
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 546F8129979 for <ipsec@ietfa.amsl.com>; Wed, 22 Feb 2017 06:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
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 lKTrbUguNFrX for <ipsec@ietfa.amsl.com>; Wed, 22 Feb 2017 06:30:38 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6276912999C for <ipsec@ietf.org>; Wed, 22 Feb 2017 06:30:38 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v1MEUOgP008905 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Feb 2017 16:30:24 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v1MEUNTY014246; Wed, 22 Feb 2017 16:30:23 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22701.41087.295109.746640@fireball.acr.fi>
Date: Wed, 22 Feb 2017 16:30:23 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Sandeep Kampati <sandeepkampati@huawei.com>
In-Reply-To: <2DA788A5A7D91747AEA54B502558D738269FA622@DGGEMM506-MBS.china.huawei.com>
References: <CAHbuEH4K1MW8BitnOtmpoHwU6ZseqwNkYQTJ_YUE6cYxH9cshg@mail.gmail.com> <alpine.LRH.2.20.1702171211350.17106@bofh.nohats.ca> <CAHbuEH4f_67DKywJNL=POTu-dF8Ewb7T0aYO6U=uxAd6ocxGKA@mail.gmail.com> <2DA788A5A7D91747AEA54B502558D738269FA622@DGGEMM506-MBS.china.huawei.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 6 min
X-Total-Time: 8 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/x2DglAoD2i2UCppWajzOqcGenEI>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "ynir.ietf@gmail.com" <ynir.ietf@gmail.com>
Subject: [IPsec] Regarding max limit of payloads to avoid unwanted processing.
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Feb 2017 14:30:40 -0000

Sandeep Kampati writes:
> 3.5.  Identification Payloads
> 
> ID_IPV4_ADDR                        1
>       A single four (4) octet IPv4 address.
> 
> Questions:  do we need to consider "single four (4) octet IPv4
> address"  as MUST point and reject the packet if we receive more
> length for it. 
> 
> For security reason we want to add restriction the payloads what we
> received, and reject packet if we receive more length  
> 
> Ex:  Identification Payloads ID Type : 1) ID_IPV4_ADDR ->A single
> four (4) octet  2) ID_IPV6_ADDR-> A single sixteen (16) octet 

The Identification Payload ID is used to search the matching policy
from the PAD, and as your PAD most likely will not add any other
lengths for the IP-addresses than 4 and 16 octets, then you can
immediately know that the matching policy will not be found from the
policy so you can reject it immediately.

The proper error code would most likely be INVALID_SYNTAX (as the ID
payload does not match the specified syntax, and if someone sends 5
octets for IPv4 address there is clearly a bug in their
implementation, and changing policy will not help)...
-- 
kivinen@iki.fi

v2.23.0 | Report a Bug | By Email