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" <[email-masked]>
Date: Tue, 20 Nov 2018 11:27:07 -0500

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Nov 2018 17:51:33 -0300

Hello, Ran!

Thanks so much for your comments! Inline....

> fell through the cracks by accident. :-)

It may have been my failure. If that was the case, please accept my
apologies.

> deployments (e.g. inside an enterprise).

I have no problem with updating the title as suggested. Chairs: May I go
ahead and apply it?

> Such configuration options SHOULD include the following possible settings:

Fine for me.

> critical (more later on this).

Makes sense. Maybe we could add your paragraph on "REASONS" as a
parenthetical (indented) note?

>  environments are much less common than non-MLS environments.

Also makes sense. Unless somebody screams agains, I will apply the
suggested edit.

Thanks a lot for your continued help in improving documents!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "R. Atkinson" <[email-masked]>
Date: Thu, 22 Nov 2018 09:21:03 -0500

> On Nov 21, 2018, at 15:51, Fernando Gont <[email-masked]> wrote:
> 

We are all busy and I understand that things do sometimes fall through
cracks.  So long as we can apply the agreed edits now, I’m quite happy.

> parenthetical (indented) note?

I’m flexible about editing text.  I supplied candidate text primarily to be
clear about what edits I hope to see.  Feel free to add it as a note or
simply to edit the key points into the candidate text to create suitable
new text.

> Also makes sense. Unless somebody screams agains, I will apply the

Thank you very much - and a Happy Thanksgiving [1] to all.

Yours,

Ran

[1] A quaint North American holiday, celebrated today in the US and 
     celebrated last month in Canada.