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:59:25 -0400

Jari, 

One of the advantages I see in an extension header
is that CGAs could be used to secure messages other 
than ND (e.g. BUs). 

Looking forward to your draft. 

Hesham

 > -----Original Message-----
 > From: Jari Ark
 [mailto:[email-masked]]
 > Sent: Sunday, June 15, 2003 11:31 AM
 > To: Pekka Nikander
 > Cc: SEND WG; Tuomas Aura
 > Subject: Re: Should CGA parameters be a separate header 
 > instead of being
 > integrated with AH
 > 
 > 
 > 
 > Pekka Nikander wrote:
 > 
 > > 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.
 > 
 > I agree that this can be troublesome. However, while I agree
 > with you that this could be an issue, I'm not sure I agree with
 > the proposed solution.
 > 
 > As you know but the rest of the list may not know, I have doubts
 > about the use of AH vs. "application layer" security in ND options.
 > If you think the IPsec - ND coordination is troublesome, I would
 > suggest that we go for ND options instead, with roughly the
 > same format and functionality as we now have in the Authentication
 > Data field.
 > 
 > I'm working on a pros-cons analysis and a drafty draft for this
 > approach, and will post it to the list as soon as possible.
 > 
 > > 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.
 > 
 > Agree with this, though I don't currently see this as a major
 > problem.
 > 
 > --Jari
 > 
 > --------------------------------------------------------------------
 > 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: Jari Arkko <[email-masked]>
Date: Mon, 16 Jun 2003 14:26:34 +0300

> is that CGAs could be used to secure messages other 

No doubt CGAs could be useful in other contexts. The
question is, what's the easiest way to get them in place
in those other contexts? A generic extension header, or
an "application" specific extension, such as a new
mobility option for MIPv6 MH?

I simply have the opinion that the latter approach is
going to be faster in terms of implementations and
standardization, and more robust in terms of the
functions it can offer.

For instance, is the CGA extension header for a BU
going to say something about the care-of address or
home address or both? It seems to me that there
exists application layer needs and data that should
be taken into account, and this may be hard if the
solution is too generic.

--Jari