IETF Logo Mail Archive

Re: [Idr] [BULK] Benjamin Kaduk's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

Christoph Loibl <c@tix.at> Mon, 16 November 2020 09:59 UTC

Return-Path: <c@tix.at>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C963A1703; Mon, 16 Nov 2020 01:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at
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 pPjnQJj461sq; Mon, 16 Nov 2020 01:59:26 -0800 (PST)
Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::22]) (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 8DCF53A16C8; Mon, 16 Nov 2020 01:59:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=5GXdvvxlho9sCtjHFxL9/OZUd4Bskwnp7iA7xz7EXq8=; b=PDuwCQpq37iEcMu0vqg1fwhKMD +i3kf40Qil8fVbR3lCGCKSZ5h9t4faw1iDRfSDzz3c/VE42eK8ILszgryVIhVR8faRkNRlmtOBhGI Lkh227131t27DLe/nRoLn3ki1FI445xHaccvNqBWFpdJ21KYcm2GjDNNxkoJY3kWhvyBbhu2Wn7xO Uq71Bp9pWZxAQSuRef/aGZ5T6FbB9AaZTKFkJIGIjPPYTbqCiNNi7i9O5Mh6kB+5FaHcuFeTYZsGQ jceR2Vux3eJUO5aPqAGblQv0Ptf7ZGWa/8udafrIk/fdLHNv/rr6+GB577LVJ3HP/Xu+nbdC63ls1 aS4lH6nw==;
Received: from 80-110-113-91.cgn.dynamic.surfer.at ([80.110.113.91] helo=[192.168.66.207]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <c@tix.at>) id 1kebI7-0001fL-HP; Mon, 16 Nov 2020 10:59:20 +0100
From: Christoph Loibl <c@tix.at>
Message-Id: <A7DA0A78-228D-4D76-80E1-7FEC6525804D@tix.at>
Content-Type: multipart/alternative; boundary="Apple-Mail=_306A83A1-E9B0-484A-9FDB-4BDC7EC78EF4"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 16 Nov 2020 10:59:15 +0100
In-Reply-To: <20201116094249.GC12209@pfrc.org>
Cc: Benjamin Kaduk <kaduk@mit.edu>, "idr@ietf. org" <idr@ietf.org>, draft-ietf-idr-flow-spec-v6@ietf.org, Robert Raszuk <robert@raszuk.net>, idr-chairs@ietf.org, The IESG <iesg@ietf.org>, Erik Kline <ek.ietf@gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
References: <E70A15BB-5C6C-447A-832C-571D413139E3@tix.at> <20201109205805.GY39170@kduck.mit.edu> <20201116080901.GI2881@pfrc.org> <20201116075756.GQ39170@kduck.mit.edu> <828ACEB0-C1D8-4A83-AED5-7B9F300F0421@tix.at> <20201116094249.GC12209@pfrc.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Mon, 16 Nov 2020 10:59:19 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LG-VgzT5JQ-yVaatjGd7OETxUiQ>
Subject: Re: [Idr] [BULK] Benjamin Kaduk's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 09:59:34 -0000

Hi,

> On 16.11.2020, at 10:42, Jeffrey Haas <jhaas@pfrc.org> wrote:
> 
> Remind me, is there procedure handling improper values for the length of the
> component semantics?
> 
> E.g. ports can only be 2 bytes of value. 
> 
> I have a feeling this is in the base procedures of "this can't match, so
> it's not a problem" but I'm not finding it right now.

In case of the port component, the numeric operator does lt, gt, eq comparisons between the port in the packet and the value followed by the operator. This is independent on the encoding. Only that the port can never exceed the 16bit boundary. While the value from the operator technically can and will, depending on the operator (gt,lt,eq), even match packets. 

Cheers Christoph

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

v2.28.0 | Report a Bug | By Email | System Status