[Sis-csi] The _other_ SCPS protocols (SP, NP, FP)
Howard Weiss
Howard.Weiss at sparta.com
Fri Dec 3 08:39:47 EST 2004
Ed, Dave,
I will speak only for SCPS-SP. Historically speaking, SCPS-SP was
developed in parallel with the IETFs IPSEC. I attended a large number
of the IETF IPSEC meetings and followed the course of that protocol
development. The problem was, IPSEC was being developed for the
hardwired, terrestrial-based, high bandwidth Internet environment.
Protocol overhead, while taken into some account, was not a major issue
- a few hundred bytes here or there does not bother people running over
broadband circuits. Wireless at that time did not play into the picture.
At the time of SCPS development, we were still working with the folks
who were planning to orbit thousands of kinetic kill vehicles as part of
the old "Star Wars" SDI program. There were also the NASA folks who
claimed bandwidth starvation and who counted every overhead bit as too
much (which is where I coined my phrase "bit neanderthals"). SCPS-SP
was the response to both of these environements - an algorithms neutral,
low overhead protocol that did pretty much what IPSEC did (in terms of
providing encryption and authentication/integrity services) but without
all of IPSEC's bells and whistles (e.g,. IPSEC includes a 32-bit
sequence counter to protect against replay - SCPS-SP says we can't
afford such a thing and we hope that only TCP or TP runs above with its
sequence counter).
Do we still need SCPS-SP? Only if the old constraints are still with us
- bandwidth deprivation. If we've got landline-like bandwidths - it can
go away. If we still have narrow bandwidth that needs security, SP will
win over IPSEC.
Howie
Ed Greenberg wrote:
> Dave and Keith,
>
> I agree with Dave. Someone should answer the first question (Does IP
> header compression replace SCPS-NP?). But in that vain NP was
> designed to go where IP wouldn't and therefore it might still be a
> valid recommendation to keep . I believe that SP was produced because
> there was no IP security spec at the time. I believe that FP should
> be dropped, period!!!
>
> Ed Greenberg
>
> At 05:32 PM 12/2/2004 -0500, Dave Israel wrote:
>
>> Keith,
>>
>> I don't believe the NP, SP, and FP protocols should just be
>> reaffirmed, as is. At minimum, I think they should be reviewed as to
>> whether they truly are recommendations for certain mission
>> scenarios. There should be some clarification, such as what you
>> started in your e-mail, about if/when these protocols should be
>> recommended. I think there should also be an assessment of what
>> continued support for these protocols exists and if there are any
>> newer alternatives. Some questions that come to my mind (that I
>> don't know the answers to) are:
>>
>> - Does IP header compression replace SCPS-NP?
>> - Will SCPS-SP meet the latest and future IT security requirements?
>> - Has SCPS-FP been replaced by CFDP and other follow on file delivery
>> methods?
>> - Does anybody really foresee these other protocols being used?
>>
>> The term "SCPS" is starting to become synonymous with "SCPS-TP," so
>> carrying these other protocols, unless truly needed, only increases
>> the confusion.
>>
>> Somebody had to get the conversation going...
>>
>> Regards,
>> Dave
>>
>> At 03:24 PM 11/30/2004, you wrote:
>>
>>> All,
>>>
>>> We spent time at the recent CCSDS meetings addressing
>>> interoperability and capability issues with SCPS-TP. In addition to
>>> the SCPS Transport Protocol (SCPS-TP), there are three other
>>> protocols in the SCPS suite:
>>>
>>> SCPS Network Protocol (SCPS-NP)
>>> (http://www.ccsds.org/CCSDS/documents/713x0b1.pdf)
>>> SCPS Security Protocol (SCPS-SP)
>>> (http://www.ccsds.org/CCSDS/documents/713x5b1.pdf)
>>> SCPS File Protocol (SCPS-FP)
>>> (http://www.ccsds.org/CCSDS/documents/717x0b1.pdf)
>>>
>>> These protocols were approved as CCSDS Recommendations a little over
>>> five years ago, and reviewing them falls under the Cislunar Space
>>> Internetworking Working Group's charter. Possible actions for these
>>> protocols include:
>>>
>>> o Approving the standards 'as-is' for another five years.
>>> o Updating / clarifying aspects of the specifications (as is being
>>> done for the TP)
>>> o Retiring some or all of the standards
>>> o ....?
>>>
>>> It is my personal belief that while there has not been as much
>>> commercial interest in the above standards as there has been in the
>>> SCPS Transport Protocol (SCPS-TP), they are still relevant for space
>>> use, at least for certain mission sets. Below is a brief reprise of
>>> the various protocols' capabilities, comparisons with their Internet
>>> counterparts, and comments about their continued applicability to CCSDS.
>>>
>>> SCPS-NP
>>> The SCPS Network Protocol allows for very compact representation of
>>> end system addresses and groups of addresses (the latter via the
>>> path address feature). SCPS-NP also provides mechanisms for
>>> priority handling of datagrams, as well as per-packet control of
>>> routing mechanisms. Per-packet routing control is used to signal
>>> that certain packets should be flooded to improve reliability. The
>>> smallest SCPS-NP header is 4 octets, significantly smaller than
>>> IPv4's 20-byte header. The main disadvantage of SCPS-NP is that it
>>> is not bit-interoperable with IPv4/v6 -- SCPS-NP headers would have
>>> to be translated into and out of IPv4/v6 to allow interoperation
>>> with an IPv4/v6-based network. Translating between SCPS-NP and IP
>>> is possible, with the possible loss in IP of some of NP's
>>> capabilities such as the ability to select different routing
>>> treatments as mentioned above. Other differences between SCPS-NP
>>> and IP include:
>>> 1) SCPS-NP has a 8191-byte maximum packet size limit and no
>>> fragmentation
>>> 2) SCPS-NP supports a maximum of 16 upper-layer (transport) protocols
>>> 3) SCPS-NP supports 16 levels of precedence, independent of the IP
>>> TOS field
>>> 4) SCPS-NP's version of ICMP (SCMP) supports explicit signaling of
>>> congestion, corruption, and link outage if such information can be
>>> acquired from the link layer.
>>> Its lower overhead and ability to signal per-packet routing options
>>> make SCPS-NP an attractive alternative to straight IPv4 (IPv6) for
>>> bandwidth-constrained missions.
>>>
>>> SCPS-SP
>>> SCPS-SP provides capabilities similar to IP Security (IPSEC) in the
>>> Internet world. The main differences between SCPS-SP and IPSEC are:
>>> 1) SCPS-SP incurs two bytes of overhead per packet, whereas IPSEC
>>> requires 10
>>> 2) SCPS-SP only allows one active security association per address
>>> pair, while IPSEC allows multiple simultaneous SAs.
>>> For some mission scenarios the overhead savings of SCPS-SP are
>>> probably not worth the effort. If the mission is pushing HDTV
>>> streams around at tens or hundreds of Mbps, a few extra bytes for
>>> IPSEC will likely be tolerable. Smaller, lower bandwidth missions
>>> might still be able to capitalize on the savings.
>>> 3) SCPS-SP does not provide replay protection, instead it relies
>>> on transport sequence numbers.
>>> Because of its lower overhead, SCPS-SP is still relevant to
>>> bandwidth-constrained missions that require security services.
>>>
>>> SCPS-FP
>>> The SCPS File Protocol supports low-bandwidth file transfers. The
>>> main features of SCPS-FP that have NOT been implemented in modern
>>> FTP implementations are:
>>> 1) Record read, update
>>> 2) Integrated file integrity checking
>>> 3) Suppression of reply text
>>> The ability to read and update pieces of a file without
>>> reading/sending the entire file could be of significant benefit to
>>> bandwidth-constrained (or asymmetric bandwidth) missions.
>>>
>>>
>>>
>>> In short, SCPS-NP, SCPS-SP, and SCPS-FP provide bit-efficient
>>> services that will be needed on future space missions. While some
>>> missions will likely have bandwidth to burn, others that are not so
>>> lucky will be able to reap significant benefits from NP, SP, and
>>> FP. For that reason I would suggest that these protocols be
>>> reaffirmed as Recommendations within CCSDS.
>>>
>>> Again, I invite discussion on any/all of the protocols.
>>>
>>>
>>> Best Regards,
>>>
>>> --keith
>>>
>>>
>>>
>>>
>>> Dr. Keith Scott
>>> kscott at mitre.org <mailto:kscott at mitre.org>
>>> +1.703.883.6547
>>> Chair, CCSDS Cislunar Space Internetworking Working Group
>>>
>>> _______________________________________________
>>> Sis-CSI mailing list
>>> Sis-CSI at mailman.ccsds.org
>>> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
>>
>>
>> ______________________________________________________________
>> Dave Israel
>> Leader, Advanced Technology Development Group
>> Microwave & Communication Systems Branch
>> NASA Goddard Space Flight Center Code 567.3
>> Greenbelt, MD 20771
>> Phone: (301) 286-5294 Fax: (301) 286-1769
>> E-mail: dave.israel at nasa.gov
>>
>> "Without deviation from the norm, progress is not possible." -Frank
>> Zappa
>> _______________________________________________
>> Sis-CSI mailing list
>> Sis-CSI at mailman.ccsds.org
>> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
>
> Progress is impossible when you always do things the way they have
> always been done.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Sis-CSI mailing list
>Sis-CSI at mailman.ccsds.org
>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
>
>
--
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20041203/ec69d0d5/attachment.htm
More information about the Sis-CSI
mailing list