Hi, In addition to the current thread, and regarding to CGA configuration, maybe there are some aspects that could be nice to have (either provided by DHCP, or maybe by RA): - recommendation for the Sec values to be used by the hosts when generating the CGA, since the administrator could have a better idea about the security requirements of the network. If Extension Fields for the CGA are defined, maybe some of them could be nice to be set by the network administrator. This could be done though either through RA or DHCP. - my understanding of MCGA (for SEND proxies) is that the end hosts need to know that there is the possibility of being proxied, so that an MCGA should be generated, and should be configured with some keying material from the proxies to generate the MCGA. Additionally, the proxies need to know the public key of the host to which they could proxy to. Is there any "automated" mechanism for this? If not, maybe DHCP could do the job. - the computation of the Modifier of a CGA/MCGA in order to comply with a certain Sec value could be CPU-intensive: around 5000 seconds to compute a Sec=2 Modifier with openSSL in a dual core system. Some devices (i.e. mobile, limited capacity, etc.) could require too much time, or have their batteries drained because of this computation. Maybe an interaction through DHCP, or maybe other protocol could solve the problem (or maybe this is out of any standardization effort)
Best regards, Alberto -----Mensaje original----- De: James Kempf [mailto:[EMAIL PROTECTED] Enviado el: martes, 19 de junio de 2007 23:58 Para: Templin, Fred L; marcelo bagnulo braun; Stig Venaas CC: INT Area Asunto: Re: DHCPv6 and CGA (was: Re: [Int-area] SeND & CGA Extensions BOF) Fred, Thanx for the correction. Do you see any aspect of CGA use with DHCP that is not currently covered by RFC 3315? jak ----- Original Message ----- From: "Templin, Fred L" <[EMAIL PROTECTED]> To: "James Kempf" <[EMAIL PROTECTED]>; "marcelo bagnulo braun" <[EMAIL PROTECTED]>; "Stig Venaas" <[EMAIL PROTECTED]> Cc: "INT Area" <[EMAIL PROTECTED]> Sent: Tuesday, June 19, 2007 2:07 PM Subject: RE: DHCPv6 and CGA (was: Re: [Int-area] SeND & CGA Extensions BOF) > I think it is already possible for a node to use CGAs with > DHCPv6. This was what I meant in "NETLMM using DHCP" where it says: "IPv6 RAs can carry prefix options whereas IPv4 RAs only carry the addresses of routers. IPv6 MNs can auto-configure addresses from advertised prefixes and propose them to the MAP's DHCPv6 server instead of allowing the DHCPv6 server to select addresses." (see: http://tools.ietf.org/html/draft-templin-autoconf-netlmm-dhcp-04). > The node > sends an Interface ID Option (Section 22.18 of RFC 3315) > along with the > REQUEST, containing a cryptographically generated interface > id. The DHCP server assigns the address having this id. AFAICT, according to ([RFC3315], Section 22.18)) that is not what the Interface ID option is used for, and would not work as you have described it. > For this to work, the subnet > prefixes must be advertised in the RA even though the 'M' > flag is set, since > the cryptographic generation process uses the subnet prefix. > If the RA > advertises more than one subnet, there might be a problem, > since there is no > way to indicate to the server which subnet the host has selected. Not true; the client can configure a CGA address from an advertised prefix and "propose" it to the server by including it in an IA Address option ([RFC3315], Section 22.6). The server should then be willing to assign the address to the client as long as it isn't a duplicate. Fred [EMAIL PROTECTED] > Most of the reasons mentioned in this thread as to why this > might be useful > strike me as somewhat speculative, if still within the realm > of possibly > useful. The only reason that I can see as being soundly > justified is that > the NS/NA IP address to link address resolution process for a > DHCP assigned > address is subject to address spoofing unless the address is a CGA. > > I think this topic (how to use CGAs with DHCP) rates about a > 4-9 page RFC > that essentially expands on the above, indicating what hosts, > routers, and > DHCP servers must do in order to make it possible. > > Sorry it took so long to get back on this, I was travelling without > reasonable email access. > > jak > > > ----- Original Message ----- > From: "marcelo bagnulo braun" <[EMAIL PROTECTED]> > To: "Stig Venaas" <[EMAIL PROTECTED]> > Cc: "INT Area" <[EMAIL PROTECTED]> > Sent: Monday, June 04, 2007 8:13 AM > Subject: Re: [Int-area] SeND & CGA Extensions BOF > > > Hi Stig, > > thanks for the comments, see reply in line... > > El 04/06/2007, a las 12:51, Stig Venaas escribió: > > > > I agree that there are some challenges, but we should work on > > understanding what those are, and see if it is worthwhile to work > > on it. > > well the proposed work is to understand those rather than build > solutions. > > the main question at this stage is what are the motivations for a node > that needs to use CGAs to use also dhcp > > If we determine that there are relevant scenarios where a > host needs to > use CGA and dhcp simoultaneously, then we should explore how to make > these two work togehter, which is the proposed work. > > So as i understand it, if we see use cases for using cga and dhcp in > the same node, then we have a motivation for this work item (in this > bof or somewhere else, but this means that this is interesting work) > > > I for one would like to think more about that (I guess you > > may have thought more about this than me Markus :) > > > > I have only passing knowledge of CGAs, but I wonder if > there could also > > be ways of proving that an address really was handed out by a given > > DHCP server. > > i guess you could envision different ways of doing that, ranging from > modifier ranges of multikey cgas or other approaches, it > really depends > on what are the motiviatiosn for doing so, do you think there may be a > case for needing that? > > thanks, marcelo > > > > > > Stig > > > >> > >>> > >>> I don't see a single good reason for standardizing that > but multiple > >>> reasons why not to. If someone really cares, I can provide the > >>> reasons > >>> off-band :) > >>> > >> > >> please expand on this since seems to be a central point for this > >> proposed item > >> > >> Thanks again, marcelo > >> > >>> Cheers, > >>> > >>> -Markus > >>> > >>> > >> > >> > >> > >> _______________________________________________ > >> Int-area mailing list > >> [email protected] > >> https://www1.ietf.org/mailman/listinfo/int-area > > > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
