Subject: Re: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02

From: RJ Atkinson <[email-masked]>
Date: Mon, 8 Jul 2013 09:04:14 -0400

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

---

From: Arturo Servin <[email-masked]>
Date: Mon, 08 Jul 2013 10:41:30 -0300

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:
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 8 Jul 2013 17:51:01 +0000

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-masked]<mailto:[email-masked]>> wrote:

Ran,

Cheers,
as

Yours,

Ran Atkinson

_______________________________________________
OPSEC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsec

_______________________________________________
OPSEC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsec

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 8 Jul 2013 15:23:04 -0400

> specifics on the config granularity.

Well, the ability to apply IPSO checks on a per-interface
granularity is in fact the key point from a deployment
perspective, which is why that was mentioned.

> Could you please suggest some text that would satisfy your concern?

I will do so to the list.  Please give me a day or so.

Thanks very much,

Ran