Subject: [OPSEC] Additional corrections for draft-ietf-opsec-ip-options-filtering

From: RJ Atkinson <[email-masked]>
Date: Tue, 12 Jun 2012 09:36:12 -0400

1) Incorrect Advice in Section 4.22.5

The advice in Section 4.22.5 is incorrect, and simply will create
pressure by experimenters to obtain unique experimental IP option
allocations.   This is not helpful from a security perspective.
It also is not helpful from a standards perspective, as it creates
pressure to allocate unique permanent option numbers to experiments
that might have a relatively short lifetime.

Such options normally will be ignored by routers, gateways, or other
devices that don't recognise them -- as required already by both 
RFC-1122 and RFC-1812 -- and as widely implemented in deployed 
IP routers.  

These experimental IP options do NOT create any new security risk.  
So the correct Advice is for devices that don't recognise such 
IP options to ignore the presence of those options when forwarding 
or otherwise handling the packets.

This correction to the text in 4.22.5 is entirely consistent
with the existing text in Section 4.23 about handling for
other "unrecognised IP options".

2) Incorrect reference for RFC-1108.

The expansion of the reference for RFC-1108 is wrong.  The title
for that RFC is much longer.  This problem has been noted in the
past without actually being corrected.

If this is a "tools problem", then please either pick different 
tools, cause the tools problem to be fixed, or find a manual fix 
for the problem.  A manual fix might be required in the near-term.
Reviewers deserve to be able to read the whole correct citation.

3) Incorrect Reference for [FIPS1994]

This entry should read instead:

[FIPS1994]
             US National Institute for Standards and Technology, 
             "Standard Security Label for Information Transfer",
             (US) Federal Information Processing Standards 
             Publication 188 (FIPS 188), NIST, Gaithersburg, MD, 
             USA, 6 September 1994.  
             <http://csrc.nist.gov/publications/fips/fips188/fips188.pdf>

Kindly note that NIST is both author and publisher, and also that 
the first use of the acronym NIST is fully expanded for clarity.

Again, if this is a "tools problem", then please either use
different tools or find a manual fix for the problem.

4)  Incorrect reference placement

[I-D.gp-intarea-obsolete-ipv4-options-iana] should be a normative
reference, not an informative reference, because the advice 
contained in *-ip-options-filtering is based on the premise that 
the cited I-D will be approved by the IETF and the requested changes 
will be made by IANA upon the direction of the IESG.

5) Proposed additional reference

I'd suggest adding this refereed conference paper as an Informational 
reference relating to SE-Linux, since it appears to be the key published
paper relating to SE-Linux:

  [LS2001]  Peter Loscocco and Stephen Smalley, "Integrating Flexible 
  Support for Security Policies into the Linux Operating System", in 
  Proceedings of the FREENIX Track: 2001 USENIX Annual Technical 
  Conference (FREENIX ’01), USENIX Association, Boston, MA, USA,
  June 2001.

Yours,

Ran

---

From: Fernando Gont <[email-masked]>
Date: Wed, 13 Jun 2012 06:52:22 -0300

Hi, Ran,

> other "unrecognised IP options".

Will fix this in the next rev.

> past without actually being corrected.

This is an error in the xml2rfc tool. I reported it at least twice, but
it has not yet been fixed. Rather than changing the xml source, I
decided to wait a bit in the hopes that they fixed the tool, such that
this got fixed in the I-D automagically.

Unless they fix this shortly, I'll replace the "automatic" reference
with a handcrafted one, such that this error is fixed.

> Reviewers deserve to be able to read the whole correct citation.

Will do.

> different tools or find a manual fix for the problem.

I will try to convey all this information in the xml. Unfortunately,
this seems to be a kind of "black magic" -- even the RFC-Ed has to hack
the xml to get the desired output. :-(

Worst case scenario: I'll include this as a comment in the xml, such
that the RFC-Ed does the final editing to make this look as expected.

> will be made by IANA upon the direction of the IESG.

Will do.

>   Conference (FREENIX ’01), USENIX Association, Boston, MA, USA,

Will do.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1