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: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
