Re: Last Call: <draft-ietf-opsec-ipv6-eh-filtering-06.txt> (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC

"R. Atkinson" <rja.lists@gmail.com> Tue, 20 November 2018 16:27 UTC

Return-Path: <rja.lists@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0B112F1AC; Tue, 20 Nov 2018 08:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 VKEf4Fdv70k5; Tue, 20 Nov 2018 08:27:09 -0800 (PST)
Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (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 BC15812008A; Tue, 20 Nov 2018 08:27:09 -0800 (PST)
Received: by mail-qk1-x742.google.com with SMTP id m5so3156686qka.9; Tue, 20 Nov 2018 08:27:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VvnzECN9hOH7wIN7pnjcUE/WUg8zQZf9H1jeqPkZ7Zs=; b=E/mcR3xT4A1HPGHWdGWyk7nAApCyluN141fCurQwxFCoA2UQpWTW93uYYQ/FSOj+mU C25Qd6AaTlvVmNH2vSPDSHAujo//QxSx9Ql1pdM1PhjFQ/DgmsUImfnIIGpNNqATf2mH scXzA0HNOgyaMTsKiuRSsCZKbAJ4VevWFj8oO/nT4Y7Jl1OzA50wtOUhCK8erjlkrd16 +TZU34HS0Fg0Re727jZiKSSzQGCo3M4CkMHXBZWIZWXryuYLRMfNwp+pSL1c6UGgYO6K WO+LB8ykWbT20hgbSWQyILv3O6gecsllxUTactVlhKg8z4anZOMOxKfLlzHoUrT1xDD3 +5KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VvnzECN9hOH7wIN7pnjcUE/WUg8zQZf9H1jeqPkZ7Zs=; b=Hv9CKm0yR4GaD386fTb7Bgx5v5hQvc1mxsrDKziaRe0Ybvv6Q+ruJSymPGi8BcfbF0 /OiTjyo4Ss+qbMDcpTJsV700IEL+sbY7nRLsg3K54RIbX4C6kAsr9ficPNjtFEcJCf0u CQ8fcjBGjc+zlxP/XtnNrv6qHkdeMp2khTxUzD9XI/T9rbnbplPh92AuQN8RpwqWmuik DypOfJlIV95Sx1pYwp5nWsUtwV+TfbVxl1AhbhLA7S9lbk7akc2Yyx3m4H25kSWQP6/X 0jZ85YIqqiFs8lrKBEM8kCAPFpt+RWiCHWrOCp72Q0lyy9AaBE5Hg5guuWic9t2DU5ec RqnA==
X-Gm-Message-State: AA+aEWbJ0lVwGrjjYBmBgOIy9FFAftOhzAbrS+Y5N0y3MGeFjWXI5rk8 OUjsyjicEe/OSzD6OopkUnvqiuSd
X-Google-Smtp-Source: AFSGD/U8wS82uAm/KpRKkI4B92mUfnIyOpX8PAh2bCupJVurRXVO10mXCwIZNwiLLIeoWt/zFBcufw==
X-Received: by 2002:a37:c3c3:: with SMTP id r64mr2365694qkl.70.1542731228627; Tue, 20 Nov 2018 08:27:08 -0800 (PST)
Received: from [10.30.20.5] (pool-72-83-171-117.washdc.east.verizon.net. [72.83.171.117]) by smtp.gmail.com with ESMTPSA id c49sm10038701qtc.94.2018.11.20.08.27.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 08:27:08 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: Last Call: <draft-ietf-opsec-ipv6-eh-filtering-06.txt> (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC
From: "R. Atkinson" <rja.lists@gmail.com>
In-Reply-To: <154264505944.5231.6349536976903745769.idtracker@ietfa.amsl.com>
Date: Tue, 20 Nov 2018 11:27:07 -0500
Cc: opsec@ietf.org, iesg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EB81EE5-C8C7-4B6A-9EF4-90B5049E5F88@gmail.com>
References: <154264505944.5231.6349536976903745769.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/KKyXXrvHa5r5mNcqlu_CbkktQmY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Nov 2018 16:27:12 -0000

All,

I believe this document needs a few very important, 
but hopefully not controversial edits before going ahead.  

(I had thought these concerns had been worked out previously, 
per email exchanges on the opsec list (and privately) circa 
6 July 2018 with Fernando Gont.  So I had expected to see a 
-07 revision appear with the agreed fixes, but maybe something 
fell through the cracks by accident. :-)

Comments below are organized by Document Section.

I am open to wordsmithing.  Candidate new text has been provided
for review (and ideally - to be adopted into a -07 revision).



DOCUMENT TITLE:  Recommendations on the Filtering of IPv6 Packets 
                                   Containing IP Extension Headers

REQUEST:

Could we somehow edit the title to make clear that these recommendations
are specifically focused on “Transit Routers” ?

REASONS:

The current document title is slightly misleading.  It implies the recommendations 
are entirely general, but actually (per the -06 Abstract) they are  "advice on the 
filtering of such IPv6 packets at transit routers for traffic *not* directed to them”.
Advice specific to a Transit Router might or might not apply to other IP router
deployments (e.g. inside an enterprise).



SECTION "2.3 Conventions"

EXISTING:

Such configuration options may include the following possible settings:

PROPOSED NEW:

Such configuration options SHOULD include the following possible settings:

REASONS:

1) Operational Considerations

If an implementer doesn’t include these configuration capabilities, then
operators might be left with interoperability issues and/or with an
inability to deploy IETF technologies — as is described later in Section
3.4.1.4.

2) Consistency with RFC 7045.




SECTION "3.4.1.5.  Advice"

EXISTING:

For legacy nodes, the recommended configuration for the processing of
these packets depends on the features and capabilities of the underlying platform.

PROPOSED NEW:

For legacy nodes, the recommended configuration for the processing of
these packets depends on the features and capabilities of the underlying platform,
the configuration of the platform, and also the deployment environment
of the platform.

REASONS:

Which configuration for processing of HBH options is reasonable depends
not only on the features/capabilities, but also how the system has actually
been configured (e.g. it might have enabled some feature that BREAKS
proper operation if all packets with HBH headers are dropped) and also
what kind of deployment environment it is in.   RSVP remains fairly
widely deployed and used today, although obviously it is not deployed
or used everywhere; RSVP would break.  Similarly, in an MLS deployment
environment, transmitting packets containing the CALIPSO HBH is
critical (more later on this).


Section "4.3.9.5.  Advice”

EXISTING:
   Intermediate systems that do not operate in Multi-Level Secure (MLS)
   networking environments should discard packets that contain this
   option.

PROPOSED:

  "Recommendations for handling the CALIPSO option depend  on the 
  deployment environment, rather than whether an intermediate system 
  happens to be deployed as a transit device (e.g., IPv6 transit router).

  Explicit configuration is the only method via which an intermediate system
 can know whether or not that particular intermediate system has been 
 deployed within a Multi-Level Secure (MLS) environment.  In many cases, 
 ordinary commercial intermediate systems (e.g., IPv6 routers & firewalls) 
 are the majority of the deployed intermediate systems inside an MLS 
 network environment.  

 For Intermediate systems that DO NOT implement RFC-5570, there 
 SHOULD be a configuration option to EITHER (a) drop packets containing 
 the CALIPSO option OR  (b) to ignore the presence of the CALIPSO option
 and forward the packets normally.  In non-MLS environments, such
 intermediate systems SHOULD have this configuration option set to (a)
 above.  In MLS environments, such intermediate systems SHOULD
 have this option set to (b) above.  The default setting for this configuration
 option SHOULD be set to (a) above, because MLS environments are much
 less common than non-MLS environments.

  For Intermediate systems that DO implement RFC-5570, there SHOULD 
 be configuration options (a) and (b) from the preceding paragraph and 
 also a third configuration option (c) to process packets containing
 a CALIPSO option as per RFC-5570.  When deployed in non-MLS
 environments, such intermediate systems SHOULD have this configuration
 option set to (a) above.  When deployed in MLS environments, such
 intermediate systems SHOULD have this set to (c).  The default setting
 for this configuration option MAY be set to (a) above, because MLS 
 environments are much less common than non-MLS environments.

REASONS:

In the global public Internet, the CALIPSO HBH option ought not appear,
so that is the most common case.  However, there are large multi-continent
networks (with multiple AS#s in use) that do carry explicit IP labels such
as CALIPSO.  The majority of forwarding devices (routers/gateways) in
such networks are ordinary commercial IP routers, while a much smaller
number of forwarding devices are specialized products.  So careful
recommendations will make a big difference in such deployments.
In those deployments, either dropping packets with a CALIPSO
HBH present or stripping the HBH header entirely could cause severe
operational problems — basically such behaviour would create an 
avoidable DOS attack.  Kindly note that anecdotal reports indicate that 
some financial firms have deployed the CALIPSO option to provide separation
of information flow between different groups (e.g. Trading Room staff
ought not be able to see Merger & Acquisition staff’s activity to comply
with securities regulations in multiple countries/economies).

Yours,

Ran Atkinson