Ran, Arturo,
I understood the feedback on the list to refer to this text in Section 4.12.2:
Many Cisco routers that run Cisco IOS include support dropping
packets that contain this option with per-interface granularity.
This capability has been present in many Cisco routers since the
early 1990s
[Cisco-IPSO-Cmds<http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-02#ref-Cisco-IPSO-Cmds>].
But NOT to the following text in Section 4.12.1:
The DoD Basic Security Option (BSO) is currently implemented in a
number of operating systems (e.g.,
[IRIX2008<http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-02#ref-IRIX2008>],
[SELinux2008<http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-02#ref-SELinux2008>],
[Solaris2008<http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-02#ref-Solaris2008>],
and
[Cisco-IPSO<http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-02#ref-Cisco-IPSO>]),
and deployed in a number of high-
security networks. These networks are typically either in physically
So support for IPSO by Cisco routers would remain without the specifics on the
config granularity.
Ran,
Could you please suggest some text that would satisfy your concern?
Many thanks,
-- Carlos.
On Jul 8, 2013, at 9:41 AM, Arturo Servin
<[email protected]<mailto:[email protected]>> wrote:
Ran,
I think it was me that made the comment.
To me the text didn't make to much sense when I read it. Now that
you explained in more detail why it is included I understand the rationale.
I do mind to put it back as it seems reasonable to do so. If there
were a way to explain why the text is there in a few words it would be
great.
Cheers,
as
On 7/8/13 10:04 AM, RJ Atkinson wrote:
All,
* I object to the removal of the references to the Cisco
support for IPSO processing. I observe that the comments
made recently on the OPSEC list suggested edits, and also
expressed confusion about the purpose of the existing text,
but did not demand entire removal of that text.
* I am VERY open to editing of text in some way, to clarify
its purpose or such like, but the total removal of that
text and reference is problematic because it creates
confusion that is easily avoided by having such text.
Those references were added in direct response to an
earlier comment erroneously claiming those options never
had been supported in routers. So there has been confusion
in the modern world about whether those options are only
supported in end systems or whether they also are supported
in routers. One commenter refused to believe that cisco
supported IPSO, which is why the specific reference to
a (relatively) recent Cisco IOS web page was included
in the draft.
Removing that text or reference will create the incorrect
impression that IPSO is an end-system-only option, when
actually deployed networks using IPSO consider the router
policing based on that option to be an important design
feature.
The recently deleted text (e.g. from 4.12.2) clarified that
actually millions of deployed routers do support the IPSO and
had the specific reference to the cisco website both to support
the technical claim that the option is supported and also
to satisfy the doubters.
In fact, there are other IP routers that support that
option, although they are part of MLS IP router implementations
that are less commonly used in the public global Internet
than either Cisco or Juniper. The products that I am thinking
of don't seem to have a public URL describing their features,
probably because they don't need one. The IPSO is probably
more widely deployed today than it was in 2000 or 1990,
but it is a specialised option that is rarely seen on the
public global Internet. It also appears to have much broader
geographic spread in its deployment today versus back in 2000.
The lack of such an option was an issue for IPv6 deployment,
leading fairly directly to the creation of RFC-5570 (CALIPSO).
As the more recent RFC-5570 observes, however, those private
IP networks commonly are built almost entirely using commercial
(and open-source) products -- for hosts, firewalls, NATs, routers,
and so on. As an example, Trusted Solaris and Trusted Linux
might be present both as hosts and (in separate hardware instances)
also as MLS IPSO-enforcing routers.
To repeat my bottom line, I'm happy to discuss edits to those
chunks of text, but deleting them entirely will create confusion
about the implementation status and deployed uses of the IPSO
option(s).
Yours,
Ran Atkinson
_______________________________________________
OPSEC mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/opsec
_______________________________________________
OPSEC mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/opsec
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
