1. Carrying IPSEC Authentication and ESP Headers Across SCPS-NP Networks
Keith Scott

2. CCSDS Action Item From 2000
A : Identify IP header fields necessary to support carrying IPv4 Authentication Header by the SCPS-NP, and draft a spec that shows how these fields shall be organized in relation to the SCPS-NP and the IPv4 AH

3. Issues With IPSec AH and SCPS-NP
NP as currently defined cannot carry enough information to reconstruct a correct IPv4 header in all cases (mainly when the packet originates as IP and is later translated to NP)
IP Fragmentation Information – Always required to correctly reconstruct IPv4 packets; current assumption is IPv4 reassembly before translation from IP to NP so that this information is not necessary for reconstruction
IP Options – Not necessarily required if security is not used but could be very important (e.g. router alert to support RSVP)
IPID – When security is not in use, could be artificially generated for reconstructed IPv4 packets
IPID and IP Options must be carried across the NP network for IPSec AH tunnel and transport modes
These fields (at least their lengths) are included in the IPSec signatures for the given modes

4. Applicability
Dual IP/NP gateways (IPSec AH over IP at ends, IPSec over NP in the middle)
Single IP/NP gateway (IPSec AH over IP going into IPSec AH over SCPS-NP)
For end-to-end IPSec AH over SCPS-NP, could simply assert values for required fields (IPID)
Note: NOT requried for ESP (outer IP header isn’t signed for transport mode)

5. Things that Need to be Carried to Support IPSec AH (and IP Options)
IP version can be reconstituted from NP TPID
IPv4 header length can be calculated from the reconstructed IPv4 header
Type of Service, if desired, can be carried in the expanded QoS field of SCPS-SP
IPv4 total length can be rebuilt from the SCPS-SP length field and the length of the reconstructed IPv4 header
IPID (2 bytes) – needed if AH is used; needs additional support in NP
IF IP PACKETS ARE NOT REASSEMBLED BEFORE BEING INJECTED INTO THE NP NETWORK, THEN THE FLAGS / FRAGMENT OFFSET MUST BE CARRIED (2 bytes) regardless of security
TTL is set at destination
Next protocol can be calculated from NP TPID
Header checksum is recalculated at destination
Source / Destination IP addresses
IP Options (see RFC4302 – some are mutable but even mutable ones are zerored out in AH signature computation so that the length of the reconstructed IPv4 header has to be right. Some are immutable and covered by AH signature).
Gray: carried by current SCPS-NP header (note: extended QoS field required to carry TOS byte)
Blue: needed if IPSec AH is used
Red: needed regardless of security

6. Observations
If IPv4 reassembly is guaranteed to occur before translation to NP, then IPv4 Flags and Fragment Offset fields can be omitted from NP and assumed zero on IPv4 packet reconstruction
Choice of whether to carry IP TOS byte (DSCP, ECN) in SCPS-NP Extended QoS bytes is independent of security
Mutable field not covered by AH, ESP

7. Options
Option 1: Define a single new TPID to carry additional IPv4 header information
Within this new shim layer, use another TPID to identify the next layer (e.g. IPSec AH, IPSec ESP, TCP, UDP, …)
Option 2: Use control bits to signal some of the v4 header info, TPID may indicate presence of other info
Option 3: Define a new version of SCPS-NP to bring the newly added IPv4 fields under the (optional) SCPS-NP header checksum

8. Option 1: Carry Extra IPv4 Information in a New, Dedicated TPID
Define a TPID (shim) to handle extra IPv4 header information
Use flags field in the shim to indicate which extra information is present
Use TPID in the shim to indicate next protocol
Overhead (in addition to required information)
1 byte if any of [fragmentation, AH, IP options] are used
Plus must also use at least 4 bit wide control field
Would require carrying IPID even for end-to-end AH over NP
Addresses all combinations of (fragmentation, AH, IP Options)
Includes IPID only if required
No changes to reserved control bits (just a new TPID)
Fewer compatibility issues with older versions?
New information NOT COVERED by optional SCPS-NP header checksum

9. Option 1: Shim Header Format
1 nibble TPID
TPID [4 bits]
1 nibble flags
Fragmentation information present [1 bit]
IP Options present [1 bit]
Reserved [1 bit]
IPID field (present if TPID indicates AH as next proto)
2 bytes copied from the IPID field of the IPv4 header
IP Fragmentation segment (signaled from flags)
2 bytes copied from the IPv4 header (flags & fragment offset)
IP options segment (signaled from flags)
IPv4 options copied verbatim from IP header
Could remove length fields from fixed-length IP options that contain length fields
New TPIDs
IPv4 extended header information
IPv4 AH
IPv4 ESP
VPI
Datagram
Length
TP ID
Control
(4, 12, or 20 bits)
Dest
Address
(1, 4, or 16 octets)
Src Address (0, 1, 4, or 16 octets)
Basic QoS
(0 or 1 octet)
Hop Count
(0 or 1 octet)
Time Field
[0,3,4, or self-
delimiting 2—8 octets]
Time Field
(cont’d)
Expanded QoS
(0 or 1 octet)
Header Checksum
(0 or 2 octets)
TPID
Flags
IPID
(0 or 2 octets)
Fragment Info
(0 or 2 octets)
OptLen
(0 or 1 octet )
IPv4 Options
(if present, variable)
Next Proto (e.g. IPSec AH)
(variable)

10. Option 1 Operation IP-to-NP NP-to-IP
Include the new shim header info if any of the following are true:
IP next proto is IPSec AH
Must include all IP options, IPID
IP packet is fragment and gateway does not reassemble
Must include flags, fragment offset
NP-to-IP
If IPID information is not in the NP header, implementation sets ‘new’ IPIDs (should be monotone non-decreasing?)

11. Src Address (0, 1, 4, or 16 octets) Next Proto (e.g. IPSec AH)
Option 2: Control Bits Signal Fragmentation, IP Options; TPID Signals IPID
Use a currently reserved control bit (bit 21) to indicate the presence of IP fragmentation information
If set, 2 bytes following NP header is (IPv4 flags, fragment offset)
Use another reserved control bit (bit 29, requires going from 4->12 bits of control) to signal IP options
If set, IP options are present
Could remove lengths from fixed-length IP options that contain length fields
NP TPID itself signals further extra information
If TPID is IPSec AH
Next 2 bytes after (NP header or frag info) are IPv4 IPID
IP Options, if set on the IP packet, MUST be included (not implementation- dependent)
Overhead
If fragmentation, must use at least 4 bit wide control field
If IP options are used, must use at least 12 bit wide control field
If neither fragmentation nor IP Options are used, no extra overhead
Would require carrying IPID even for end-to-end AH over NP
Addresses all combinations of (fragmentation, AH, IP Options)
Allocates two previously reserved bits in the NP control field
Includes IPID only if AH is used (in which case IPID is required)
Severe non-backward compatibility
New information NOT COVERED by optional SCPS-NP header checksum
VPI
Datagram
Length
TP ID
Control
(4, 12, or 20 bits)
Dest
Address
(1, 4, or 16 octets)
Src Address (0, 1, 4, or 16 octets)
Basic QoS
(0 or 1 octet)
Hop Count
(0 or 1 octet)
Time Field
[0,3,4, or self-
delimiting 2—8 octets]
Time Field
(cont’d)
Expanded QoS
(0 or 1 octet)
Header Checksum
(0 or 2 octets)
Fragment Info
(0 or 2 octets)
IPv4 Options
(if present, variable)
IPID
(0 or 2 octets)
Next Proto (e.g. IPSec AH)
(variable)

12. Option 2 Operation IP-to-NP NP-to-IP
Signal presence of fragmentation, IP options independently of each other and independent of security
IF AH is used, IPID is copied from IPv4 to correct place after SCPS-NP header checksum (and fragment and options)
NP-to-IP
If IPID information is not in the NP header, implementation sets ‘new’ IPIDs (should be monotone non-decreasing?)

13. Src Address (0, 1, 4, or 16 octets) Next Proto (e.g. IPSec AH)
Option 3: Option 2 But With The New Information Covered By the SCPS-NP Header Checksum
Would require a new version (010) of SCPS-NP – different header format to bring the new information under the header checksum
VPI
Datagram
Length
TP ID
Control
(4, 12, or 20 bits)
Dest
Address
(1, 4, or 16 octets)
Src Address (0, 1, 4, or 16 octets)
Basic QoS
(0 or 1 octet)
Hop Count
(0 or 1 octet)
Time Field
[0,3,4, or self-
delimiting 2—8 octets]
Time Field
(cont’d)
Expanded QoS
(0 or 1 octet)
Fragment Info
(0 or 2 octets)
IPv4 Options
(if present, variable)
IPID
(0 or 2 octets)
Header Checksum
(0 or 2 octets)
Next Proto (e.g. IPSec AH)
(variable)

14. Option 3 Operation
As option 2

15. Comparison
All options would require carriage of IPID field if AH is used, even if end-to-end AH over NP (i.e. no IP at all)
Probably not an issue; if using NP end-to-end why not use SP end-to- end?
Could define a different TPID to identify this case
Option Comparison Table
NP Control Bits Needed
Overhead
IP Header info covered by NP header checksum
‘Routing Compatible’ with SCPS-NP Version 001
Option 1
1 byte if any of (fragmentation, IP options, AH) are used No
Yes
Option 2 2
None
Option 3

16. Open Issues
Specify mechanisms to remove IP Option ‘length’ fields from those IP options that are fixed length and that have length fields?

17. Backup

18. IPSEC AH Coverage Fields NOT covered by IPSEC IPv6 IPv4 SCPS-NP
IPv4Flags: reserved (zero)
more fragments
don’t fragment
Version
Header
Length
Type of Service
total length
Version
Traffic
Class
Flow Label
Identification
Flags
Fragment offset
Payload Length
Next Header
Hop Limit
IPv6
IPv4
TTL
Protocol
Header Checksum
Source Address
Source IP Address
Destination IP Address
IP Options (optional; TLV encoded)
Destination Address
SCPS-NP
VPI
Datagram
Length
TP ID
Control
(4, 12, or 20 bits)
Dest
Address
(1, 4, or 16 octets)
Src Address (0, 1, 4, or 16 octets)
8 unused TPIDs
6 unused control (1,1,4)
Basic QoS
(0 or 1 octet)
Hop Count
(0 or 1 octet)
Time Field
[0,3,4, or self-
delimiting 2—8 octets]
IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH98] for more information.
The IPv6 extension headers that do not contain options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable.
Time Field
(cont’d)
Expanded QoS
(0 or 1 octet)
Header Checksum
(0 or 2 octets)
Note: IPSec zeros out fields that are mutable, but leaves the zeros there. This means that the overall length is covered
See: RFC4302

19. IPSec Transport Mode Transport mode ESP Transport mode AH
IP header not covered; NP doesn’t have to carry anything
Transport mode AH
Fragmentation information still an issue for both cases

20. IPSec Tunnel Mode For tunnel mode ESP, done except for fragmentation
ESP carries an entire, encrypted IP header
Outer IP header not covered by ESP
Tunnel mode AH, need same support as transport mode
Outer IP header covered by AH signature
Fragmentation information still an issue for both cases
Figures from

21. Motivations
SCPS-NP is not in wide usage, but is a stable international (CCSDS and ISO) standard
If it were to gain wider usage, there would probably be a strong desire to support functions like
Fragmentation
End-to-end (IPSec) security
IP Options (to support things like RSVP QoS)

22. Possible Scenarios Host Internet NP Network Internet HostGW NP
Network GW
Internet
Host
IPSec (AH -- Tunnel or transport mode) IP
SCPS-NP IP
Host
Internet GW NP
Network
Host
IPSec (AH -- Tunnel or transport mode) IP
SCPS-NP
Host NP
Network
Host
IPSec (AH -- Tunnel or transport mode)
SCPS-NP