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