Re: draft-stjohns-sipso-05 & transport protocols

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 would
> expect 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  
>>> all
>>> Internet 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 and
> 1122 rules for TCP change as well. Others pointed out the potential  
> need
> to "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