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

[Fernando Gont <[e-mail]>]

Hello, Ran!

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

On 20/11/18 13:27, R. Atkinson wrote:
> 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. :-)

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


> 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).

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



> 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:

Fine for me.




> 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).

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



> 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.

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492