[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new ESP spec (bigger message)

Note that many of my questions were covered in AH already.

>                 IP Encapsulating Security Payload (ESP)
<SNIP!>

> 2.  Encapsulating Security Payload Packet Format
<SNIP!>

> 2.1  Security Parameters Index

> 2.4  Payload Data
> 
>    Payload Data is a variable-length field containing data described by
>    the Next Header field. This field is an integral number of bytes in
>    length.  The Payload Data field is mandatory.
> 
>    ***We have a potential IPv6 alignment problem here, that may have
>    ***been present for some time.  Ignoring the presence or absence of an
>    ***iv, the payload data will not be aligned on an 8-byte boundary if
>    ***the Sequence Number is omitted.  This may cause a problem for
>    ***efficient crypto data transfer.   If the IV is present,  and the
>    ***Sequence Number is omitted, the same problem arises, starting with
>    ***the IV, unless the IV is of a compensating size.  The decryption
>    ***process can fix the problem for higher layer protocols, because the
>    ***output buffer from decryption is usually distinct from the input
>    ***buffer, but that still causes potential problems for transfer of
>    ***data to the crypto module. Also, if encryption is not employed,
>    ***this becomes a potential problem for authentication data being
>    ***passed up.  We could solve this by adding an optional alignment
>    ***field to the ESP header, when required for IPv6.  What do people think?

This isn't a real problem for IPv6.  The reason for the 8-byte alignment
drive in IPv6 was to make fast-path processing faster.  (Those of us with
UltraSPARC appreciate this.)  Since ESP is already beating down the slow
path, this isn't as huge of a deal as one might think at first.  Also, a
properly formed IPv6 datagram will be 8-byte aligned once you strip out the
ESP cruft after decryption.

There's always crypto-algorithm alignment issues, but I leave those to the
crypto wizards.

> 3.  Encapsulating Security Protocol Processing

See my previous note about IPv6 destination option semantics, tunnel-mode
not being all that different, and outbound SA selection.

<SNIP!>

> 3.2.3  Packet Encryption
> 
> 3.2.3.1 Scope of Encryption
> 
>    In transport mode, if encryption has been selected, the transmitter
>    encapsulates the original upper layer protocol information into the
>    ESP payload field, adds any necessary padding, and encrypts the
>    result (Payload Data, Padding, Pad Length, and Next Header) using the
>    key, encryption algorithm, and algorithm mode indicated by the SA.
>    In tunnel mode, the transmitter encapsulates and encrypts the the
>    entire original IP datagram (plus the Padding, Pad Length, and Next
>    Header).
> 
>    If both encryption and authentication have been selected, encryption
>    is performed first, before the authentication and the encryption does
>    not encompass the Authentication Data field.  This order of
>    processing facilitates rapid detection and rejection of replayed or
>    bogus packets by the receiver, prior to decrypting the packet, hence
>    potentially reducing the impact of denial of service attacks.  It
>    also allows for the possibility of parallel processing of packets at
>    the receiver, i.e., decryption can take place in parallel with
>    authentication.  Note that since the Authentication Data is not
>    protected by encryption, a keyed authentication algorithm must be
>    employed to compute the ICV.

You've seen my comments on this (reversing the order of authentication and
encryption) already.

<SNIP!>

> 3.2.4.3  Authentication Algorithms
> 
>    The authentication algorithm employed for the ICV computation is
>    specified by the SA.  For point-to-point communication, suitable
>    authentication algorithms include keyed Message Authentication Codes
>    (MACs) based on symmetric encryption algorithms (e.g., DES) or on
>    one-way hash functions (e.g., MD5 or SHA-1).  For multicast
>    communication, one-way hash algorithms combined with asymmetric
>    signature algorithms are suitable.  As of this writing, the
>    mandatory-to-implement authentication algorithms are based on the
>    former class, i.e.,  HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5
>    [Riv92].  The output of the HMAC computation is truncated to (the
>    leftmost) 96 bits.  Other algorithms, possibly with different ICV
>    lengths, MAY be supported.

Is the HMAC trunctated for use in ESP?!?  I hadn't heard any movement to do
so, but I sometimes miss these things.

<SNIP!>

> 3.3  Inbound Packet Processing
<SNIP!>

You've seen some comments about things in here in the AH comments.

> 3.3.5  Packet Decryption
> 
>    If data confidentiality was selected, the receiver decrypts the ESP
>    Payload Data, Padding, Pad Length, and Next Header using the session
>    key that has been established for this traffic.  If an explicit IV is
>    present, it is input to the decryption algorithm as per the algorithm
>    specification.  If an implicit IV is employed, a local version of the
>    IV is constructed and input to the decryption algorithm as per the
>    algorithm specification.  (Decryption may take place in parallel with
>    authentication, but care must be taken to avoid possible race
>    conditions with regard to packet access and reconstruction of the
>    decrypted packet.)
> 
>    After decryption, the original IP datagram is reconstructed and
>    processed per the normal IP protocol specification.  The exact steps
>    for reconstructing the original datagram depend on the mode (tunnel
>    vs transport) and are described in the document, "Security
>    Architecture for the Internet Protocol."

Ahh, the stripping of the ESP cruft I was talking about before... :)

That's it for this one,
Dan
Follow-Ups: References: