Discussion:
SeND & CGA Extensions BOF
(too old to reply)
marcelo bagnulo braun
2007-06-01 15:42:28 UTC
Permalink
Hi,

we have proposed a BOF on SeND and CGA extensions for the Chicago IETF.
I attach the proposed charter below. There is a mailing list created
for the discussion (https://www1.ietf.org/mailman/listinfo/cga-ext)

If you have comments about the proposed work, it would be appreciated.

Thanks, marcelo



Proposed charter for SeND & CGA Extensions BOF

Secure Neighbour Discovery (SeND) protocol as defined in RFC 3971
provides the security mechanisms to protecting the different
functions performed by the Neighbour Discovery (ND) protocol,
including the discovery of other nodes on the link and their
link-layer addresses, router discovery and reachability detection
for the paths to active neighbors. However, current SeND
specification lacks of support for ND Proxies as defined in
RFC 4389. The SeND protocol relies on the usage of
Cryptographically GEnerated Addresses (CGAs) to provide some of
these functions, in particular to provide IPv6 address ownership
proof to the other nodes on the link and authenticate node related
information of the ND protocol. CGAs are defined in RFC 3972 which
has been recently updated by RFC 4581 to define the CGA extension
format and by RFC-to-be draft-bagnulo-multiple-hash-cga-03.txt to
support multiple hash functions. While CGAs were originally
defined for the SeND protocol, they have proved to be a useful
security tool in other environments too, and its usage has been
proposed to secure other protocols such as the Shim6 multihoming
protocol and the Mobile IPv6 protocol. As the CGAs become more
widely used for different purposes, it is necessary to produce
some extensions to support such new usages.

The objective of this working group is to define extensions related
to both to the SeND protocol and to the CGAs. The following are
charter items for the working group:

- Extensions to the SeND protocol to support Neighbour Discovery
Proxies: SeND protocol as currently defined in RFC 3971 lacks of
support for ND Proxies defined in RFC 4389. Extensions to the SeND
protocol will be defined in order to provide equivalent SeND
security capabilities to ND Proxies.

- Extensions to the IKEv2 protocol to create IPSec SAs associated to
the CGA key. Because of their cryptographic nature, CGAs are
inherently bound to the key pair that was used for their generation.
This is used in existent protocols for proving address ownership.
However, it would be possible also to use this cryptographic material
to create a security association between peers. The key benefit of
such approach is that it allows the creation of a security association
that is cryptographically bound to the IP address of the end points
without dependence on a common trust anchor point, eg. PKI. Such
approach would provide additional protection compared to the
opportunistic approaches. The proposed work will produce an analysis
of this type of solution and the required extensions to CGAs and to
the IKEv2 protocol in order to be able to create IPSec SA using the
CGAs keys.

- DHCP support for CGAs. An analysis of possible approaches to allow
the usage of the DHCP protocol to assign CGAs will be produced. The
output of the analysis will be an informational document describing
the recommended approaches that will be provided as an input to the
DHC working group where the actual DHCP extensions needed for the
recommended approaches will be defined.

- Define a CGA extension to support other public key algorithms: As
currently defined, CGAs can only use RSA keys in the CGA Parameter
Data Structure. An extension to update the CGA specification in
order to multiple public key cryptographic algorithm support will be
defined.


Related drafts:

draft-kempf-mobopts-ringsig-ndproxy-01.txt
draft-laganier-ike-ipv6-cga-01.txt
Markus Stenberg
2007-06-04 01:41:32 UTC
Permalink
Disclaimer: I mostly agree with the need for extra SeND/CGA work;
these comments are the delta that I do not agree with :)

On 2.6.2007, at 0.42, marcelo bagnulo braun wrote:
> - Extensions to the IKEv2 protocol to create IPSec SAs associated to
> the CGA key. Because of their cryptographic nature, CGAs are
> inherently bound to the key pair that was used for their generation.
> This is used in existent protocols for proving address ownership.
> However, it would be possible also to use this cryptographic material
> to create a security association between peers. The key benefit of
> such approach is that it allows the creation of a security association
> that is cryptographically bound to the IP address of the end points
> without dependence on a common trust anchor point, eg. PKI. Such
> approach would provide additional protection compared to the
> opportunistic approaches. The proposed work will produce an analysis
> of this type of solution and the required extensions to CGAs and to
> the IKEv2 protocol in order to be able to create IPSec SA using the
> CGAs keys.

Maybe it is just a matter of wording, but the additional protection
compared to opportunistic approaches seems slim to me. Certainly, you
have CGA-IP as bound entity as opposed to someone on return-routing
path, but you still don't have faintest idea who is using the IP. And
I thought that (for most part) security authorization issues required
something concrete to be identified (whether it is a machine, or user
of the machine), and not just 'oh, he went through CGA process to get
that IP'.

> - DHCP support for CGAs. An analysis of possible approaches to allow
> the usage of the DHCP protocol to assign CGAs will be produced. The
> output of the analysis will be an informational document describing
> the recommended approaches that will be provided as an input to the
> DHC working group where the actual DHCP extensions needed for the
> recommended approaches will be defined.

DHCP and security shouldn't be mixed - for laughs, look at the
current DHCPv6.. It basically assumes that all network links DHCPv6
is used on are trusted, and effectively due to that anyone on the
server-relay, or relay-client legs could 'acquire' the CGA
information if you really pushed the address+key tuple that way.

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 :)

Cheers,

-Markus
marcelo bagnulo braun
2007-06-04 10:25:04 UTC
Permalink
Hi Markus,

thanks for your comments, see reply below...


El 04/06/2007, a las 3:41, Markus Stenberg escribió:

> Disclaimer: I mostly agree with the need for extra SeND/CGA work;
> these comments are the delta that I do not agree with :)
>

great

do you think of any additional work that do you think would be
interesting to work on and that has not been included in the proposed
charter?


> On 2.6.2007, at 0.42, marcelo bagnulo braun wrote:
>> - Extensions to the IKEv2 protocol to create IPSec SAs associated to
>> the CGA key. Because of their cryptographic nature, CGAs are
>> inherently bound to the key pair that was used for their generation.
>> This is used in existent protocols for proving address ownership.
>> However, it would be possible also to use this cryptographic material
>> to create a security association between peers. The key benefit of
>> such approach is that it allows the creation of a security association
>> that is cryptographically bound to the IP address of the end points
>> without dependence on a common trust anchor point, eg. PKI. Such
>> approach would provide additional protection compared to the
>> opportunistic approaches. The proposed work will produce an analysis
>> of this type of solution and the required extensions to CGAs and to
>> the IKEv2 protocol in order to be able to create IPSec SA using the
>> CGAs keys.
>
> Maybe it is just a matter of wording, but the additional protection
> compared to opportunistic approaches seems slim to me. Certainly, you
> have CGA-IP as bound entity as opposed to someone on return-routing
> path, but you still don't have faintest idea who is using the IP. And
> I thought that (for most part) security authorization issues required
> something concrete to be identified (whether it is a machine, or user
> of the machine), and not just 'oh, he went through CGA process to get
> that IP'.
>


but, the IP address is the identity at the IP level, right?

I mean, from an architectural point of view, at the IP level what is
needed is to be certain of the identity of the peer at the IP level. So
using the CGAs would exactly provide that, an SA bound to the IP level
identity. This would suppress the leap of faith that is needed in the
opportunistic mode. I mean there are a number of processes and security
filters, ACL, that run based on IP addresses because of this reason, so
making certain that the peer is actually the owner of the IP address it
is claiming to, would provide trust to this applications. It may well
be the case that additional trust is needed because additional
information is needed. But building a generic any to any trust model
that requires no pre arrangement (global PKI or shared secret) is a
very complex task, and i think this is a significant step on this
direction. I mean, nowadays, or either a global PKI is assumed or all
you have is the opportunistic mode with the leap of faith. This work
would take a step further in the deployment of this general any to any
trust relations with no pre arrangement with an extremely reduced cost.
I mean, i would expect that the changes required to support this are
slim, minor extensions to the IKE protocol and the output is the
elimination of the leap of faith in the opportunistic mode.

But you raise a central point in this discussion, what are the
motivations for this work and if they are worth it, so i think this is
what we need to discuss at this stage. Probably it would be nice to
have a draft detailing what are the tradeoffs involved, like what are
the benefits of such approach and the costs and limitations, so that
folks would have a better picture for the discussion.



>> - DHCP support for CGAs. An analysis of possible approaches to allow
>> the usage of the DHCP protocol to assign CGAs will be produced. The
>> output of the analysis will be an informational document describing
>> the recommended approaches that will be provided as an input to the
>> DHC working group where the actual DHCP extensions needed for the
>> recommended approaches will be defined.
>
> DHCP and security shouldn't be mixed

not sure what do you mean here, but considering that CGAs are addresses
and that CGAs are used for security and that some folks may want to use
dhcp for configuring CGAs, then it seems that there should be some
relation here...

> - for laughs, look at the current DHCPv6.. It basically assumes that
> all network links DHCPv6 is used on are trusted,

that may be a reasonable assumption when current parameters are
configured, but probably this is not a valid assumption when we want to
configure cgas which will be used for security purposes, i guess

> and effectively due to that anyone on the server-relay, or
> relay-client legs could 'acquire' the CGA information if you really
> pushed the address+key tuple that way.

this is certainly a model, but it is not the only one.

I mean, it really depends what are the motivations for using dhcp and
what are the motivations for using CGAs. I mean this model assumes an
underlying trust model, where the node can fully trust not only the
links but also the dhcp server. It may well be the case that the node
doesn't want to dhcp server to have its CGA key or that simply you
cannot trust the underlying links for this purposes.

>
> 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
>
>
Stig Venaas
2007-06-04 10:51:40 UTC
Permalink
marcelo bagnulo braun wrote:
[...]
>>> - DHCP support for CGAs. An analysis of possible approaches to allow
>>> the usage of the DHCP protocol to assign CGAs will be produced. The
>>> output of the analysis will be an informational document describing
>>> the recommended approaches that will be provided as an input to the
>>> DHC working group where the actual DHCP extensions needed for the
>>> recommended approaches will be defined.
>>
>> DHCP and security shouldn't be mixed
>
> not sure what do you mean here, but considering that CGAs are addresses
> and that CGAs are used for security and that some folks may want to use
> dhcp for configuring CGAs, then it seems that there should be some
> relation here...
>
>> - for laughs, look at the current DHCPv6.. It basically assumes that
>> all network links DHCPv6 is used on are trusted,
>
> that may be a reasonable assumption when current parameters are
> configured, but probably this is not a valid assumption when we want to
> configure cgas which will be used for security purposes, i guess
>
>> and effectively due to that anyone on the server-relay, or
>> relay-client legs could 'acquire' the CGA information if you really
>> pushed the address+key tuple that way.
>
> this is certainly a model, but it is not the only one.
>
> I mean, it really depends what are the motivations for using dhcp and
> what are the motivations for using CGAs. I mean this model assumes an
> underlying trust model, where the node can fully trust not only the
> links but also the dhcp server. It may well be the case that the node
> doesn't want to dhcp server to have its CGA key or that simply you
> cannot trust the underlying links for this purposes.

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. 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.

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
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
marcelo bagnulo braun
2007-06-04 15:13:33 UTC
Permalink
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
>> Int-***@lists.ietf.org
>> https://www1.ietf.org/mailman/listinfo/int-area
>
James Kempf
2007-06-19 17:28:03 UTC
Permalink
I think it is already possible for a node to use CGAs with DHCPv6. 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. 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.

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" <***@it.uc3m.es>
To: "Stig Venaas" <***@uninett.no>
Cc: "INT Area" <int-***@ietf.org>
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
>> Int-***@lists.ietf.org
>> https://www1.ietf.org/mailman/listinfo/int-area
>
Templin, Fred L
2007-06-19 21:07:39 UTC
Permalink
> 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
***@boeing.com

> 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" <***@it.uc3m.es>
> To: "Stig Venaas" <***@uninett.no>
> Cc: "INT Area" <int-***@ietf.org>
> 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
> >> Int-***@lists.ietf.org
> >> https://www1.ietf.org/mailman/listinfo/int-area
> >
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
>
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
>
Templin, Fred L
2007-06-19 21:10:01 UTC
Permalink
> 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.

Whoops; I think I remember now that CGAs were only to
be used for SEcure Neighbor Discovery (SEND). Is that
still true?

Fred
***@boeing.com
James Kempf
2007-06-19 21:59:59 UTC
Permalink
Yes, but IMHO that is sufficient. IP address to link address mapping via ND
is subject to spoofing if the address is DHCP assigned but not a CGA, since
the ND message cannot be signed.

Do you see an issue?

jak

----- Original Message -----
From: "Templin, Fred L" <***@boeing.com>
To: "James Kempf" <***@docomolabs-usa.com>; "marcelo bagnulo braun"
<***@it.uc3m.es>; "Stig Venaas" <***@uninett.no>
Cc: "INT Area" <int-***@ietf.org>
Sent: Tuesday, June 19, 2007 2:10 PM
Subject: RE: DHCPv6 and CGA (was: Re: [Int-area] SeND & CGA Extensions BOF)


> 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.

Whoops; I think I remember now that CGAs were only to
be used for SEcure Neighbor Discovery (SEND). Is that
still true?

Fred
***@boeing.com
James Kempf
2007-06-19 21:57:39 UTC
Permalink
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" <***@boeing.com>
To: "James Kempf" <***@docomolabs-usa.com>; "marcelo bagnulo braun"
<***@it.uc3m.es>; "Stig Venaas" <***@uninett.no>
Cc: "INT Area" <int-***@ietf.org>
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
***@boeing.com

> 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" <***@it.uc3m.es>
> To: "Stig Venaas" <***@uninett.no>
> Cc: "INT Area" <int-***@ietf.org>
> 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
> >> Int-***@lists.ietf.org
> >> https://www1.ietf.org/mailman/listinfo/int-area
> >
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
>
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
>
Alberto García
2007-06-20 17:47:20 UTC
Permalink
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:***@docomolabs-usa.com]
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" <***@boeing.com>
To: "James Kempf" <***@docomolabs-usa.com>; "marcelo bagnulo braun"
<***@it.uc3m.es>; "Stig Venaas" <***@uninett.no>
Cc: "INT Area" <int-***@ietf.org>
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
***@boeing.com

> 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" <***@it.uc3m.es>
> To: "Stig Venaas" <***@uninett.no>
> Cc: "INT Area" <int-***@ietf.org>
> 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
> >> Int-***@lists.ietf.org
> >> https://www1.ietf.org/mailman/listinfo/int-area
> >
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
>
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
>
Thomas Narten
2007-06-20 15:32:05 UTC
Permalink
"James Kempf" <***@docomolabs-usa.com> writes:

> I think it is already possible for a node to use CGAs with DHCPv6. 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. 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.

Do you mean that the RA must include a prefix information option? If
so, with which bits set? if the autoconfigure bit must be set for this
to work, that seems like a non-starter, since now there is no point in
using DHCP to get an address you already legitimitely have. (I don't
know the details right off here, hence I'm asking.)

Thomas
James Kempf
2007-06-20 16:58:43 UTC
Permalink
The basic issue is that the host must know which subnet prefix to use prior
to sending the DHCP REQUEST if it is to generate a CGA. The prefix is part
of the CGA parameters data structure used in the hash calculation for the
crypto-id, as described in Section 3 of RFC 3972. The host then includes an
IA Address Option (Section 22.6 of RFC 3315) with the address in a DHCP
REQUEST. So that means that the RA must include a prefix information option
so that the host has the prefix in order to generate the address.

Exactly how that interacts with address autoconfiguration is something that
would need to be addressed in generating the draft describing how to do CGAs
with DHCP. I don't know whether hosts using DHCPv6 commonly propose
addresses today, but I suspect probably not, since it isn't done in IPv4 and
I suspect DHCPv6 is most commonly used in a way that works as much like the
v4 case as possible. Others with more operational and deployment knowledge
of DHCP use please correct me if I am wrong.

jak

----- Original Message -----
From: "Thomas Narten" <***@us.ibm.com>
To: "James Kempf" <***@docomolabs-usa.com>
Cc: "marcelo bagnulo braun" <***@it.uc3m.es>; "Stig Venaas"
<***@uninett.no>; "INT Area" <int-***@ietf.org>
Sent: Wednesday, June 20, 2007 8:32 AM
Subject: Re: DHCPv6 and CGA (was: Re: [Int-area] SeND & CGA Extensions BOF)


"James Kempf" <***@docomolabs-usa.com> writes:

> I think it is already possible for a node to use CGAs with DHCPv6. 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. 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.

Do you mean that the RA must include a prefix information option? If
so, with which bits set? if the autoconfigure bit must be set for this
to work, that seems like a non-starter, since now there is no point in
using DHCP to get an address you already legitimitely have. (I don't
know the details right off here, hence I'm asking.)

Thomas
Markus Stenberg
2007-06-04 11:08:50 UTC
Permalink
On 4.6.2007, at 19.25, marcelo bagnulo braun wrote:
>> Maybe it is just a matter of wording, but the additional
>> protection compared to opportunistic approaches seems slim to me.
>> Certainly, you have CGA-IP as bound entity as opposed to someone
>> on return-routing path, but you still don't have faintest idea who
>> is using the IP. And I thought that (for most part) security
>> authorization issues required something concrete to be identified
>> (whether it is a machine, or user of the machine), and not just
>> 'oh, he went through CGA process to get that IP'.
> but, the IP address is the identity at the IP level, right?
> I mean, from an architectural point of view, at the IP level what
> is needed is to be certain of the identity of the peer at the IP
> level. So using the CGAs would exactly provide that, an SA bound to
> the IP level identity. This would suppress the leap of faith that
> is needed in the opportunistic mode. I mean there are a number of
> processes and security filters, ACL, that run based on IP addresses
> because of this reason, so making certain that the peer is actually
> the owner of the IP address it is claiming to, would provide trust
> to this applications. It may well be the case that additional trust
> is needed because additional information is needed. But building a
> generic any to any trust model that requires no pre arrangement
> (global PKI or shared secret) is a very complex task, and i think
> this is a significant step on this direction. I mean, nowadays, or
> either a global PKI is assumed or all you have is the opportunistic
> mode with the leap of faith. This work would take a step further in
> the deployment of this general any to any trust relations with no
> pre arrangement with an extremely reduced cost. I mean, i would
> expect that the changes required to support this are slim, minor
> extensions to the IKE protocol and the output is the elimination of
> the leap of faith in the opportunistic mode.

I think lots of things are nowadays keyed on IP basis mostly due to
layering violations, bad CLIs/configuration models and little else;
they make network renumbering for example intensely painful.

The question I was trying to phrase is this: If I connect to a
network, generate an arbitrary CGA, what value can someone else
derive from the fact that they do opportunistic encryption with me,
with CGA-based auth as opposed to some arbitrary 'uhm, I am someone.
really.' identity scheme?

The difference in the level of trust between return-routability and
actually confirmed IP address (given no other information) seems slim
to me, as I wouldn't trust either of them for about any purpose.

As I see it, you need

- trusted local/global directory/configuration database (for
discussion's sake, DNSSec - although I wouldn't trust any central
authority not under my own control) + CGA-opportunistic-stuff, or

- PKI/something else in IPsec SPD itself that provides the trust.

What is the value of CGA-based authentication without trusted tie-ins
to higher application layers?

Hmmh. Maybe I'm not just seeing the trust value of identifying IP
address for endpoints - I see more point for the routers on the
network path to identify the correct sender of packet for example,
but this won't provide that. Or for a strict DNS-based mapping to
identify, but that won't happen either with DNSSec as it stands..

>>> - DHCP support for CGAs. An analysis of possible approaches to allow
>>> the usage of the DHCP protocol to assign CGAs will be produced. The
>>> output of the analysis will be an informational document describing
>>> the recommended approaches that will be provided as an input to the
>>> DHC working group where the actual DHCP extensions needed for the
>>> recommended approaches will be defined.
>> DHCP and security shouldn't be mixed
> not sure what do you mean here, but considering that CGAs are
> addresses and that CGAs are used for security and that some folks
> may want to use dhcp for configuring CGAs, then it seems that there
> should be some relation here...

Some folks want strangest of things. However, providing them isn't
always the way to go.

I thought the basic premise of CGA was that they're created on the
host-side, and yes, nothing prevents you from getting extra
parameters from DHCP server, but the whole premise of DHCP RFCs as
they stand seem to not to mandate encryption - adding that would mean
significant rewriting.. As examples, the relay-server IPsec
characteristics are auth-only, there is no encryption framework for
protocol traffic, not to mention chicken-and-egg problem of where to
get the keying material for the DHCP client to start with..

>> - for laughs, look at the current DHCPv6.. It basically assumes
>> that all network links DHCPv6 is used on are trusted,
> that may be a reasonable assumption when current parameters are
> configured, but probably this is not a valid assumption when we
> want to configure cgas which will be used for security purposes, i
> guess

Yes, that's why I brought it up as an example.

>> and effectively due to that anyone on the server-relay, or relay-
>> client legs could 'acquire' the CGA information if you really
>> pushed the address+key tuple that way.
> this is certainly a model, but it is not the only one.

I can imagine few other 'useful' models, and I can bet there being
more out there; but without confidentiality they all assume that the
path between DHCP client and server is trusted, and that's assumption
even RFC3315 doesn't make (it provides for authentication of traffic,
but no confidentiality due to assuming lack of need of
confidentiality for the traffic).

> I mean, it really depends what are the motivations for using dhcp
> and what are the motivations for using CGAs. I mean this model
> assumes an underlying trust model, where the node can fully trust
> not only the links but also the dhcp server. It may well be the
> case that the node doesn't want to dhcp server to have its CGA key
> or that simply you cannot trust the underlying links for this
> purposes.

Indeed. I'm just worried about pushing any combination of insecure
provisioning protocol and security protocols, and offhand the most
useful CGA-oriented DHCP use I can think of is just doing information
request for the configuration information you care about on the host :-)

Cheers,

-Markus
marcelo bagnulo braun
2007-06-04 15:09:10 UTC
Permalink
El 04/06/2007, a las 13:08, Markus Stenberg escribió:

> On 4.6.2007, at 19.25, marcelo bagnulo braun wrote:
>>> Maybe it is just a matter of wording, but the additional protection
>>> compared to opportunistic approaches seems slim to me. Certainly,
>>> you have CGA-IP as bound entity as opposed to someone on
>>> return-routing path, but you still don't have faintest idea who is
>>> using the IP. And I thought that (for most part) security
>>> authorization issues required something concrete to be identified
>>> (whether it is a machine, or user of the machine), and not just 'oh,
>>> he went through CGA process to get that IP'.
>> but, the IP address is the identity at the IP level, right?
>> I mean, from an architectural point of view, at the IP level what is
>> needed is to be certain of the identity of the peer at the IP level.
>> So using the CGAs would exactly provide that, an SA bound to the IP
>> level identity. This would suppress the leap of faith that is needed
>> in the opportunistic mode. I mean there are a number of processes and
>> security filters, ACL, that run based on IP addresses because of this
>> reason, so making certain that the peer is actually the owner of the
>> IP address it is claiming to, would provide trust to this
>> applications. It may well be the case that additional trust is needed
>> because additional information is needed. But building a generic any
>> to any trust model that requires no pre arrangement (global PKI or
>> shared secret) is a very complex task, and i think this is a
>> significant step on this direction. I mean, nowadays, or either a
>> global PKI is assumed or all you have is the opportunistic mode with
>> the leap of faith. This work would take a step further in the
>> deployment of this general any to any trust relations with no pre
>> arrangement with an extremely reduced cost. I mean, i would expect
>> that the changes required to support this are slim, minor extensions
>> to the IKE protocol and the output is the elimination of the leap of
>> faith in the opportunistic mode.
>
> I think lots of things are nowadays keyed on IP basis mostly due to
> layering violations, bad CLIs/configuration models and little else;

Not sure i agree with that. I think that people use the IP address as
identifiers for upper layer because it is the only identifier provided
by the architecture. I mean, today, you identify a node in the network
based on the IP address. In some cases, apps do not want to rely in a
repository to convert an upper layer identifier (like a fqdn) into an
ip address because this would introduce additional failure modes. In
other cases, the IP address is the only identifier contained in the
packet itself (for instance in the router filters).

> they make network renumbering for example intensely painful.
>

yes, this is the price they pay. I guess that the reasons for directly
using IP addresses when the cost is this additional pain in renumbering
must be good and strong ones, if many people are willing to pay the
price.

> The question I was trying to phrase is this: If I connect to a
> network, generate an arbitrary CGA, what value can someone else derive
> from the fact that they do opportunistic encryption with me, with
> CGA-based auth as opposed to some arbitrary 'uhm, I am someone.
> really.' identity scheme?

exactly this is the main question to be answered

with a leap of faith/opportunistic authentication, basically the peers
know that they are communicating with the same node they contacted
initially during the whole lifetime of the communication but they
cannot know who is that node (for any meaning of who)

with a CGA authentication, they can verify that they are communicating
with the owner of the IP address that they are using as the IP level
identifier during the whole communication. This is more than the
previous case, but the question you pose is what can i use this IP
identifier for? i guess this is useful depending on how this IP address
is bind to the actual endpoint that you want to communicate with.

This is useful without any additional tools for applications or
processes that actually use the IP address as identifier for the peer.
such as IP address based ACLs, filters or any app that use the IP
address directly.

However, in other situations this can be part of the trust chain. For
instance consider the case of DNSSec. With DNSSec a peer can verify
that a given IP address is bound to a given IP address. This CGA+IKE
extension can complete the trust chain providing the means to prove
that a the communicating peer is actually the owner of the IP address
contained in the signed RR. By this mean, a peer can verify that the
the fqdn is associated to the IP address using DNSSec and that the
actual communicating peer is associated to the IP address using
CGA+IKE. From an architectural p.o.v. this seems a clean approach,
since the DNSSec proves the binding between fqdn and IP address and the
IP layer proves the binding between the IP address and the
communicating peer. Note that this can also be used without DNSSec,
since in some scenarios it may be easier to intercept the packets
between the nodes than the information returned from the DNS. I mean,
using DNS (not DNSsec) you could establish a not very secure, but
somehow secure binding between the fqdn and the IP address and you
could use the cga+ike to bind the communicating peer with the IP
address obtained by the dns.

In addition to that, another feature provided by this cga+ike approach
is that nobody can impersonate and IP address to perform nasty things.
I mean, with leap of faith/oportunistic schemes, it is possible for an
attacker to create a false IP address and launch an attack from that
address. Oportunistic security doesn't prevent that. However, the
cga+ike scheme would prevent attacker from doing that, since the
attacker will not be able to impersonate a CGA (because it needs the
associated private key). this basically protects the address owner from
attacker having malicious behaviour using other node's identity.



>
> The difference in the level of trust between return-routability and
> actually confirmed IP address (given no other information) seems slim
> to me, as I wouldn't trust either of them for about any purpose.
>
> As I see it, you need
>
> - trusted local/global directory/configuration database (for
> discussion's sake, DNSSec - although I wouldn't trust any central
> authority not under my own control) + CGA-opportunistic-stuff, or
>

i think we should clarify the terminology here.
agree that with DNSsec+CGA IKE stuff you build a complete trust chain,
but this is not the case with other leap of faith oportunistic schemes,
since there is no binding between the IP address and the actual
communicating peer (except from the one provided by the routing system)

> - PKI/something else in IPsec SPD itself that provides the trust.
>
> What is the value of CGA-based authentication without trusted tie-ins
> to higher application layers?
>

the points above aim to answer this question...

> Hmmh. Maybe I'm not just seeing the trust value of identifying IP
> address for endpoints - I see more point for the routers on the
> network path to identify the correct sender of packet for example, but
> this won't provide that.

this is a good observation.

what happens if you are using IPSec tunnel mode and the security
gateway verifies the endpoints based on the IP address? wouldn't CGA
stuff be useful here? I mean, the IPSec gateway will verify that the
communicating peer is the actual owner of the IP address used in the
IPSec SA.

> Or for a strict DNS-based mapping to identify, but that won't happen
> either with DNSSec as it stands..
>

Not sure what do you mean here... DNSSec does provide a secure mapping
between a fqdn and an IP address, doesn't it?

>>>> - DHCP support for CGAs. An analysis of possible approaches to allow
>>>> the usage of the DHCP protocol to assign CGAs will be produced. The
>>>> output of the analysis will be an informational document describing
>>>> the recommended approaches that will be provided as an input to the
>>>> DHC working group where the actual DHCP extensions needed for the
>>>> recommended approaches will be defined.
>>> DHCP and security shouldn't be mixed
>> not sure what do you mean here, but considering that CGAs are
>> addresses and that CGAs are used for security and that some folks may
>> want to use dhcp for configuring CGAs, then it seems that there
>> should be some relation here...
>
> Some folks want strangest of things. However, providing them isn't
> always the way to go.
>

agree, the question is why would it make sense to use dhcp to configure
CGAs

some use cases can be:
- device with low processing power that want to off load the CGA
generation procedure (consider for instance mobile devices). In this
case, probably the whole processing should be performed in the dhcp
server and then the dhcp server must push the address+CGA parameter
data strucutre+private key to the node. The problem here is that the
dhcp server will know the private key of the node, and needs to
actually transmit it using other secure means, which would imply other
form of trust management.

- another somehow different case, is a node that does actually can
generate his key pair, but doesn't want to share it (because of
security issues) but doesn't have enough processing power to generate
the CGA with a given SEC value. In this case, it wants to offload the
CGA generation process but doesn't want the dhcp server to learn its
private key. In this case the node transmits the publi key to the dhcp
server, the dhcp server generates the cga and returns the CGA plus the
CGA parameter data strucutre.

- a site is using dhcp for centrally manage the site. Addresses used in
the site must be included in the server for management reasons. In this
case, the important thing is that the dhcp server is aware of the CGA,
but it doesn't need to know the CGA parameter data structure, the
client needs to register the CGA address in the dhcp server.

there maybe other use cases that have different requirements, the goal
here is to understand this scenarios and produce a reccomendation ofhow
to manage them and identify if additional modification to the dhcp
protocol are required.

> I thought the basic premise of CGA was that they're created on the
> host-side,

yes, but this would imply that they are incompatible with sites using
the dhcp server as a IP address management tool and it may be the cse
that some small devices cannot do the cga generation process

> and yes, nothing prevents you from getting extra parameters from DHCP
> server, but the whole premise of DHCP RFCs as they stand seem to not
> to mandate encryption - adding that would mean significant rewriting..

this maybe ok, as there maybe options that support some scenarios that
do not exchange keying material, as the example i described above

> As examples, the relay-server IPsec characteristics are auth-only,
> there is no encryption framework for protocol traffic, not to mention
> chicken-and-egg problem of where to get the keying material for the
> DHCP client to start with..

agree. maybe CGAs could be used for the dhcp server, so that provides
the initial keying material? (i mean, configuring a cga to the dhcp
server itself)

>
>>> - for laughs, look at the current DHCPv6.. It basically assumes
>>> that all network links DHCPv6 is used on are trusted,
>> that may be a reasonable assumption when current parameters are
>> configured, but probably this is not a valid assumption when we want
>> to configure cgas which will be used for security purposes, i guess
>
> Yes, that's why I brought it up as an example.
>
>>> and effectively due to that anyone on the server-relay, or
>>> relay-client legs could 'acquire' the CGA information if you really
>>> pushed the address+key tuple that way.
>> this is certainly a model, but it is not the only one.
>
> I can imagine few other 'useful' models, and I can bet there being
> more out there; but without confidentiality they all assume that the
> path between DHCP client and server is trusted, and that's assumption
> even RFC3315 doesn't make (it provides for authentication of traffic,
> but no confidentiality due to assuming lack of need of confidentiality
> for the traffic).
>

funny because probably is SeND that provides that trust, right? Do
probably, for thiss case that we are considering here, the assumption
should be revisited, don't you think?

>> I mean, it really depends what are the motivations for using dhcp and
>> what are the motivations for using CGAs. I mean this model assumes an
>> underlying trust model, where the node can fully trust not only the
>> links but also the dhcp server. It may well be the case that the
>> node doesn't want to dhcp server to have its CGA key or that simply
>> you cannot trust the underlying links for this purposes.
>
> Indeed. I'm just worried about pushing any combination of insecure
> provisioning protocol and security protocols, and offhand the most
> useful CGA-oriented DHCP use I can think of is just doing information
> request for the configuration information you care about on the host
> :-)

what cga related information do you think the dhcp server should care
about the host?

Thanks marcelo


>
> Cheers,
>
> -Markus
>
>
Suresh Krishnan
2007-06-04 15:44:15 UTC
Permalink
Hi Markus,

Markus Stenberg wrote:
> The question I was trying to phrase is this: If I connect to a network,
> generate an arbitrary CGA, what value can someone else derive from the
> fact that they do opportunistic encryption with me, with CGA-based auth
> as opposed to some arbitrary 'uhm, I am someone. really.' identity scheme?

The value you gain is that once you start communicating with a node
using your CGA address, nobody else can claim to be you and communicate
with the same node. I think that counts for something.

>
> The difference in the level of trust between return-routability and
> actually confirmed IP address (given no other information) seems slim to
> me, as I wouldn't trust either of them for about any purpose.

CGA based addresses can guard against on-link attackers which return
routability cannot.

Cheers
Suresh
Bernard Aboba
2007-06-04 17:01:26 UTC
Permalink
I have a basic concern with the use of CGA in the IETF, which is that the
CGA design is not currently crypto-agile.

Before we starting "extending" CGA usage, shouldn't we have a firm
foundation for it first?

I have read the rationale for why a single algorithm was
selected, but frankly I don't find it convincing. In almost every
instance where a fixed algorithm has been "baked" into a protocol, at some
point this turned out to be a mistake.

As it stands, were we to require an alternative to RSA (ECC, for example?)
or an alternative hash (do we really think that SHA-1 is likely to remain
viable forever?), CGAs as currently defined will fold like a house of
cards, and the "extensions" with them.
Suresh Krishnan
2007-06-04 17:09:45 UTC
Permalink
Hi Bernard,

Bernard Aboba wrote:
> I have a basic concern with the use of CGA in the IETF, which is that the
> CGA design is not currently crypto-agile.

Yes. This is a big concern. Marcelo and Jari wrote a draft about
updating CGAs to use multiple hash functions.

http://www.ietf.org/internet-drafts/draft-bagnulo-multiple-hash-cga-03.txt

This is an individual submission and is in the RFC Editor's queue.

Cheers
Suresh
Jari Arkko
2007-06-04 17:38:02 UTC
Permalink
Bernard, Suresh,

Yes, hash agility is needed but seems at least partially
a solved problem with the draft that Suresh pointed to.
Signature algorithm agility is a part of Marcelo's proposal
for work.

Jari
Dave Thaler
2007-06-07 01:44:23 UTC
Permalink
Right, there is work on making CGAs crypto-agile and it was presented in
a previous int-area meeting at IETF 66
(http://www3.ietf.org/proceedings/06jul/minutes/intarea.txt item 6).

However, there's another SEND issue that arose in a discussion I was in.
Is there any EKU defined for the X.509 certs used for securing Router
Discovery, that authorizes use as a router? I can't find one, meaning
the only option is to issue a cert that is valid for all possible
purposes. Or am I missing something?

-Dave

> -----Original Message-----
> From: Suresh Krishnan [mailto:***@ericsson.com]
> Sent: Monday, June 04, 2007 10:10 AM
> To: Bernard Aboba
> Cc: int-***@ietf.org
> Subject: Re: [Int-area] Re: SeND & CGA Extensions BOF
>
> Hi Bernard,
>
> Bernard Aboba wrote:
> > I have a basic concern with the use of CGA in the IETF, which is
that
> the
> > CGA design is not currently crypto-agile.
>
> Yes. This is a big concern. Marcelo and Jari wrote a draft about
> updating CGAs to use multiple hash functions.
>
>
http://www.ietf.org/internet-drafts/draft-bagnulo-multiple-hash-cga-03.t
xt
>
> This is an individual submission and is in the RFC Editor's queue.
>
> Cheers
> Suresh
>
>
> _______________________________________________
> Int-area mailing list
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
Jari Arkko
2007-06-08 07:33:06 UTC
Permalink
> However, there's another SEND issue that arose in a discussion I was in.
> Is there any EKU defined for the X.509 certs used for securing Router
> Discovery, that authorizes use as a router? I can't find one, meaning
> the only option is to issue a cert that is valid for all possible
> purposes. Or am I missing something?
>
There is no such definition, as far as I am aware of. The certificates
should contain address range information, but no additional
requirements have been defined.

How does one define a key usage? Can you point me to some
example definitions for other applications?

Jari
James Kempf
2007-06-19 20:13:46 UTC
Permalink
Dave,

Section 6.3 of RFC 3971 contains a certificate profile for routing
authorization in X.509 certs. If that is somehow insufficient or lacking,
then there definitely needs to be a charter item in the charter addressing
the issue.

jak


----- Original Message -----
From: "Dave Thaler" <***@windows.microsoft.com>
To: <int-***@ietf.org>
Sent: Wednesday, June 06, 2007 6:44 PM
Subject: RE: [Int-area] Re: SeND & CGA Extensions BOF


Right, there is work on making CGAs crypto-agile and it was presented in
a previous int-area meeting at IETF 66
(http://www3.ietf.org/proceedings/06jul/minutes/intarea.txt item 6).

However, there's another SEND issue that arose in a discussion I was in.
Is there any EKU defined for the X.509 certs used for securing Router
Discovery, that authorizes use as a router? I can't find one, meaning
the only option is to issue a cert that is valid for all possible
purposes. Or am I missing something?

-Dave

> -----Original Message-----
> From: Suresh Krishnan [mailto:***@ericsson.com]
> Sent: Monday, June 04, 2007 10:10 AM
> To: Bernard Aboba
> Cc: int-***@ietf.org
> Subject: Re: [Int-area] Re: SeND & CGA Extensions BOF
>
> Hi Bernard,
>
> Bernard Aboba wrote:
> > I have a basic concern with the use of CGA in the IETF, which is
that
> the
> > CGA design is not currently crypto-agile.
>
> Yes. This is a big concern. Marcelo and Jari wrote a draft about
> updating CGAs to use multiple hash functions.
>
>
http://www.ietf.org/internet-drafts/draft-bagnulo-multiple-hash-cga-03.t
xt
>
> This is an individual submission and is in the RFC Editor's queue.
>
> Cheers
> Suresh
>
>
> _______________________________________________
> Int-area mailing list
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
Fred Baker
2007-06-04 12:29:13 UTC
Permalink
On Jun 1, 2007, at 11:42 AM, marcelo bagnulo braun wrote:

> we have proposed a BOF on SeND and CGA extensions for the Chicago
> IETF. I attach the proposed charter below. There is a mailing list
> created for the discussion (https://www1.ietf.org/mailman/listinfo/
> cga-ext)

The SAVA BOF is bringing up another issue, that of source address
validation. In theory, using SAA one could open a new address for
each TCP session on a web client; more realistically, someone
concerned enough to do such things would probably change their
address once a minute and use the address for all TCP sessions
started in that minute even if they lapped into a subsequent one. But
if the first hop router is going to verify that the MAC Address and
the IPv6 source address are those of the same machine, SeND or
something like it is going to have to be used to notify the router of
the changing mapping (else it is just an attack vector), or the
router is going to put a stop to it pretty quickly.

It would be nice to verify that we can handle this with SeND, and
make whatever adjustments are required.
marcelo bagnulo braun
2007-06-05 10:53:52 UTC
Permalink
Hi Fred,

El 04/06/2007, a las 14:29, Fred Baker escribió:

>
> On Jun 1, 2007, at 11:42 AM, marcelo bagnulo braun wrote:
>
>> we have proposed a BOF on SeND and CGA extensions for the Chicago
>> IETF. I attach the proposed charter below. There is a mailing list
>> created for the discussion
>> (https://www1.ietf.org/mailman/listinfo/cga-ext)
>
> The SAVA BOF is bringing up another issue, that of source address
> validation. In theory, using SAA one could open a new address for each
> TCP session on a web client; more realistically, someone concerned
> enough to do such things would probably change their address once a
> minute and use the address for all TCP sessions started in that minute
> even if they lapped into a subsequent one. But if the first hop router
> is going to verify that the MAC Address and the IPv6 source address
> are those of the same machine, SeND or something like it is going to
> have to be used to notify the router of the changing mapping (else it
> is just an attack vector), or the router is going to put a stop to it
> pretty quickly.
>
> It would be nice to verify that we can handle this with SeND, and make
> whatever adjustments are required.
>

thanks for the feedback

do you think there are some features that SeND should support to deal
with this type of cases independently of the actual SAVA solution
adopted or do you think that the the changes required to SeND heavily
depend on the actual final SAVA solution? I mean, if it is the first
case, it would be interesting to work on this at this stage, but if it
is the second option probably we should wait till the SAVA solution is
more defined?

Regards, marcelo
Fred Baker
2007-06-05 17:46:36 UTC
Permalink
On Jun 5, 2007, at 3:53 AM, marcelo bagnulo braun wrote:

> do you think there are some features that SeND should support to
> deal with this type of cases independently of the actual SAVA
> solution adopted or do you think that the the changes required to
> SeND heavily depend on the actual final SAVA solution? I mean, if
> it is the first case, it would be interesting to work on this at
> this stage, but if it is the second option probably we should wait
> till the SAVA solution is more defined?

The solution Tsinghua has prototyped is a form of CGA, AFAIK does not
use SeND, and is focused not on system identity but on user identity.
I have a number of thoughts that I have expressed to them and won't
burden this forum with.

The proposal that I have run past them (and will one day get around
to posting as an I-D - it's written now and is in review) focuses not
on identifying users, but on verifying that the system that
originated a datagram using a given source address can be expected to
receive the datagram sent in reply. It applies to both IPv4 and IPv6
technology, and mostly uses existing technologies, including both
uRPF and approaches suited to the local LAN. On the local LAN, it
depends on the association of the source address with something else
- an L2 address or physical port. One weakness of current technology
is that it also depends on having the address assigned to the system
by some outside entity, while most IPv6 systems use SAA, potentially
with some form of privacy addressing. Another is that this assignment
must be visible in some sense to each party that needs to verify the
address pairing, which in a campus wireless LAN has obvious negative
implications. I would far rather enable the use of SAA and privacy
addressing and still be able to associate an L2 address with the set
of L3 addresses a system uses, and do so in a manner that scales to a
campus LAN with thousands of systems on it.

In theory, it seems to me that SeND should be usable for the purpose.
ND has many of the same lack-of-security issues that ARP does, and
also has a chicken/egg problem; in the following sketch, if H1 opens
a connection to H2 using a privacy address calculated on the LAN, R1
does not necessarily learn of the association of H1's MAC and IPv6
addresses until it sees the reply from H2 and sends a Solicitation.
But if it is refusing to forward datagrams for which that association
is not known and therefore not verifiable, it will not send the
datagram H1->H2 to open the session.

+--+ | | +--+
|H1+-+ +-+H2|
+--+ | | +--+
| +--+ +--+ |
+-+R1+-------+R2+-+
| +--+ +--+ |

oops.

Hence, I would like to use SeND to exchange RFC 3401 addresses, and
have H1 do so with any system that it wants to talk with/through on
its local LAN for any address relevant to the association prior to
other L3 exchanges. Host-to-host within the LAN, I would expect that
to be limited to link-local addresses as it is now (one could also
send everything through the router, but that solution doesn't help
LANs that have no router, and has limitations on very busy LANs).
With any system originating SeND-authenticated Router Advertisements,
I would expect that it would do so for any address it wants to use
off-LAN.

If I'm off in the weeds, I'm willing to be told as much. In the case,
though, I'm very concerned.
Jari Arkko
2007-06-08 08:20:19 UTC
Permalink
Hi Fred,

> Hence, I would like to use SeND to exchange RFC 3401 addresses, and
> have H1 do so with any system that it wants to talk with/through on
> its local LAN for any address relevant to the association prior to
> other L3 exchanges. Host-to-host within the LAN, I would expect that
> to be limited to link-local addresses as it is now (one could also
> send everything through the router, but that solution doesn't help
> LANs that have no router, and has limitations on very busy LANs). With
> any system originating SeND-authenticated Router Advertisements, I
> would expect that it would do so for any address it wants to use off-LAN.

This is an interesting case.

So SEND gives you secure mapping of IP to L2 addresses, as
well as address ownership.

SEND currently does nothing for actual traffic packets, so presumably
you are thinking of maintaining some state or performing some
extra verification tasks at the router. This would allow the SEND-
secured mapping and ownership to be used for a packet forwarding
decision.

It would probably be a bad idea for the router to listen to all
NA/NS traffic. So I'm not sure we want to base the state
on that.

Are you thinking of the router making an extra SEND
operation to verify ownership when it for the first time
sees a packet? It could send an NS and verify the resulting
NA. And use this for the forwarding decision.

This would not, however, prevent someone who can forge
L2 source addresses from claiming that an IP packet came
from a host. So for a full solution I guess you would also
need to enforce L2 source addresses, either through
switch configuration or L2 security.

> If I'm off in the weeds, I'm willing to be told as much. In the case,
> though, I'm very concerned.

I don't think you are off in the weeds -- this is an interesting
direction for the SAVA problem. But more work is definitely
needed.

Jari
Fred Baker
2007-06-08 16:43:04 UTC
Permalink
On Jun 8, 2007, at 1:20 AM, Jari Arkko wrote:

> Are you thinking of the router making an extra SEND operation to
> verify ownership when it for the first time sees a packet? It could
> send an NS and verify the resulting NA. And use this for the
> forwarding decision.
>
> This would not, however, prevent someone who can forge L2 source
> addresses from claiming that an IP packet came from a host. So for
> a full solution I guess you would also need to enforce L2 source
> addresses, either through switch configuration or L2 security.

In a network with a switch, the switch can do a number of things that
are very helpful, including suppress non-conforming traffic. Or so
the Catalyst people tell me :-). In a wireless network, at least
according to my limited understanding of 802.11 and 802.16 radio
technologies, the access point potentially schedules use of the air
segment (that is itself a configuration thing - most have the end
systems doing that using RTS/CTS for larger datagrams) but doesn't
act as a switch unless the datagram actually has to traverse to
another LAN domain for delivery.

Yes, one could readily imagine having the receiving host or router
reply to a datagram from an unknown source by dropping the datagram
(there is a ddos vector here, and holding the datagram is a second
ddos vector) and replying with a solicit, expecting that the sender
will now reply to the solicit and repeat the original datagram.

e2e, and noting that many implementations do in fact drop a datagram
that they can't immediately forward due to the implied ddos on the
network if they don't, this means that there is some probability that
a TCP session between systems aggressively using privacy addresses
could easily only get a SYN-ACK response to the third SYN, and only
get the SYN-ACK to traverse e2e on the fourth or fifth. The algorithm
of dropping the datagram that triggers a solicit also has a ddos in
it, which those who build routers argue is a rare case and so not
statistically valuable to chase.
Jari Arkko
2007-06-09 04:36:55 UTC
Permalink
>
> e2e, and noting that many implementations do in fact drop a datagram
> that they can't immediately forward due to the implied ddos on the
> network if they don't, this means that there is some probability that
> a TCP session between systems aggressively using privacy addresses
> could easily only get a SYN-ACK response to the third SYN,

Yes. Can you clarify what is it exactly that you are
suggesting then? Or are you saying that you want
the switch-based approach? Can I go read about
your proposal somewhere?

Jari
marcelo bagnulo braun
2007-06-09 11:29:50 UTC
Permalink
Hi,


El 08/06/2007, a las 10:20, Jari Arkko escribió:

> Hi Fred,
>
>> Hence, I would like to use SeND to exchange RFC 3401 addresses, and
>> have H1 do so with any system that it wants to talk with/through on
>> its local LAN for any address relevant to the association prior to
>> other L3 exchanges. Host-to-host within the LAN, I would expect that
>> to be limited to link-local addresses as it is now (one could also
>> send everything through the router, but that solution doesn't help
>> LANs that have no router, and has limitations on very busy LANs). With
>> any system originating SeND-authenticated Router Advertisements, I
>> would expect that it would do so for any address it wants to use
>> off-LAN.
>
> This is an interesting case.
>
> So SEND gives you secure mapping of IP to L2 addresses, as
> well as address ownership.
>

right

but what is exactly what we are trying to secure? I mean, as i
understand it, SeND is used to secure the process of ND state creation.
I mean, SeND is used to make sure that when ND related state is
installed in a router or a host, the state is authentic. In particular,
the IP address L2 address binding state, the available prefix state and
so on.

However, it seems to me that we are talking about something different
here. As i understand it (maybe i got it wrong), here we don't want to
verify that some state that a router or a host is installing is
authentic, but rather that a given packet is compliant, in particular,
that it has been originated by the owner of the ip address that has
been used as source address. I guess that CGA/SeND would provide the
basis to do that, since CGAs can be used to prove address ownership,
but as understand this, this type of approach would require for every
packet to carry authentication information, since the goal is to prove
that each packet is generated by the address owner, right?

> SEND currently does nothing for actual traffic packets, so presumably
> you are thinking of maintaining some state or performing some
> extra verification tasks at the router. This would allow the SEND-
> secured mapping and ownership to be used for a packet forwarding
> decision.

but for this, we would also need some additional validation information
in the packet itself, right? I mean even if you are certain that there
is a node that owns a given address in the link, you cannot verify that
this node has generated the actual packet that the router is
forwardiing...

or woudl it be enough just to verify that packets contain source
addresses beloging to nodes that exist and we don't need to care about
the fact the source address owner actually generated the packet?

>
> It would probably be a bad idea for the router to listen to all
> NA/NS traffic. So I'm not sure we want to base the state
> on that.
>
> Are you thinking of the router making an extra SEND
> operation to verify ownership when it for the first time
> sees a packet? It could send an NS and verify the resulting
> NA. And use this for the forwarding decision.

this would verify that a given node exists with the source address of
the packet and that it has the associated l2 address

>
> This would not, however, prevent someone who can forge
> L2 source addresses from claiming that an IP packet came
> from a host. So for a full solution I guess you would also
> need to enforce L2 source addresses, either through
> switch configuration or L2 security.

exactly

regards, marcelo


>
>> If I'm off in the weeds, I'm willing to be told as much. In the case,
>> though, I'm very concerned.
>
> I don't think you are off in the weeds -- this is an interesting
> direction for the SAVA problem. But more work is definitely
> needed.
>
> Jari
>
Jari Arkko
2007-06-08 07:43:35 UTC
Permalink
Hi Marcelo,

> do you think there are some features that SeND should support to deal
> with this type of cases independently of the actual SAVA solution
> adopted or do you think that the the changes required to SeND heavily
> depend on the actual final SAVA solution? I mean, if it is the first
> case, it would be interesting to work on this at this stage, but if it
> is the second option probably we should wait till the SAVA solution is
> more defined?

SAVA is not just one thing. Its a framework for a number of different
issues within the source address spoofing space. Things that you
need to do in the local link. Things that you need to do in an AS.
Ideas about ways to do things in the global Internet.

The part that Fred is interested in relates to the local link operation.
What should the router do to verify the validity of the source address
in a packet sent to it? It can verify that its within the configured
subnet, but can it do more?

There are a few different ideas in the SAVA space about the local
link operation. I don't think we have the final answer, though.
This is why Fred is trying to figure out if SEND would help his
problem.

Jari
Jean-Michel Combes
2007-06-05 11:54:06 UTC
Permalink
Hi,

I support such a future work, specially the interaction between IKE and CGA.

Best regards.

JMC.

2007/6/1, marcelo bagnulo braun <***@it.uc3m.es>:
> Hi,
>
> we have proposed a BOF on SeND and CGA extensions for the Chicago IETF.
> I attach the proposed charter below. There is a mailing list created
> for the discussion (https://www1.ietf.org/mailman/listinfo/cga-ext)
>
> If you have comments about the proposed work, it would be appreciated.
>
> Thanks, marcelo
>
>
>
> Proposed charter for SeND & CGA Extensions BOF
>
> Secure Neighbour Discovery (SeND) protocol as defined in RFC 3971
> provides the security mechanisms to protecting the different
> functions performed by the Neighbour Discovery (ND) protocol,
> including the discovery of other nodes on the link and their
> link-layer addresses, router discovery and reachability detection
> for the paths to active neighbors. However, current SeND
> specification lacks of support for ND Proxies as defined in
> RFC 4389. The SeND protocol relies on the usage of
> Cryptographically GEnerated Addresses (CGAs) to provide some of
> these functions, in particular to provide IPv6 address ownership
> proof to the other nodes on the link and authenticate node related
> information of the ND protocol. CGAs are defined in RFC 3972 which
> has been recently updated by RFC 4581 to define the CGA extension
> format and by RFC-to-be draft-bagnulo-multiple-hash-cga-03.txt to
> support multiple hash functions. While CGAs were originally
> defined for the SeND protocol, they have proved to be a useful
> security tool in other environments too, and its usage has been
> proposed to secure other protocols such as the Shim6 multihoming
> protocol and the Mobile IPv6 protocol. As the CGAs become more
> widely used for different purposes, it is necessary to produce
> some extensions to support such new usages.
>
> The objective of this working group is to define extensions related
> to both to the SeND protocol and to the CGAs. The following are
> charter items for the working group:
>
> - Extensions to the SeND protocol to support Neighbour Discovery
> Proxies: SeND protocol as currently defined in RFC 3971 lacks of
> support for ND Proxies defined in RFC 4389. Extensions to the SeND
> protocol will be defined in order to provide equivalent SeND
> security capabilities to ND Proxies.
>
> - Extensions to the IKEv2 protocol to create IPSec SAs associated to
> the CGA key. Because of their cryptographic nature, CGAs are
> inherently bound to the key pair that was used for their generation.
> This is used in existent protocols for proving address ownership.
> However, it would be possible also to use this cryptographic material
> to create a security association between peers. The key benefit of
> such approach is that it allows the creation of a security association
> that is cryptographically bound to the IP address of the end points
> without dependence on a common trust anchor point, eg. PKI. Such
> approach would provide additional protection compared to the
> opportunistic approaches. The proposed work will produce an analysis
> of this type of solution and the required extensions to CGAs and to
> the IKEv2 protocol in order to be able to create IPSec SA using the
> CGAs keys.
>
> - DHCP support for CGAs. An analysis of possible approaches to allow
> the usage of the DHCP protocol to assign CGAs will be produced. The
> output of the analysis will be an informational document describing
> the recommended approaches that will be provided as an input to the
> DHC working group where the actual DHCP extensions needed for the
> recommended approaches will be defined.
>
> - Define a CGA extension to support other public key algorithms: As
> currently defined, CGAs can only use RSA keys in the CGA Parameter
> Data Structure. An extension to update the CGA specification in
> order to multiple public key cryptographic algorithm support will be
> defined.
>
>
> Related drafts:
>
> draft-kempf-mobopts-ringsig-ndproxy-01.txt
> draft-laganier-ike-ipv6-cga-01.txt
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
>
Jean-Michel Combes
2007-06-06 16:26:01 UTC
Permalink
Hi,

in fact I think I have an issue with SEND but I really don't know
whether this BOF would be the right place or not.

Background:
On one side, Prefix delegation (PD) protocols have been specified like
the RFC 3633 based on DHCP, the draft
"draft-ietf-nemo-prefix-delegation-01" for NEMO based on Mobility
Header (MH) or the draft
"draft-sarikaya-netlmm-prefix-delegation-00.txt" for PMIP based on
DHCP/RADIUS/MH.
On the other hand, if I remember correctly (I am not an certs expert),
the CMS protocol allows to get certificates and can be transported
over HTTP/TCP/MINE

The issue, IMHO, is that it seems there is no easy/simple way to
combine PD and certs generation in the case where you want to use SEND
(the RtAdv security part). Am I wrong?

If this is a real issue, where to do the work? In this BOF? In the PKIX WG?

Comments are very welcome :)

Best regards.

JMC.

2007/6/5, Jean-Michel Combes <***@gmail.com>:
> Hi,
>
> I support such a future work, specially the interaction between IKE and CGA.
>
> Best regards.
>
> JMC.
>
> 2007/6/1, marcelo bagnulo braun <***@it.uc3m.es>:
> > Hi,
> >
> > we have proposed a BOF on SeND and CGA extensions for the Chicago IETF.
> > I attach the proposed charter below. There is a mailing list created
> > for the discussion (https://www1.ietf.org/mailman/listinfo/cga-ext)
> >
> > If you have comments about the proposed work, it would be appreciated.
> >
> > Thanks, marcelo
> >
> >
> >
> > Proposed charter for SeND & CGA Extensions BOF
> >
> > Secure Neighbour Discovery (SeND) protocol as defined in RFC 3971
> > provides the security mechanisms to protecting the different
> > functions performed by the Neighbour Discovery (ND) protocol,
> > including the discovery of other nodes on the link and their
> > link-layer addresses, router discovery and reachability detection
> > for the paths to active neighbors. However, current SeND
> > specification lacks of support for ND Proxies as defined in
> > RFC 4389. The SeND protocol relies on the usage of
> > Cryptographically GEnerated Addresses (CGAs) to provide some of
> > these functions, in particular to provide IPv6 address ownership
> > proof to the other nodes on the link and authenticate node related
> > information of the ND protocol. CGAs are defined in RFC 3972 which
> > has been recently updated by RFC 4581 to define the CGA extension
> > format and by RFC-to-be draft-bagnulo-multiple-hash-cga-03.txt to
> > support multiple hash functions. While CGAs were originally
> > defined for the SeND protocol, they have proved to be a useful
> > security tool in other environments too, and its usage has been
> > proposed to secure other protocols such as the Shim6 multihoming
> > protocol and the Mobile IPv6 protocol. As the CGAs become more
> > widely used for different purposes, it is necessary to produce
> > some extensions to support such new usages.
> >
> > The objective of this working group is to define extensions related
> > to both to the SeND protocol and to the CGAs. The following are
> > charter items for the working group:
> >
> > - Extensions to the SeND protocol to support Neighbour Discovery
> > Proxies: SeND protocol as currently defined in RFC 3971 lacks of
> > support for ND Proxies defined in RFC 4389. Extensions to the SeND
> > protocol will be defined in order to provide equivalent SeND
> > security capabilities to ND Proxies.
> >
> > - Extensions to the IKEv2 protocol to create IPSec SAs associated to
> > the CGA key. Because of their cryptographic nature, CGAs are
> > inherently bound to the key pair that was used for their generation.
> > This is used in existent protocols for proving address ownership.
> > However, it would be possible also to use this cryptographic material
> > to create a security association between peers. The key benefit of
> > such approach is that it allows the creation of a security association
> > that is cryptographically bound to the IP address of the end points
> > without dependence on a common trust anchor point, eg. PKI. Such
> > approach would provide additional protection compared to the
> > opportunistic approaches. The proposed work will produce an analysis
> > of this type of solution and the required extensions to CGAs and to
> > the IKEv2 protocol in order to be able to create IPSec SA using the
> > CGAs keys.
> >
> > - DHCP support for CGAs. An analysis of possible approaches to allow
> > the usage of the DHCP protocol to assign CGAs will be produced. The
> > output of the analysis will be an informational document describing
> > the recommended approaches that will be provided as an input to the
> > DHC working group where the actual DHCP extensions needed for the
> > recommended approaches will be defined.
> >
> > - Define a CGA extension to support other public key algorithms: As
> > currently defined, CGAs can only use RSA keys in the CGA Parameter
> > Data Structure. An extension to update the CGA specification in
> > order to multiple public key cryptographic algorithm support will be
> > defined.
> >
> >
> > Related drafts:
> >
> > draft-kempf-mobopts-ringsig-ndproxy-01.txt
> > draft-laganier-ike-ipv6-cga-01.txt
> >
> >
> >
> > _______________________________________________
> > Int-area mailing list
> > Int-***@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/int-area
> >
>
Julien Laganier
2007-06-08 12:28:06 UTC
Permalink
Hi Marcelo, others,

How about including work on extensions to secure
Multicast Listener Discovery Version 2 (MLDv2) for
IPv6, along the same lines that what was done to
secure Neighbor Discovery:

1. protection against spoofing of multicast listener
report messages in which a rogue node unsubscribe its
target from receiving multicast traffic.

2. protection against spoofing of multicast Listener
query messages in which a rogue node with a lower IPv6
address than the current querier will cause querier
duties to be assigned to the rogue node.

On a first glance, it seems 1. could be achieved in a
way similar to what's been done for the neighbor
discovery security part of SEND (i.e. use of CGA to
provide address proof-of-ownership and RSA signatures
to protect message integrity), while 2. would be
similar to the router discovery security part of SEND
(i.e. use of a trust hierarchy delegating router
authorizations, and RSA signatures).

Thoughts?

--julien

On Friday 01 June 2007 17:42, marcelo bagnulo braun
wrote:
> Hi,
>
> we have proposed a BOF on SeND and CGA extensions
> for the Chicago IETF. I attach the proposed charter
> below. There is a mailing list created for the
> discussion
> (https://www1.ietf.org/mailman/listinfo/cga-ext)
>
> If you have comments about the proposed work, it
> would be appreciated.
>
> Thanks, marcelo
>
>
>
> Proposed charter for SeND & CGA Extensions BOF
>
> Secure Neighbour Discovery (SeND) protocol as
> defined in RFC 3971 provides the security mechanisms
> to protecting the different functions performed by
> the Neighbour Discovery (ND) protocol, including the
> discovery of other nodes on the link and their
> link-layer addresses, router discovery and
> reachability detection for the paths to active
> neighbors. However, current SeND specification lacks
> of support for ND Proxies as defined in RFC 4389.
> The SeND protocol relies on the usage of
> Cryptographically GEnerated Addresses (CGAs) to
> provide some of these functions, in particular to
> provide IPv6 address ownership proof to the other
> nodes on the link and authenticate node related
> information of the ND protocol. CGAs are defined in
> RFC 3972 which has been recently updated by RFC 4581
> to define the CGA extension format and by RFC-to-be
> draft-bagnulo-multiple-hash-cga-03.txt to support
> multiple hash functions. While CGAs were originally
> defined for the SeND protocol, they have proved to
> be a useful security tool in other environments too,
> and its usage has been proposed to secure other
> protocols such as the Shim6 multihoming protocol and
> the Mobile IPv6 protocol. As the CGAs become more
> widely used for different purposes, it is necessary
> to produce some extensions to support such new
> usages.
>
> The objective of this working group is to define
> extensions related to both to the SeND protocol and
> to the CGAs. The following are charter items for the
> working group:
>
> - Extensions to the SeND protocol to support
> Neighbour Discovery Proxies: SeND protocol as
> currently defined in RFC 3971 lacks of support for
> ND Proxies defined in RFC 4389. Extensions to the
> SeND protocol will be defined in order to provide
> equivalent SeND security capabilities to ND Proxies.
>
> - Extensions to the IKEv2 protocol to create IPSec
> SAs associated to the CGA key. Because of their
> cryptographic nature, CGAs are inherently bound to
> the key pair that was used for their generation.
> This is used in existent protocols for proving
> address ownership. However, it would be possible
> also to use this cryptographic material to create a
> security association between peers. The key benefit
> of such approach is that it allows the creation of a
> security association that is cryptographically bound
> to the IP address of the end points without
> dependence on a common trust anchor point, eg. PKI.
> Such approach would provide additional protection
> compared to the opportunistic approaches. The
> proposed work will produce an analysis of this type
> of solution and the required extensions to CGAs and
> to the IKEv2 protocol in order to be able to create
> IPSec SA using the CGAs keys.
>
> - DHCP support for CGAs. An analysis of possible
> approaches to allow the usage of the DHCP protocol
> to assign CGAs will be produced. The output of the
> analysis will be an informational document
> describing the recommended approaches that will be
> provided as an input to the DHC working group where
> the actual DHCP extensions needed for the
> recommended approaches will be defined.
>
> - Define a CGA extension to support other public key
> algorithms: As currently defined, CGAs can only use
> RSA keys in the CGA Parameter Data Structure. An
> extension to update the CGA specification in order
> to multiple public key cryptographic algorithm
> support will be defined.
>
>
> Related drafts:
>
> draft-kempf-mobopts-ringsig-ndproxy-01.txt
> draft-laganier-ike-ipv6-cga-01.txt
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
Brian Haberman
2007-06-08 14:13:50 UTC
Permalink
Hi Julien,

Julien Laganier wrote:
> Hi Marcelo, others,
>
> How about including work on extensions to secure
> Multicast Listener Discovery Version 2 (MLDv2) for
> IPv6, along the same lines that what was done to
> secure Neighbor Discovery:
>
> 1. protection against spoofing of multicast listener
> report messages in which a rogue node unsubscribe its
> target from receiving multicast traffic.

This type of attack is mitigated by the MLD state machine. When a
router receives a Report that signals no more interest in a particular
group it first sends out a group-specific query to ensure that interest
does not exist. When that query is sent, the target node will respond
that it is still interested.

>
> 2. protection against spoofing of multicast Listener
> query messages in which a rogue node with a lower IPv6
> address than the current querier will cause querier
> duties to be assigned to the rogue node.

This would be useful in my opinion.

Regards,
Brian
Brian Haberman
2007-06-08 14:13:50 UTC
Permalink
Hi Julien,

Julien Laganier wrote:
> Hi Marcelo, others,
>
> How about including work on extensions to secure
> Multicast Listener Discovery Version 2 (MLDv2) for
> IPv6, along the same lines that what was done to
> secure Neighbor Discovery:
>
> 1. protection against spoofing of multicast listener
> report messages in which a rogue node unsubscribe its
> target from receiving multicast traffic.

This type of attack is mitigated by the MLD state machine. When a
router receives a Report that signals no more interest in a particular
group it first sends out a group-specific query to ensure that interest
does not exist. When that query is sent, the target node will respond
that it is still interested.

>
> 2. protection against spoofing of multicast Listener
> query messages in which a rogue node with a lower IPv6
> address than the current querier will cause querier
> duties to be assigned to the rogue node.

This would be useful in my opinion.

Regards,
Brian
Julien Laganier
2007-06-08 12:28:06 UTC
Permalink
Hi Marcelo, others,

How about including work on extensions to secure
Multicast Listener Discovery Version 2 (MLDv2) for
IPv6, along the same lines that what was done to
secure Neighbor Discovery:

1. protection against spoofing of multicast listener
report messages in which a rogue node unsubscribe its
target from receiving multicast traffic.

2. protection against spoofing of multicast Listener
query messages in which a rogue node with a lower IPv6
address than the current querier will cause querier
duties to be assigned to the rogue node.

On a first glance, it seems 1. could be achieved in a
way similar to what's been done for the neighbor
discovery security part of SEND (i.e. use of CGA to
provide address proof-of-ownership and RSA signatures
to protect message integrity), while 2. would be
similar to the router discovery security part of SEND
(i.e. use of a trust hierarchy delegating router
authorizations, and RSA signatures).

Thoughts?

--julien

On Friday 01 June 2007 17:42, marcelo bagnulo braun
wrote:
> Hi,
>
> we have proposed a BOF on SeND and CGA extensions
> for the Chicago IETF. I attach the proposed charter
> below. There is a mailing list created for the
> discussion
> (https://www1.ietf.org/mailman/listinfo/cga-ext)
>
> If you have comments about the proposed work, it
> would be appreciated.
>
> Thanks, marcelo
>
>
>
> Proposed charter for SeND & CGA Extensions BOF
>
> Secure Neighbour Discovery (SeND) protocol as
> defined in RFC 3971 provides the security mechanisms
> to protecting the different functions performed by
> the Neighbour Discovery (ND) protocol, including the
> discovery of other nodes on the link and their
> link-layer addresses, router discovery and
> reachability detection for the paths to active
> neighbors. However, current SeND specification lacks
> of support for ND Proxies as defined in RFC 4389.
> The SeND protocol relies on the usage of
> Cryptographically GEnerated Addresses (CGAs) to
> provide some of these functions, in particular to
> provide IPv6 address ownership proof to the other
> nodes on the link and authenticate node related
> information of the ND protocol. CGAs are defined in
> RFC 3972 which has been recently updated by RFC 4581
> to define the CGA extension format and by RFC-to-be
> draft-bagnulo-multiple-hash-cga-03.txt to support
> multiple hash functions. While CGAs were originally
> defined for the SeND protocol, they have proved to
> be a useful security tool in other environments too,
> and its usage has been proposed to secure other
> protocols such as the Shim6 multihoming protocol and
> the Mobile IPv6 protocol. As the CGAs become more
> widely used for different purposes, it is necessary
> to produce some extensions to support such new
> usages.
>
> The objective of this working group is to define
> extensions related to both to the SeND protocol and
> to the CGAs. The following are charter items for the
> working group:
>
> - Extensions to the SeND protocol to support
> Neighbour Discovery Proxies: SeND protocol as
> currently defined in RFC 3971 lacks of support for
> ND Proxies defined in RFC 4389. Extensions to the
> SeND protocol will be defined in order to provide
> equivalent SeND security capabilities to ND Proxies.
>
> - Extensions to the IKEv2 protocol to create IPSec
> SAs associated to the CGA key. Because of their
> cryptographic nature, CGAs are inherently bound to
> the key pair that was used for their generation.
> This is used in existent protocols for proving
> address ownership. However, it would be possible
> also to use this cryptographic material to create a
> security association between peers. The key benefit
> of such approach is that it allows the creation of a
> security association that is cryptographically bound
> to the IP address of the end points without
> dependence on a common trust anchor point, eg. PKI.
> Such approach would provide additional protection
> compared to the opportunistic approaches. The
> proposed work will produce an analysis of this type
> of solution and the required extensions to CGAs and
> to the IKEv2 protocol in order to be able to create
> IPSec SA using the CGAs keys.
>
> - DHCP support for CGAs. An analysis of possible
> approaches to allow the usage of the DHCP protocol
> to assign CGAs will be produced. The output of the
> analysis will be an informational document
> describing the recommended approaches that will be
> provided as an input to the DHC working group where
> the actual DHCP extensions needed for the
> recommended approaches will be defined.
>
> - Define a CGA extension to support other public key
> algorithms: As currently defined, CGAs can only use
> RSA keys in the CGA Parameter Data Structure. An
> extension to update the CGA specification in order
> to multiple public key cryptographic algorithm
> support will be defined.
>
>
> Related drafts:
>
> draft-kempf-mobopts-ringsig-ndproxy-01.txt
> draft-laganier-ike-ipv6-cga-01.txt
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
Behcet Sarikaya
2007-06-08 19:31:14 UTC
Permalink
Hi Brian, Julien,

----- Original Message ----
From: Brian Haberman <***@innovationslab.net>
To: Julien Laganier <***@laposte.net>
Cc: INT Area <int-***@ietf.org>; int-***@lists.ietf.org
Sent: Friday, June 8, 2007 9:13:50 AM
Subject: Re: [Int-area] SeND & CGA Extensions BOF

Hi Julien,

Julien Laganier wrote:
> Hi Marcelo, others,
>
> How about including work on extensions to secure
> Multicast Listener Discovery Version 2 (MLDv2) for
> IPv6, along the same lines that what was done to
> secure Neighbor Discovery:
>
> 1. protection against spoofing of multicast listener
> report messages in which a rogue node unsubscribe its
> target from receiving multicast traffic.

This type of attack is mitigated by the MLD state machine. When a
router receives a Report that signals no more interest in a particular
group it first sends out a group-specific query to ensure that interest
does not exist. When that query is sent, the target node will respond
that it is still interested.

>
> 2. protection against spoofing of multicast Listener
> query messages in which a rogue node with a lower IPv6
> address than the current querier will cause querier
> duties to be assigned to the rogue node.

This would be useful in my opinion.

Regards,
Brian

[behcet] I think these (or this) issues need better be handled in multicast related WG in int area, magma is one. We recently started multimob mailing list (cc'ed), if the above issue is likely to arise in mobile environments, multimob could also be considered.

Regards,

Behcet
Ralph Droms
2007-06-20 17:27:31 UTC
Permalink
I think the usual deployment scenario to use DHCPv6 will be to configure
routers to send RAs with M/O bits set and PIOs for prefixes on the link with
'A' bits not set. That is, hosts will be aware of prefixes on the link, for
routing decisions, while using only addresses assigned through DHCP. We've
tested this deployment scenario with Vista and some flavors of *NIX and it
works as expected.

And, I think the usual deployment scenario will be to coordinate the routers
and the DHCP service so that the same prefixes are advertised on the link
and used for address assignment.

Assuming DHCP is desired by the network administrator, the host could, in
fact, generate CGA addresses and send them to the DHCP server as a hint.
If you're postulating changes to the IPv6 stack to generate the CGAs, it
seems reasonable to me that the DHCPv6 implementation could be extended to
send the CGA as a hint.

In the case that the network administrator wants to assign an address from,
say, only one of the available prefixes on the link, I suppose the host
could generate a CGA from each prefix, and then the DHCP server can select
the appropriate CGA to actually assign.

- Ralph


On 6/20/07 12:58 PM, "James Kempf" <***@docomolabs-usa.com> wrote:

> The basic issue is that the host must know which subnet prefix to use prior
> to sending the DHCP REQUEST if it is to generate a CGA. The prefix is part
> of the CGA parameters data structure used in the hash calculation for the
> crypto-id, as described in Section 3 of RFC 3972. The host then includes an
> IA Address Option (Section 22.6 of RFC 3315) with the address in a DHCP
> REQUEST. So that means that the RA must include a prefix information option
> so that the host has the prefix in order to generate the address.
>
> Exactly how that interacts with address autoconfiguration is something that
> would need to be addressed in generating the draft describing how to do CGAs
> with DHCP. I don't know whether hosts using DHCPv6 commonly propose
> addresses today, but I suspect probably not, since it isn't done in IPv4 and
> I suspect DHCPv6 is most commonly used in a way that works as much like the
> v4 case as possible. Others with more operational and deployment knowledge
> of DHCP use please correct me if I am wrong.
>
> jak
>
> ----- Original Message -----
> From: "Thomas Narten" <***@us.ibm.com>
> To: "James Kempf" <***@docomolabs-usa.com>
> Cc: "marcelo bagnulo braun" <***@it.uc3m.es>; "Stig Venaas"
> <***@uninett.no>; "INT Area" <int-***@ietf.org>
> Sent: Wednesday, June 20, 2007 8:32 AM
> Subject: Re: DHCPv6 and CGA (was: Re: [Int-area] SeND & CGA Extensions BOF)
>
>
> "James Kempf" <***@docomolabs-usa.com> writes:
>
>> I think it is already possible for a node to use CGAs with DHCPv6. 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. 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.
>
> Do you mean that the RA must include a prefix information option? If
> so, with which bits set? if the autoconfigure bit must be set for this
> to work, that seems like a non-starter, since now there is no point in
> using DHCP to get an address you already legitimitely have. (I don't
> know the details right off here, hence I'm asking.)
>
> Thomas
>
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
James Kempf
2007-06-20 18:52:30 UTC
Permalink
Right.

Given a host stack that already implements CGAs for autoconfigured
addresses, I think the changes needed to allow CGAs as hints for DHCP are
fairly minor.

So I think the question is, are network administrators concerned enough
about address spoofing on networks where addresses are configured through
DHCPv6 that they would be interested in deploying this?

jak




----- Original Message -----
From: "Ralph Droms" <***@cisco.com>
To: "James Kempf" <***@docomolabs-usa.com>; "Thomas Narten"
<***@us.ibm.com>
Cc: "INT Area" <int-***@ietf.org>
Sent: Wednesday, June 20, 2007 10:27 AM
Subject: Re: DHCPv6 and CGA (was: Re: [Int-area] SeND & CGA Extensions BOF)


I think the usual deployment scenario to use DHCPv6 will be to configure
routers to send RAs with M/O bits set and PIOs for prefixes on the link with
'A' bits not set. That is, hosts will be aware of prefixes on the link, for
routing decisions, while using only addresses assigned through DHCP. We've
tested this deployment scenario with Vista and some flavors of *NIX and it
works as expected.

And, I think the usual deployment scenario will be to coordinate the routers
and the DHCP service so that the same prefixes are advertised on the link
and used for address assignment.

Assuming DHCP is desired by the network administrator, the host could, in
fact, generate CGA addresses and send them to the DHCP server as a hint.
If you're postulating changes to the IPv6 stack to generate the CGAs, it
seems reasonable to me that the DHCPv6 implementation could be extended to
send the CGA as a hint.

In the case that the network administrator wants to assign an address from,
say, only one of the available prefixes on the link, I suppose the host
could generate a CGA from each prefix, and then the DHCP server can select
the appropriate CGA to actually assign.

- Ralph


On 6/20/07 12:58 PM, "James Kempf" <***@docomolabs-usa.com> wrote:

> The basic issue is that the host must know which subnet prefix to use
> prior
> to sending the DHCP REQUEST if it is to generate a CGA. The prefix is part
> of the CGA parameters data structure used in the hash calculation for the
> crypto-id, as described in Section 3 of RFC 3972. The host then includes
> an
> IA Address Option (Section 22.6 of RFC 3315) with the address in a DHCP
> REQUEST. So that means that the RA must include a prefix information
> option
> so that the host has the prefix in order to generate the address.
>
> Exactly how that interacts with address autoconfiguration is something
> that
> would need to be addressed in generating the draft describing how to do
> CGAs
> with DHCP. I don't know whether hosts using DHCPv6 commonly propose
> addresses today, but I suspect probably not, since it isn't done in IPv4
> and
> I suspect DHCPv6 is most commonly used in a way that works as much like
> the
> v4 case as possible. Others with more operational and deployment knowledge
> of DHCP use please correct me if I am wrong.
>
> jak
>
> ----- Original Message -----
> From: "Thomas Narten" <***@us.ibm.com>
> To: "James Kempf" <***@docomolabs-usa.com>
> Cc: "marcelo bagnulo braun" <***@it.uc3m.es>; "Stig Venaas"
> <***@uninett.no>; "INT Area" <int-***@ietf.org>
> Sent: Wednesday, June 20, 2007 8:32 AM
> Subject: Re: DHCPv6 and CGA (was: Re: [Int-area] SeND & CGA Extensions
> BOF)
>
>
> "James Kempf" <***@docomolabs-usa.com> writes:
>
>> I think it is already possible for a node to use CGAs with DHCPv6. 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. 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.
>
> Do you mean that the RA must include a prefix information option? If
> so, with which bits set? if the autoconfigure bit must be set for this
> to work, that seems like a non-starter, since now there is no point in
> using DHCP to get an address you already legitimitely have. (I don't
> know the details right off here, hence I'm asking.)
>
> Thomas
>
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-***@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
Loading...