[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Part Three: Field Variance Analysis
The second thing that I've heard that I disagree with is that the
IP header has so many more variant fields and fields that aren't critical
to security that we should just use a pseudo-header. One thing in these
arguments I disagree with is the definition of "critical to security".
Ninth assertion: Fields that can be used for denial-of-service
attacks must be authenticated so that the denial-of-service attack can
be detected and logged.
Even if mucking with a field can't be used to get into a system,
steal a connection, or something direct like that, it frequently has the
ability to cause other denial-of-service situations. When any denial-of-
service attack is in progress, you need to be able to know this in order
to stop it. Fields that aren't critical to system security but could be
modified to create a denial-of-service attack should still be authenticated
for the sole purpose of detecting that attack.
Also, I'm not a cryptographer and I don't play one on TV, but it
would seem to me that known nonzero but not really important values are
probably better than zero values and should not be worse. It would seem
to me that information of that sort should be stirred into the pot just to
have some nonzero bits in the stew. Someone who knows more about cryptography
and cryptographic checksums could offer better input on this subject, but,
unless someone with more crypto experience can explain otherwise, I am
working from the assumption that nonzero fields are better than zero fields.
Some discussion should be given to reserved fields. Currently, I
believe that reserved fields should be included in the hash for exactly
the same reason unknown option fields should be. The argument and cases
is exactly the same.
That all said, this is what I concluded for variance:
Legend:
Classes:
Invariant = If this field changes, the packet is
not authentic
(C) = Changed by some routers. By definition,
however, the packet is not actually
authentic if this field is changed
and not changed back before the next
AH check.
Variant = If this field changes, the packet is
still authentic
(L) = Due to layering (e.g., of
fragmentation below AH)
(T) = Due to transit
Predictable = This field changes deterministically,
so we can figure out what it will
look like at the receiver
Actions:
Hash = Run straight through hash
(R) = Redundant, i.e., should be authentic
by virtue of getting to AH processing,
but we still want a crypto guarantee
Zero = Run a same-size zero block through hash
Roll = "Roll-forward"/compute how it would look at
the receiver after re-assembly, run result
through hash
Other Symbols:
(deprecated) = Obsolete or never caught on. If I
label your favorite option deprecated, don't
think I'm trying to slam it. It's just that
I don't know of any system that uses it.
You can probably get away with not processing
deprecated options, but I wouldn't recommend
that you do so.
(*)(+) = Indicate footnotes follow with more info.
==== IPv4 ====
IPv4 Header: [RFC791]
Field Size Class Action
Version 4 bits Invariant Hash (R)
IHL 4 bits Invariant (C) Hash (R)
TOS 8 bits Invariant (C) Hash
Total length 16 bits Invariant (C) Hash (R)
Identification 16 bits Invariant Hash
Flags:
Reserved 1 bit Invariant Hash
DF 1 bit Invariant Hash
MF 1 bit Predictable Roll (=Zero)
Fragment off. 13 bits Predictable Roll (=Zero)
Time to Live 8 bits Variant (T) Zero
Protocol 8 bits Invariant Hash (R)
Header Checksum 16 bits Variant (L) Zero (R)
Source Address 32 bits Invariant Hash
Destination Ad. 32 bits Predictable(*) Roll(*)
(*) If a source route is present and the pointer is less than the
length (indicating that this is not the final destination),
the Destination Address field must be filled in with the
last destination address in the source route's list.
IPv4 End of Option List Option: [RFC791]
Field Size Class Action
Type 8 bits Invariant Hash
IPv4 No Operation: [RFC791]
Field Size Class Action
Type 8 bits Invariant Hash
IPv4 Security Option: [RFC791] (*) (deprecated)
Field Size Class Action
Type 8 bits Invariant Hash
Length 8 bits Invariant Hash
Security (S) 16 bits Invariant Hash
Compartments(C) 16 bits Invariant Hash
Handling Rst(H) 16 bits Invariant Hash
Trans. Ctl(TTC) 24 bits Invariant Hash
(*) This option has the same type value (130) as the IPv4
Basic Security option [RFC1108].
IPv4 Loose/Strict Source and Record Route options: [RFC791]
Field Size Class Action
Type 8 bits Invariant Hash
Length 8 bits Invariant Hash
Pointer 8 bits Predictable(*) Roll
Data var. Predictable(+) Roll
(*) At the final destination, the Pointer will be equal to (Length+1)
(+) The algorithm for rolling source route data is:
0. If Pointer > Length, don't roll (you have it already)
1. Hash up to the octet before the one pointed to by Pointer
2. Hash the destination address in the IP header
3. If (Pointer + (size of dest address)) > Length, you're done
4. Hash from Pointer to (Length - (size of the dest. address))
IPv4 Record Route option: [RFC791]
Field Size Class Action
Type 8 bits Invariant Hash
Length 8 bits Invariant Hash
Pointer 8 bits Variant Zero
Data var. Variant Zero
IPv4 Stream Identifier option: [RFC791] (deprecated)
Field Size Class Action
Type 8 bits Invariant Hash
Length 8 bits Invariant Hash
Stream ID 16 bits Invariant Hash
IPv4 Internet Timestamp option: [RFC791] (deprecated)
Field Size Class Action
Type 8 bits Invariant Hash
Length 8 bits Invariant Hash
Pointer 8 bits Variant Zero
Overflow 4 bits Variant Zero
Flag 4 bits Invariant Hash
Data var. Variant Zero
IPv4 Probe/Reply MTU options: [RFC1063] (*) (deprecated)
Field Size Class Action
Type 8 bits Invariant Hash
Length 8 bits Invariant Hash
Value 16 bits Variant Zero
(*) RFC1700, Assigned Numbers, lists RFC1191 as being the
current specification for these options. RFC1191 is
the current specification for Path MTU Discovery
and obseletes RFC1063, but it does not mention this
option at all. RFC1063 defines the latest version
of this options.
IPv4 Basic Security option: [RFC1108] (*)
Field Size Class Action
Type 8 bits Invariant Hash
Length 8 bits Invariant Hash
Classification 8 bits Invariant Hash
Protection Auth var. Invariant Hash
(*) This option has the same type value (130) as the IPv4
Security option [RFC791].
IPv4 Extended Security option: [RFC1108]
Field Size Class Action
Type 8 bits Invariant Hash
Length 8 bits Invariant Hash
Add. Info Fmt. 8 bits Invariant Hash
Add. Info var. Invariant Hash
IPv4 Traceroute option: [RFC1393] (deprecated)
Field Size Class Action
Type 8 bits Invariant Hash
Length 8 bits Invariant Hash
ID Number 16 bits Invariant Hash
Outbound Hop C. 16 bits Variant Zero
Return Hop Cnt. 16 bits Variant Zero
Originator IP 32 bits Invariant Hash
==== IPv6 ====
IPv6 Header: [draft-ietf-ipngwg-ipv6-spec-02]
Field Size Class Action
Version 4 bits Invariant Hash (R)
Priority 4 bits Invariant Hash
Flow Label 24 bits Invariant Hash
Payload Length 16 bits Invariant Hash (R)
Next Header 8 bits Invariant Hash (R)
Hop Limit 8 bits Variant (T) Zero
Source Address 128 bit Invariant Hash
Destination Ad. 128 bit Predictable(*) Roll(*)
(*) If a source route is present and the pointer is less than the
length (indicating that this is not the final destination),
the Destination Address field must be filled in with the
last destination address in the source route's list.
IPv6 Hop-by-Hop/Destination Options Headers: [draft-ietf-ipngwg-ipv6-spec-02]
Field Size Class Action
Next Header 8 bits Invariant Hash
Hdr Ext Len 8 bits Invariant Hash
Option Data var. var.(*) var.(*)
(*) If the third-highest-order bit in the Option Type is set,
the Option Data MUST be Zeroed. If the third-highest-order
bit in the Option Type is not set, you must either Hash
or Roll, depending on the option.
IPv6 Pad1 Option: [draft-ietf-ipngwg-ipv6-spec-02]
Field Size Class Action
Option Type 8 bits Invariant Hash
IPv6 PadN Option: [draft-ietf-ipngwg-ipv6-spec-02]
Field Size Class Action
Option Type 8 bits Invariant Hash
Option Length 8 bits Invariant Hash
Option Data var. Invariant Hash
IPv6 Jumbo Payload Option: [draft-ietf-ipngwg-ipv6-spec-02]
Field Size Class Action
Option Type 8 bits Invariant Hash
Option Length 8 bits Invariant Hash
Option Data 32 bits Invariant Hash
IPv6 Routing Header: [draft-ietf-ipngwg-ipv6-spec-02]
Field Size Class Action
Next Header 8 bits Invariant Hash
Routing Type 8 bits Invariant Hash
(*) (*) (*) (*)
(*) More data follows depending on type.
IPv6 Routing Header Type 0: [draft-ietf-ipngwg-ipv6-spec-02]
Field Size Class Action
Next Header 8 bits Invariant Hash
Routing Type 8 bits Invariant Hash
Num Addrs 8 bits Invariant Hash
Next Addr 8 bits Predictable(*) Roll(*)
Reserved 8 bits Invariant Hash
Strict/Loose 24 bits Invariant Hash
Addresses var. Predictable(+) Roll(+)
(*) At the final destination, the Next Addr field will be equal to
the Num Addrs field
(+) The algorithm for rolling source route data is:
0. If Next Addr = Num Addrs field, don't roll (you have it)
1. Hash Address[0] through Address[Next Addr - 1]
2. Hash the destination address in the IPv6 header
3. If (Next Addr + 1) > Length, you're done
4. Hash from Address[Next Addr] through Address[Num Addrs - 2]
IPv6 Fragment Header: (*) [draft-ietf-ipngwg-ipv6-spec-02]
Field Size Class Action
Next Header 8 bits Invariant Hash
Reserved 8 bits Invariant Hash
Fragment Offset 13 bits Predictable Roll (=Zero)
Res 2 bits Invariant Hash
M flag 1 bit Predictable Roll (=Zero)
Identification 32 bits Predictable Hash
(*) This is academic, since you MUST not ever authenticate
fragments except when the fragments are inside a
tunnel (AH processing is done before fragmentation
and after re-assembly).
==== IPv4/IPv6 Common ====
IP Authentication Header: (*) [RFC1826]
Field Size Class Action
Next Header 8 bits Invariant Hash
Length 8 bits Invariant Hash
Reserved 16 bits Invariant Hash
Security Param. 32 bits Invariant Hash
Auth. Data var. Variant (L)(+) Zero
(*) Yes, you have to authenticate the authentication header.
(+) You have to zero this field or you get a chicken-and-egg
problem.
IP Encapsulating Security Payload: [RFC1827]
Field Size Class Action
Security Associ 32 bits Invariant Hash
Opaque Transfor var. Invariant(*) Hash(*)
(*) Unless the authenticating point participates in the ESP
key management, it doesn't know what the transform.
Treating all of this data as opaque seems to be the
most reasonable thing given the nature of the data
and the currently defined DES-CBC transform.
Follow-Ups: