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

Alvaro Retana <aretana.ietf@gmail.com> Wed, 04 November 2020 20:56 UTC

Return-Path: <aretana.ietf@gmail.com>
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 AF74F3A0EC2; Wed, 4 Nov 2020 12:56:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.836
X-Spam-Level:
X-Spam-Status: No, score=-1.836 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=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 9AkJVnNjr3hR; Wed, 4 Nov 2020 12:56:55 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 E98FE3A0E82; Wed, 4 Nov 2020 12:56:54 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id e18so12788991edy.6; Wed, 04 Nov 2020 12:56:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=LVah7jyFH/O+MUdnVKgoiGI81/yDKzVhWum6rl9rbmw=; b=PiFhlnf5d9yrIAgIdbXaXySRzf2rCdkDHrbTzwUFtMxSw+27ilXNm35lr9zw3oZ6E4 z/jEZbZW5B2zWt/6sGDYvHickVl2hCjjMM1iE2LxLJevSPFkC0w045kF4hepFWrrneWv LGFY5aKKZUnmGW25ZiVnrDI1vEkF5SpZ2TQmntyt6c8CT2gbMYHCv4DfZomYwDI6Fbrn M7szQQftf2kURY3ZghNmL2NNcYflXIcAuTWRXJBjnsMtBOXgGM0WRRMxfKpt4cu8x+vR Zl/5FhOX3S02p4U6AXZ0H1M8X4JeBWr4mGmWuGSF28cMbbPIFDH+ZmBUd+udOTSceI0l +ZKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=LVah7jyFH/O+MUdnVKgoiGI81/yDKzVhWum6rl9rbmw=; b=iM1vurQwTK5LLt/aefJsIY6vMFwzRNIPXW3bGT3T+l0Hpwt3b0tyn7QaYXujcDLqe0 28PycXcm+a2bH8cqlf3HJU6/RN6sQ3eD+KZoA24WVOiZXyh1lUjPQy7ko7gbsEUZfBZ+ ZC3g35On54cR/d74Wt86FqUIr75xV0uybZ2OJj1BUvidmgt9L8+6KjknXoc20cd48Y+k tiGsgLEjhrBvgtxt30bVxJgTh6dIlfGRf4gg8qudBh7duQ0/54KM0dnF2+y+0TBVtZFx sUBeBW43fItUF9/JL4FaYPqlcpo5nagiReMtmS13jFhgbZC5W3UPzKAsZRfdmJoQO6Dv yT/g==
X-Gm-Message-State: AOAM533K9TbWjNObzUUw3p1BmSNxwJ9tJ2TUNwnV6CuzW3Kq7gw2F1E4 KUiR1ZPdKL6+q3/6YY5UfWSv3GoryxeXchBMi94=
X-Google-Smtp-Source: ABdhPJzvdCJip99U2HytNC/nC3SwZr9h0pzi5XuZdYm2h761sHk08GaRT1ilFE5puRmsbUBWidm4kIUmwcmj3kB2cBM=
X-Received: by 2002:aa7:ce8d:: with SMTP id y13mr30067377edv.65.1604523413474; Wed, 04 Nov 2020 12:56:53 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Nov 2020 12:56:52 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <0D408BA4-52EE-45CE-8884-91CDEE8995CF@tix.at>
References: <160442801878.21168.17412260809706411361@ietfa.amsl.com> <3C5BB93B-5E8C-42AD-B1C1-F96C359EC110@tix.at> <20201104163619.GR39170@kduck.mit.edu> <0D408BA4-52EE-45CE-8884-91CDEE8995CF@tix.at>
MIME-Version: 1.0
Date: Wed, 4 Nov 2020 12:56:52 -0800
Message-ID: <CAMMESszOcX=nw6U6prnXwZiONtFF5VJUc_HxiprYHHc0Mnko_w@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Christoph Loibl <c@tix.at>
Cc: draft-ietf-idr-flow-spec-v6@ietf.org, idr-chairs@ietf.org, The IESG <iesg@ietf.org>, idr@ietf.org
Content-Type: multipart/alternative; boundary="00000000000018116405b34e38e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/vIPvwBMuUoa1sDeo6XLwBhn4QtE>
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: Wed, 04 Nov 2020 20:56:57 -0000

Hi!

Yes, if that text works for Ben then we can still add it to rfc5575bis.

Thanks!

Alvaro.

On November 4, 2020 at 3:34:36 PM, Christoph Loibl (c@tix.at) wrote:

Hi Benjamin,

See my comments below (I stripped down the message, it only contains the
remaining issues).

@ Alvaro: Please also read my last question.


...


>>> Section 7
>>>
>>> It was a little surprising to me that the inability to match (e.g.) TCP
>>> flags or Port values on non-initial IP fragments was not reiterated in
>>> the security considerations of 5575bis. I don't think it would make
>>> sense to mention that just in this document's security considerations,
>>> though -- if we are to change anything it should be in 5575bis. But I
>>> guess we had that conversation already, at
>>> https://mailarchive.ietf.org/arch/msg/idr/zvpLPjllvKWFuyraZUVz8lB8Wz0/
>>> and thus no change is expected.
>>
>> While IPv4 and IPv6 fragmentation serves the same pupose the encoding is
different so we needed to redefine thi section. FS is working stateless on
the packets and can only match on what is in the packet.
>
> Exactly. I am proposing that this restriction (working stateless and
> cannot match [application-layer headers] things not in the packet) is
> mentioned again in the security considerations section. I believe that
> this limitation can be described in a way that is agnostic to IPv4 vs
IPv6,
> and thus would be better placed in 5575bis than in this document.

I agree that this should rather go into 5575bis than in this document.

I suggest to add the following to the Security Considerations section:

ADD:
Implementations may not be able to locate all header values
required to identify a packet. This can be especially problematic
in the case of fragmented packets that are not the first fragment
and thus lack upper-layer protocol headers or Encapsulating Security
Payload (ESP) NULL [RFC4303] encryption.

@ Alvaro do you think we should roll that paragraph into rfc5575bis?

Cheers Christoph

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