Subject: RE: Should CGA parameters be a separate header instead of being i ntegrated with AH

From: Soliman Hesham <[email-masked]>
Date: Sun, 15 Jun 2003 20:55:31 -0400

Pekka, 

Perhaps we don't need a "CGA extension header", couldn't
we just use a DST options header which can be located
before IPsec headers? 

Hesham

 > -----Original Message-----
 > From: Pekka Nikander [mailto:[email-masked]]
 > Sent: Sunday, June 15, 2003 5:20 AM
 > To: SEND WG
 > Cc: Jari Arkko; Tuomas Aura; James Kempf
 > Subject: Should CGA parameters be a separate header instead of being
 > integrated with AH
 > 
 > 
 > Based our (so far limited) implementation experience, I am
 > starting to think that perhaps the CGA public key and
 > parameters should be included in a separate option instead
 > of being integrated into the AH header.  In this note I will
 > first briefly explain the current situation, reason for the
 > suggested situation based on our experienc, and finally my
 > proposal for a new design.
 > 
 > 1. Current design
 > =================
 > 
 > In draft-ietf-send-ipsec-01.txt, the IPsec AH header is
 > defined to include the following structure:
 > 
 >    - standard AH headers (Next header, length, SPI, replay counter)
 >    - timestamp
 >    - Key Information
 >    - signature
 > 
 > The Key Information field is defined, using ASN.1, to contain
 > cgaParameters, including the CGA key, and signerInfo, which
 > may contain a different key than the CGA key.
 > 
 > 2. Why should this be changed
 > =============================
 > 
 > While implementing the current proposal, we seem to end up
 > including the CGA information in at least two separate kernel
 > data structures.  Firstly, we need the have the CGA parameters
 > field available for CGA address generation.  CGA address generation
 > is performed, in turn, either when the first link local address
 > is generated, or when a host is using autoconfiguration and
 > receives a new routing prefix in an RA.
 > 
 > Secondly, we need to have the CGA parameters field available
 > when protecting packets with AH.  The reason for this is that the
 > CGA parameters is included the AH header; otherwise they are not
 > needed.
 > 
 > Sharing the CGA parameters between AH and address generation
 > is not exactly trivial.  Typically, address generation is
 > handled by ND code, controlled with ifconfig(8), and the API
 > between ifconfig and the ND code is based on ioctl(SIOC[CG]IF).
 > On the other hand, AH is part of IPsec, controled with setkey(8),
 > and the API between the user level and kernel is based on PF_KEY.
 > 
 > Thus, if we try to inject the CGA parameters data just once to
 > the kernel, we get an ugly dependency between two otherwise fairly
 > independent pieces of code.  Alternatively, we have to pass the
 > exactly same data twice to the kernel, and typically even with
 > different user level utilities.
 > 
 > Now, if we separated CGA processing completely from AH processing,
 > AH should not know about CGA at all.  When sending outbound packets,
 > the ND stack would include a CGA header, and the IPsec processing
 > would included it as a part of the IP packet, making sure that
 > it is located before the AH header (just like HbH options or
 > Routing Header is).  On the input side, a separate piece of code
 > (trigged by the next header field) would process the CGA header,
 > drop the packet if the CGA verification fails, and cache the key
 > otherwise.  AH would then be able to fetch the key from the cache.
 > 
 > In addition to making the implementation cleaner, the new design
 > would have another benefit:  It would make CGA independent of AH,
 > making it possible to use it also with e.g. ESP or HIP.
 > 
 > 
 > 3. Proposal for a new design
 > ============================
 > 
 > I propose that we move the cga parameters from the AH header to
 > a separate header, which MUST precede the AH header:
 > 
 >    *------------------------------------------------*
 >    | IPv6   | CGA    | AH     | ICMPv6 | ND message |
 >    | Header | Header | Header | Header |            |
 >    *------------------------------------------------*
 > 
 > The CGA header would include
 >    - cgaParameters, including
 >      - auxParameters, just as today
 >      - publicKey, just as today
 > 
 > The AH header would then include just a hash of the public
 > key, i.e., a key name.
 > 
 > Furthermore, I would propose that ASN.1 is not used, since
 > having a full ASN.1 DER parser in kernel code just causes
 > bloat.  Instead, I propose the following formats for the
 > new CGA header and revised AH header.
 > 
 > ---------------------------------------------------------------------
 > 
 > X. CGA Extension Header format
 > 
 >       0                   1                   2                   3
 >       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >     | Next Header   |  Hdr Ext Len  | RES | PAD |CC |  Algorithm    |
 >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >     |                                                               |
 >     +                                                               +
 >     |                            Modifier                           |
 >     +                                                               +
 >     |                                                               |
 >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >     |                                                               |
 >     .                          Public key                           .
 >     .                      (variable length)                        .
 >     | 
 >  
 >                                                              
 >              |
 >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > 
 >     Next Header          8-bit selector.  Identifies the 
 > type of header
 >                          immediately following the CGA header.
 > 
 >     Hdr Ext Len          8-bit unsigned integer.  Length of the CGA
 >                          header in 8-octet units, not including the
 >                          first 8 octets.
 > 
 >     RESERVED             Reserved for future use.  MUST be set zero
 >                          by the sender and SHOULD be ignored by the
 >                          receiver.
 > 
 >     CC                   Collision Count.  As defined in [CGA].
 > 
 >     PAD                  Padding length (in octets).
 > 
 >     Algorithm            Public key algorithm, as defined in 
 > Section 3.2
 >                          in [RFC2535].  All conforming 
 > implementations
 >                          MUST support RSA/MD5.
 > 
 >     Modifier             CGA modifier.  As defined in [CGA].
 > 
 >     Public key           Public key in [RFC2535] format.  
 > For RSA, see
 >                          [RFC2537].  Padded with zeros, if necessary,
 >                          so that the header length becomes 
 > integral with
 >                          8-octet units.  The number of padding octets
 >                          (if any) is indicated by the PAD field.
 > 
 >     Notes:
 > 
 >     - the extension header DOES NOT include the routing prefix, since
 >       it is implicitly available in the source address.
 > 
 > ---------------------------------------------------------------------
 > 
 > 7.1.2 Integrity Check Value Format
 > 
 > [Note that AHbis has renamed the Authentication Data field into
 >   Integrity Check Value.]
 > 
 >     The format of the ICV field in AH depends on the chosen 
 > transform.
 >     For the AH_RSA_Sig transform, the format is as follows:
 > 
 >       
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >       |                                                      
 >          |
 >       +                          Timestamp                   
 >          +
 >       |                                                      
 >          |
 >       
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >       |                                                      
 >          |
 >       +                                                      
 >          +
 >       |                                                      
 >          |
 >       +                                                      
 >          +
 >       |                        Key Information               
 >          |
 >       +                                                      
 >          +
 >       |                                                      
 >          |
 >       +                                                      
 >          +
 >       |                                                      
 >          |
 >       
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >       |                                                      
 >          |
 >       .                                                      
 >          .
 >       .              Digital Signature (remaining bytes)     
 >          .
 >       .                                                      
 >          .
 >       |                                                      
 >          |
 >       
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > 
 >     The meaning of the fields is described below:
 > 
 >     Timestamp
 > 
 >        This 64 bit unsigned integer field contains a 
 > timestamp used for
 >        replay protection (the Sequence Number field in AH is 
 > not used for
 >        AH_RSA_Sig).  The use of this field is discussed in 
 > Section 7.1.4.
 > 
 >     Key Information
 > 
 >        A 160-bit long SHA-1 hash of the public key.
 > 
 >     Digital Signature
 > 
 >        This variable length field contains the signature 
 > made using the
 >        sender's private key, over the the whole packet as 
 > defined by the
 >        usual AH rules [3].  The signature is made using the 
 > RSA algorithm
 >        and MUST be encoded as private key encryption in PKCS 
 > #1 format
 >        [17].
 > 
 >        The length of this field is determined by the PKCS #1 
 > encoding.
 > 
 > ---------------------------------------------------------------------
 > 
 > 
 > --------------------------------------------------------------------
 > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
 > body to <[email-masked]>.
 > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
 > --------------------------------------------------------------------
 > 
--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 16 Jun 2003 09:32:19 +0300

Hesham,

> we just use a DST options header which can be located

Well, technically it could, but I doubt the benefit from that.
Firstly, the total size of the packet would be slightly larger.
Secondly, it would be technically easier to plug in a new
extension header to a live kernel than a new DST OPT.
Thirdly, it would have to be a mandatory DST OPT or else the
next step (AH / ESP / HIP verification) would fail.  Thus, I
don't see any real benefit.

A new extension header would have the nice benefit that you
get a clean ICMP Parameter Problem error message.  Well, you
would also get one from a DST OPT, too.  Hmm.  Maybe there would
be differences if the CGA ext header is sent to a multicast
destionation.  I have to think about this.

--Pekka