Subject: [OPSEC] Erik Kline's No Objection on draft-ietf-opsec-ipv6-eh-filtering-08: (with COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Wed, 30 Jun 2021 22:03:48 -0700

Erik Kline has entered the following ballot position for
draft-ietf-opsec-ipv6-eh-filtering-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[S1] [nit]

* "some of the measured packet drops be the result" ->
  "some of the measured packet drops are the result", I think

[S2.3] [comment]

* "o  Discard (and log) packets containing" ->
  "o  Drop (and log) packets containing"

  since the subsequent bullet is about "Reject", and discard is defined
  to mean either drop or reject...I think it only makes that this bullet
  be about dropping a packet.

* "Ignore this IPv6 EH or option type ... and forward the packet"

  I think this might want to say "process the packet according rules
  for the remaining headers" or something, rather than just "forward
  the packet".

  Basically, if the packet would, for example, match some other firewall
  deny rule based on its transport header, that behaviour should be applied
  in this particular case where the IPv6 EH/option is configured to be
  ignored (rather than just saying "and forward the packet").

[S4.3.9.4] [comment]

* It seems fairly clear from RFC 5570 Security Considerations that a
  CALIPSO option is best protected with an AH, and in such cases stripping
  the CALIPSO option would cause the packet to fail validation at the
  (suitably configured) destination.

  Similarly, it might be good to note in S4.3.9.5 that if an AH is present
  presumably the advice from S3.4.5.5 applies.