On 3 Oct 2008, at 11:10, Joe Touch wrote:
It would be useful to understand "support". I would not expect most deployed implementations to emit packets with that option, but I wouldexpect deployed implementations to check that option if it was received,and match it as specified in RFC 793.
I am not aware of any non-MLS TCP/IP implementation that checks any flavour of the IPv4 security option (RFC-791, RFC-1038, or RFC-1108). So far as I know, non-MLS host implementations don't even have code to parse any flavour of the IP Security Option. I am unaware of any non-MLS TCP/IP implementation that will generate any flavour of that option. According to Stevens in "TCP/IP Illustrated, Volume 2" page 249, there is no support of any kind for the IP Security options in BSD Net/3 and later. He is silent on BSD prior to Net/3 because that book is focused on Net/3 internals. Of course, 4.4 BSD post-dates the Net/3 distribution. Cisco routers running IOS do not check the option in their default configuration. All other routers that I am aware of can not do anything with the option. (There is a small possibility that the old "Network Systems" brand routers could be configured to look at RFC-1038 or RFC-1108 labels as part of a manually configured ACL check, but there probably aren't any of those deployed now or in recent years.) Cisco routers running certain IOS versions that have been explicitly configured to do so can use the RFC-1108 IP Security Option as part of an Access Control List decision.
There appears to be at least one change that might be required by allInternet hosts; current behavior upon receipt of an IP packet at a security level not supported is to send a TCP RST. This document indicates that such hosts MUST silently drop such packets.*Nothing in the draft applies "to all Internet hosts".* The draft is clear that nothing in the draft applies to any system that does not claim to implement that specific draft. I can repeat that scope comment in the document more times if that helps, but it does already clearly say that in the draft.I expected to find that kind of phrase in any one of the following locations, and did not
I am quite happy to add text to the Applicability section clarifying this point.
It would be useful to note that in the *'d places above where the limitations of the deployment would be stated.
I am happy to make an edit along those lines.
Agreed, but that doesn't mean these issues don't need to be addressed.
The broader question you raise of documenting which parts of RFC-791 and RFC-793 are widely not implemented is far beyond the very modest scope of this document. Such a document might well be useful, but it is well beyond the current scope.
ASIDE: One of the reasons that the IETF hasn't produced either a router requirements or a host requirements document for many years is that the last attempts in those areas did not have much impact, either on what implementers shipped or on what operators deployed.I'm not sure I agree with that. If that's the case, then why bother with this document?
We have two specifications for IPv4 security options that have some implementation and deployment (specifically RFC-1108 and FIPS-188). These have narrow deployments in multiple geographies. Those deployments normally involve MLS operating systems. We erroneously thought we would not need an equivalent IPv6 option, but operational experience over the past decade indicates that we do need an equivalent IPv6 option. So this document fills that narrow gap (no openly specified IPv6 sensitivity label option exists).
I.e., if we're admitting that the Internet ignores the IETF, we can spend more time golfing ;-)
The above is not what I said.
I'm asking that the document explain how MLS systems' view of 793 and1122 rules for TCP change as well. Others pointed out the potential needto "update" 793 regarding TCP changes; IMO this is needed for other network architecture docs as well.
I am confused how the above would translate into a specific edit.
These are architectural changes.
We appear to have different definitions for "architectural", which is perhaps not unusual for a community of this size. Yours, Ran Atkinson rja at extremenetworks.com _______________________________________________ saag mailing list saag at ietf.org https://www.ietf.org/mailman/listinfo/saag
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.