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
