Subject: [Int-area] Fwd: I-D ACTION:draft-bagnulo-cga-ext-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 2 Dec 2005 11:59:17 +0100

Hi,

we would like to submit the attached draft for the consideration of the 
Internet Area.

This is a very simple and short draft that defines a format for CGA 
extensions.

As you know, Cryptographically Generated Addresses are defined in 
RFC3972. Their main feature is that they contain a hash of a public key 
in the interface identifier part.
As currently defined, CGA allow to include additional information in 
the input of the hash i.e. in  the iid. However, the format of such 
extensions is not defined in the draft.

Lately there are a few initiatives to define such extensions, in 
particular, the Hash Based Addresses (draft-ietf-shim6-hba-01) are 
defined as a CGA extension.

The goal of the attached draft is to simply define a standard format 
for such extensions.

Probably the Internet Area list is a good place to discuss this, since 
the SEND wg (which defined the CGAs) is over and the CGAs are then a 
general tool which usage is being considered in several internet area 
wg.

I guess that the idea would be to try to go forward with this as a 
personal submission, not related to any specific wg. Hence, the 
discussion here is most welcome.

Regards, marcelo

Inicio mensaje reenviado:

> De: [email-masked]
> Fecha: 1 de diciembre de 2005 21:50:02 GMT+01:00
> Para: [email-masked]
> Asunto: I-D ACTION:draft-bagnulo-cga-ext-00.txt
> Responder a: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> 	Title		: Cryptographically Generated Addresses (CGA) Extension Field 
> Format
> 	Author(s)	: M. Bagnulo, J. Arkko
> 	Filename	: draft-bagnulo-cga-ext-00.txt
> 	Pages		: 6
> 	Date		: 2005-12-1
> 	
>    This document define a Type-Length-Value format for 
> Cryptographically
>    Generated Address (CGA) Extensions.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bagnulo-cga-ext-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of 
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-bagnulo-cga-ext-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-bagnulo-cga-ext-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Francis Dupont <[email-masked]>
Date: Fri, 02 Dec 2005 12:16:18 +0100

In your previous mail you wrote:

=> IMHO the main interest of the document is its IANA consideration
section, isn't it?

Thanks

[email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 2 Dec 2005 12:34:51 +0100

> => IMHO the main interest of the document is its IANA consideration

indeed
the draft defines a namespace for cga extensions that is to be managed 
so that if multiple extensions are defined they can be recognized and 
can be used together without interfering with each other

thanks, marcelo

---

From: Thomas Narten <[email-masked]>
Date: Tue, 06 Dec 2005 09:09:07 -0500

> can be used together without interfering with each other

This I don't quite understand. It sounds to me like you are trying to
associate random extensions with a particular CGA Message Type Name
Space (which may well be OK).

But exactly what protocols would carry such extensions? And wouldn't
_those_ protocols need to define the type field (as I think it would
be relative to that protocol)?

What this document seems to be doing is defining a TLV option space,
but the TLV numbering space isn't associated with any specific
protocol.  I don't understand how that would be used. Can you give an
example of a specific protocol where the TLV option would be carried?

Tomas

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 6 Dec 2005 18:24:02 +0100

Hi Thomas,

El 06/12/2005, a las 15:09, Thomas Narten escribió:

>> El 02/12/2005, a las 12:16, Francis Dupont escribiÃ³:
>

i don't think this is what is done in this draft...

> be relative to that protocol)?

but the extensions defined are to be included in the CGA parameter data 
structure i.e. as part of the hash input (as opposed to part of a 
protocol message) see below...

> protocol.

right

>   I don't understand how that would be used. Can you give an

Well, the first example that i can point out is the HBA multiprefix 
extension for CGAs defined in draft-ietf-shim6-hba-01
The multiprefix extension of HBA defines an extension for CGAs in order 
to include information about multiple prefixes in the input of the hash 
which output is included in the interface identifier part of the 
resulting CGA addresses. This multiprefix extension is used by the 
shim6 protocol (draft-ietf-shim6-proto-02)

Now, at the time of the design of the HBAs, one issue that was 
discussed was whether the HBAs were to be defined as an extension of 
the CGAs or as a different kind of addresses (i.e. not related to 
CGAs). (I mean, it was possible to define the HBas as addresses that 
contained the hash of the prefix set in the iid part of the addresses 
but not respecting the CGA parameter data structure, or its 
generation/verification procedures, nor considering the possibility of 
including a public key as input in the hash).
The decision was to define the HBAs as an extension of the CGA i.e. 
define the multiprefix extension in order to generate the HBAs. The 
reason for that was two-folded: i) on one hand it should be noted that 
both the HBAs and the CGAs use the same bits of the iid to store 
information (in one case the hash of a public key and in the other case 
the hash of a prefix set). If we define HBAs and CGAs as different 
things, it wouldn't be possible to use the protocols the use CGAs and 
the protocols that use HBAs simultaneously e.g. it wouldn't be possible 
to use SeND (that uses CGAs) and SHIM6 (that uses HBAs) with the same 
address. ii) on the other hand, it was useful for the shim6 protocol to 
have addresses that provide the CGA and HBA capabilities simultaneously 
(but this is a shim6 story that is not really relevant for this 
discussion)

But in any case, the bullet i) above may provide some insight why the 
extensions are needed. Two protocols, SeND and SHIM6, need to include 
information in the iid part of the address in the form of a hash. If we 
use non-unified approaches to include the different informations, then 
we end up not being able to use a single address for the different 
protocols, which seems highly undesirable (i.e. having to choose if we 
prefer SHIM6 or SeND for a given communication).
The problem of CGAs and HBAs was solved by defining the HBAs as CGA 
extensions. But suppose now that another protocol X need to include 
other information in the iid part of the addresses how would this be 
done? Probably, the approach would be to define another CGA extension 
extension X, so that the resulting address can carry CGA information, 
and the X information. Probably, we also want to be able to run the new 
protocol X and SeND and SHIM6 with the same addresses right? (i.e. that 
a host does not need to have protocol-specific addresses)
In order to do that we will need to generate the iid part of the 
address as the output of the hash with input the CGA parameter data 
structure, the mutliprefix extension (HBA) and the X extension, right?

The problem is that there is no defined format for the CGA extensions, 
no it is not obvious that there is no collisions in the way that the 
CGA extensions are defined, and it is not obvious to recognize the 
different extensions defined for CGA. Hence the need for defining a TLV 
CGA extension format.

If such standard format for CGA extensions is not defined it is 
possible that two different extensions end up with the same bit pattern 
for their extensions, making its simultaneous usage impossible since it 
wouldn't be possible to differentiate them.

makes sense?

regards, marcelo

---

From: "James Kempf" <[email-masked]>
Date: Tue, 6 Dec 2005 12:40:53 -0800

FWIW, I presented an extension of CGAs, called multikey CGAs, that can be 
used in cases where more than one node can legitimately claim an address to 
Mobopts (draft-kempf-mobopts-ringsig-ndproxy-02.txt) in Paris, for example, 
multicast, anycast or Proxy ND. This would require an extension to the CGA 
Parameters field.

            jak

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Thomas Narten" <[email-masked]>
Cc: "Internet Area" <[email-masked]>
Sent: Tuesday, December 06, 2005 9:24 AM
Subject: Re: [Int-area] Fwd: I-D ACTION:draft-bagnulo-cga-ext-00.txt

Hi Thomas,

right

makes sense?

regards, marcelo