Transcript Carrying IPSEC Authentication Headers in SCPS

Carrying IPSEC
Authentication and ESP
Headers Across SCPS-NP
Networks
Keith Scott
© 2006 The MITRE Corporation. All rights reserved
CCSDS Action Item From 2000

A00-11-02: 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
© 2006 The MITRE Corporation. All rights reserved
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
© 2006 The MITRE Corporation. All rights reserved
Applicability

Dual IP/NP gateways (IPSec AH over IP at ends, IPSec over NP in
the middle)
Host
Internet
GW
NP
Network
GW
Internet
Host
IPSec (AH -- Tunnel or transport mode)
IP

SCPS-NP
IP
Single IP/NP gateway (IPSec AH over IP going into IPSec AH over
SCPS-NP)
Host
Internet
GW
NP
Network
Host
IPSec (AH -- Tunnel or transport mode)
IP
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)
© 2006 The MITRE Corporation. All rights reserved
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
© 2006 The MITRE Corporation. All rights reserved
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
© 2006 The MITRE Corporation. All rights reserved
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
© 2006 The MITRE Corporation. All rights reserved
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
© 2006 The MITRE Corporation. All rights reserved
Option 1: Shim Header Format

1 nibble TPID
– TPID [4 bits]
Datagram
Length
VPI
TP ID Control (4, 12, or 20 bits)
Dest
Address
(1, 4, or 16 octets)
Src Address (0, 1, 4, or 16 octets)

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

Basic QoS
(0 or 1 octet)
Hop Count
(0 or 1 octet)
Time Field
[0,3,4, or selfdelimiting 2—8 octets]
Time Field
(cont’d)
Expanded QoS
(0 or 1 octet)
Header Checksum
(0 or 2 octets)
TPID
Flags
OptLen
(0 or 1 octet )
IPID
(0 or 2 octets)
Fragment Info
(0 or 2 octets)
IPv4 Options
(if present, variable)
Next Proto (e.g. IPSec AH)
(variable)
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
© 2006 The MITRE Corporation. All rights reserved
Option 1 Operation

IP-to-NP
– 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?)
© 2006 The MITRE Corporation. All rights reserved
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
–


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 set, 2 bytes following NP header is (IPv4 flags, fragment offset)
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 implementationdependent)
Datagram
Length
VPI
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 selfdelimiting 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)
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
© 2006 The MITRE Corporation. All rights reserved
Option 2 Operation

IP-to-NP
– 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?)
© 2006 The MITRE Corporation. All rights reserved
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
Datagram
Length
VPI
Dest
Address
TP ID Control (4, 12, or 20 bits)
(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 selfdelimiting 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)
© 2006 The MITRE Corporation. All rights reserved
Option 3 Operation

As option 2
© 2006 The MITRE Corporation. All rights reserved
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-toend?
– 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
No
Yes
Option 1
0
1 byte if any of
(fragmentation,
IP options, AH)
are used
Option 2
2
None
No
Yes
Option 3
2
None
Yes
No
© 2006 The MITRE Corporation. All rights reserved
Open Issues

Specify mechanisms to remove IP Option ‘length’ fields
from those IP options that are fixed length and that have
length fields?
© 2006 The MITRE Corporation. All rights reserved
Backup
© 2006 The MITRE Corporation. All rights reserved
Fields NOT covered by IPSEC
IPSEC AH Coverage
IPv4Flags: reserved (zero)
more fragments
don’t fragment
Version Header Type of Service
Length
Identification
IPv4
TTL
total length
Flags
Protocol
Version
Fragment offset
Header Checksum
Traffic
Class
Payload Length
Flow Label
Next Header
Hop Limit
IPv6
Source IP Address
Source Address
Destination IP Address
IP Options (optional; TLV encoded)
SCPS-NP
8 unused TPIDs
6 unused control (1,1,4)
VPI
Datagram
Length
Dest
Address
TP ID Control (4, 12, or 20 bits)
Destination 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 selfdelimiting 2—8 octets]
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
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.
See: RFC4302
© 2006 The MITRE Corporation. All rights reserved
IPSec Transport Mode

Transport mode ESP
– IP header not covered; NP doesn’t have to carry anything

Transport mode AH

Fragmentation information still an issue for both cases
© 2006 The MITRE Corporation. All rights reserved
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 http://technet2.microsoft.com/WindowsServer/en/Library/12eb6a6f-25cb-4af4-a659-59d9ff8de3361033.mspx
© 2006 The MITRE Corporation. All rights reserved
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)
© 2006 The MITRE Corporation. All rights reserved
Possible Scenarios
Host
Internet
GW
NP
Network
GW
Internet
Host
IPSec (AH -- Tunnel or transport mode)
IP
Host
SCPS-NP
Internet
GW
IP
NP
Network
Host
IPSec (AH -- Tunnel or transport mode)
IP
Host
SCPS-NP
NP
Network
Host
IPSec (AH -- Tunnel or transport mode)
SCPS-NP
© 2006 The MITRE Corporation. All rights reserved