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

From: Merike Kaeo <[email-masked]>
Date: Mon, 08 Jul 2013 07:49:31 -0700

In looking at the diffs from rev 2 and the rev 3 yesterday I also agree with Ran that the removal of the cisco
related IPSO text is problematic.  I remember the use of this option since I was at cisco during the time this was
created and why it was utilized and I guess for me the text wasn't confusing.  I do see how it could be for others without further
explanation.

Perhaps adding some text along the lines of:

"There are private networks that consider the router policing using IPSO to be an important design feature.  Those
private IP networks are commonly built using commercial and open-source products - for hosts, firewalls, routers, etc.
Some routers support this option although they are part of MPLS IP router implementations."...then follow with the Cisco
part that was removed

I am paraphrasing what Ran wrote and he will probably do a much better job of adding the text that is needed.

- merike

On Mon 08/07/13  6:41 AM , "Arturo Servin" [email-masked] sent:
> 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-masked]
> > https://www.ietf.org/mailman/listinfo/opsec
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
> 
> 
>

---

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

Merike, Ran,

Equivalent text to the first part of what you propose is already in Section 4.12.1, "Uses". Section 4.12.2 deals with the "Option Specification", so we need t=not repeat the use.

The current text is as follows:

   Section 4.2.2.1 of RFC 1812<http://tools.ietf.org/html/rfc1812#section-4.2.2.1> states that routers "SHOULD implement
   this option".

      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>].  Some governmental products
      reportedly support BSO, notably CANEWARE [RFC4949<http://tools.ietf.org/html/rfc4949>].  Support for
      BSO is included in the "IPsec Configuration Policy Information
      Model" [RFC3585<http://tools.ietf.org/html/rfc3585>] and in the "IPsec Security Policy Database
      Configuration MIB" [RFC4807<http://tools.ietf.org/html/rfc4807>].

Perhaps something as simple as this?

   Section 4.2.2.1 of RFC 1812<http://tools.ietf.org/html/rfc1812#section-4.2.2.1> states that routers "SHOULD implement
   this option".

      Many routers include support for IPSO. For example,

      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>].  Some governmental products
      reportedly support BSO, notably CANEWARE [RFC4949<http://tools.ietf.org/html/rfc4949>].  Support for
      BSO is included in the "IPsec Configuration Policy Information
      Model" [RFC3585<http://tools.ietf.org/html/rfc3585>] and in the "IPsec Security Policy Database
      Configuration MIB" [RFC4807<http://tools.ietf.org/html/rfc4807>].

Thanks,

-- Carlos.

On Jul 8, 2013, at 10:49 AM, Merike Kaeo <[email-masked]<mailto:[email-masked]>> wrote:

- merike

On Mon 08/07/13  6:41 AM , "Arturo Servin" [email-masked]<mailto:[email-masked]> sent:
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

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

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 9 Jul 2013 10:27:37 -0400

All,

Here is some candidate text to replace the indented text
in Sections 4.12.2 & 4.13.2, leveraging Merike's suggested 
introduction, and restoring (with minor edits) the previous 
language:

	Some private IP networks consider IP router-based
	per-interface selective filtering of packets based 
	on (a) the presence of an IPSO option (including BSO 
	and ESO) and (b) based on the contents of that IPSO 
	option to be important for operational security reasons.
	The recent IPv6 CALIPSO option specification discusses
	this in additional detail, albeit in an IPv6 context. 
	[RFC5570]

	Such private IP networks commonly are built using both
	commercial and open-source products - for hosts, guards,
	firewalls, switches, routers, etc.  Some commercial IP
	routers support this option, as do some IP routers which 
	are built on top of Multi-Level Secure (MLS) operating 
	systems (e.g. on top of Trusted Solaris	[Solaris2008] or 
	Security-Enhanced Linux [SELinux2008]).

	For example, many Cisco routers that run Cisco IOS include 
	support for selectively filtering packets that contain the
	IP Security Options (IPSO) with per-interface granularity.  
	This capability has been present in many Cisco routers 
	since the early 1990s [Cisco-IPSO-Cmds].  Some government 
	sector products reportedly also support the IP Security 
	Options (IPSO), for example CANEWARE [RFC4949].  

	Support for the IPSO Basic Security Option also is 
	included in the "IPsec Configuration Policy Information 
	Model" [RFC3585] and in the "IPsec Security Policy 
	Database Configuration MIB" [RFC4807].  Section 4.6.1
	of the IP Security Domain of Interpretation [RFC2407]
	includes support for labeled IPsec security associations
	compatible with the IP Security Options.

I'm greatly obliged to Merike for her suggested text, 
which is included in the proposed revised text above,
and to Arturo for agreeing that an edited version of 
the original text could be retained in this document.

Yours,

Ran Atkinson

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 9 Jul 2013 15:58:22 +0000

WG,

I just posted a new revision, intended to address all WGLC comments on this document.

You can find it at http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-03.
You can also find diffs from the previous version at http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ip-options-filtering-03

This new revision incorporates resolution to all comments, especially from Arturo and Merike, as well as the text below. It also incorporates a number of editorial (typographical, grammar) fixes. Hopefully we have not missed anything.

Please review.

Thanks!

-- Carlos.

---

From: Arturo Servin <[email-masked]>
Date: Tue, 09 Jul 2013 14:05:44 -0300

Looks good and clear to me.

Thanks,
as

---

From: Warren Kumari <[email-masked]>
Date: Sun, 14 Jul 2013 03:34:19 -0400

> I just posted a new revision, intended to address all WGLC comments on this document.

<chair hat>

Thank you. 

We have discussed this and judge there to be consensus to progress this.

We would also like to apologize for how long it took to complete this WGLC, and thank the authors (and WG) for their patience. We have / will be making some changes to streamline things, and hopefully prevent long delays in the future.

W
</chair hat>

--
"Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life." -- Terry Pratchett

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 28 Jul 2013 21:01:07 +0000

Warren,

> We have discussed this and judge there to be consensus to progress this.

Thanks. All the WGLC comments were resolved with revision -04 posted on July 11th.

Do you have a target for when the doc will be sent to the IESG?

-- Carlos.

---

From: KK <[email-masked]>
Date: Sun, 28 Jul 2013 20:22:36 -0700

Hi Carlos,

I have the shepherd write-up almost ready to be shipped out. My plan is to
do it this week.

Thanks you for your patience.

Regards,
KK

On Sun, Jul 28, 2013 at 2:01 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> > We would also like to apologize for how long it took to complete this
> WGLC, and thank the authors (and WG) for their patience. We have / will be
> making some changes to streamline things, and hopefully prevent long delays
> in the future.
> >
> >
> > W
> > </chair hat>
> >
> >>
> >> You can find it at
> http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-03.
> >> You can also find diffs from the previous version at
> http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ip-options-filtering-03
> >>
> >> This new revision incorporates resolution to all comments, especially
> from Arturo and Merike, as well as the text below. It also incorporates a
> number of editorial (typographical, grammar) fixes. Hopefully we have not
> missed anything.
> >>
> >> Please review.
> >>
> >> Thanks!
> >>
> >> -- Carlos.
> >>
> > "Build a man a fire, and he'll be warm for a day. Set a man on fire, and
> he'll be warm for the rest of his life." -- Terry Pratchett
> >
> >