Subject: [Int-area] SeND & CGA Extensions BOF

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 1 Jun 2007 17:42:28 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 4 Jun 2007 10:41:32 +0900

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

> the IKEv2 protocol in order to be able to create IPSec SA using the

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

> 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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 4 Jun 2007 12:25:04 +0200

Hi Markus,

thanks for your comments, see reply below...

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

> of the machine), and not just 'oh, he went through CGA process to get 

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

> 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

---

From: Stig Venaas <[email-masked]>
Date: Mon, 04 Jun 2007 12:51:40 +0200

marcelo bagnulo braun wrote:
[...]
> 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

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 4 Jun 2007 20:08:50 +0900

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

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

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

---

From: Fred Baker <[email-masked]>
Date: Mon, 4 Jun 2007 08:29:13 -0400

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.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 4 Jun 2007 17:09:10 +0200

El 04/06/2007, a las 13:08, Markus Stenberg escribió:

>>> 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 
>>> (whether it is a machine, or user of the machine), and not just 'oh, 
>>> he went through CGA process to get that IP'.
>> 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.
>

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.

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

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.

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

> to higher application layers?

the points above aim to answer this question...

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

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

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.

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

>> configured, but probably this is not a valid assumption when we want 
>> to configure cgas which will be used for security purposes, i guess
>
> 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?

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

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

Thanks marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 4 Jun 2007 17:13:33 +0200

Hi Stig,

thanks for the comments, see reply in line...

El 04/06/2007, a las 12:51, Stig Venaas escribió:
> 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

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

>>> reasons

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 04 Jun 2007 11:44:15 -0400

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.

> 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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Jun 2007 10:01:26 -0700 (PDT)

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.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 04 Jun 2007 13:09:45 -0400

Hi Bernard,

> 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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Jun 2007 01:38:02 +0800

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 5 Jun 2007 12:53:52 +0200

Hi Fred,

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

>> created for the discussion 
>> (https://www1.ietf.org/mailman/listinfo/cga-ext)
>
> 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

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 5 Jun 2007 13:54:06 +0200

Hi,

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

Best regards.

JMC.

---

From: Fred Baker <[email-masked]>
Date: Tue, 5 Jun 2007 10:46:36 -0700

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.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 6 Jun 2007 18:26:01 +0200

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.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 6 Jun 2007 18:44:23 -0700

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:[email-masked]]
> Sent: Monday, June 04, 2007 10:10 AM
> To: Bernard Aboba
> Cc: [email-masked]
> 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
http://www.ietf.org/internet-drafts/draft-bagnulo-multiple-hash-cga-03.t
xt

---

From: Jari Arkko <[email-masked]>
Date: Fri, 08 Jun 2007 10:33:06 +0300

> 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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 08 Jun 2007 10:43:35 +0300

Hi Marcelo,

> is the second option probably we should wait till the SAVA solution is

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 08 Jun 2007 11:20:19 +0300

Hi Fred,

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

> 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

---

From: Julien Laganier <[email-masked]>
Date: Fri, 8 Jun 2007 14:28:06 +0200

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 rFrom [email-masked] Fri Jun 08 08:26:24 2007
From: Julien Laganier <[email-masked]>
To: [email-masked]
Subject: Re: [Int-area] SeND & CGA Extensions BOF
Date: Fri, 8 Jun 2007 14:28:06 +0200
Cc: INT Area <[email-masked]>

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

---

From: Julien Laganier <[email-masked]>
Date: Fri, 8 Jun 2007 14:28:06 +0200

Hi Marcelo, others,

addresndproxy-01.txt

---

From: Julien Laganier <[email-masked]>
Date: Fri, 8 Jun 2007 14:28:06 +0200

Hi Marcelo, others,

Thoughts?

--julien

wrote:
> recommended apps than the current querier will cause querier 

Thoughts?

--julien

roaches will be defined.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 08 Jun 2007 10:13:50 -0400

Hi Julien,

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

> duties to be assigned to the rogue node.  

This would be useful in my opinion.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 08 Jun 2007 10:13:50 -0400

Hi Julien,

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 08 Jun 2007 10:13:50 -0400

Hi Julien,

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 08 Jun 2007 10:13:50 -0400

Hi Julien,

Regards,
Brian

---

From: Fred Baker <[email-masked]>
Date: Fri, 8 Jun 2007 09:43:04 -0700

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.

---

From: Jari Arkko <[email-masked]>
Date: Sat, 09 Jun 2007 07:36:55 +0300

> 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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 9 Jun 2007 13:29:50 +0200

Hi,

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

> secured mapping and ownership to be used for a packet forwarding

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?

> 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

> switch configuration or L2 security.

exactly

regards, marcelo

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Jun 2007 10:28:03 -0700

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" <[email-masked]>
To: "Stig Venaas" <[email-masked]>
Cc: "INT Area" <[email-masked]>
Sent: Monday, June 04, 2007 8:13 AM
Subject: Re: [Int-area] SeND & CGA Extensions BOF

Hi Stig,

thanks, marcelo

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Jun 2007 13:13:46 -0700

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" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 06, 2007 6:44 PM
Subject: RE: [Int-area] Re: SeND & CGA Extensions BOF

-Dave

that

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Jun 2007 14:07:39 -0700

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

Not true; the client can configure a CGA address from
an advertised prefix and "propose" it to the server by
including it in an IA Address option ([RFC3315], Section
22.6). The server should then be willing to assign the
address to the client as long as it isn't a duplicate.

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Jun 2007 14:10:01 -0700

> 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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Jun 2007 14:57:39 -0700

Fred,

Thanx for the correction.

Do you see any aspect of CGA use with DHCP that is not currently covered by 
RFC 3315?

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "marcelo bagnulo braun" 
<[email-masked]>; "Stig Venaas" <[email-masked]>
Cc: "INT Area" <[email-masked]>
Sent: Tuesday, June 19, 2007 2:07 PM
Subject: RE: DHCPv6 and CGA (was: Re: [Int-area] SeND & CGA Extensions BOF)

Fred

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Jun 2007 14:59:59 -0700

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" <[email-masked]>
To: "James Kempf" <[email-masked]>; "marcelo bagnulo braun" 
<[email-masked]>; "Stig Venaas" <[email-masked]>
Cc: "INT Area" <[email-masked]>
Sent: Tuesday, June 19, 2007 2:10 PM
Subject: RE: DHCPv6 and CGA (was: Re: [Int-area] SeND & CGA Extensions BOF)

Fred

---

From: Thomas Narten <[email-masked]>
Date: Wed, 20 Jun 2007 11:32:05 -0400

> 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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 20 Jun 2007 09:58:43 -0700

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" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "marcelo bagnulo braun" <[email-masked]>; "Stig Venaas" 
<[email-masked]>; "INT Area" <[email-masked]>
Sent: Wednesday, June 20, 2007 8:32 AM
Subject: Re: DHCPv6 and CGA (was: Re: [Int-area] SeND & CGA Extensions BOF)

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Wed, 20 Jun 2007 13:27:31 -0400

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

---

From: Alberto García <[email-masked]>
Date: Wed, 20 Jun 2007 19:47:20 +0200

Hi,
In addition to the current thread, and regarding to CGA configuration, maybe
there are some aspects that could be nice to have (either provided by DHCP,
or maybe by RA):
- recommendation for the Sec values to be used by the hosts when generating
the CGA, since the administrator could have a better idea about the security
requirements of the network. If Extension Fields for the CGA are defined,
maybe some of them could be nice to be set by the network administrator.
This could be done though either through RA or DHCP.
- my understanding of MCGA (for SEND proxies) is that the end hosts need to
know that there is the possibility of being proxied, so that an MCGA should
be generated, and should be configured with some keying material from the
proxies to generate the MCGA. Additionally, the proxies need to know the
public key of the host to which they could proxy to. Is there any
"automated" mechanism for this? If not, maybe DHCP could do the job.
- the computation of the Modifier of a CGA/MCGA in order to comply with a
certain Sec value could be CPU-intensive: around 5000 seconds to compute a
Sec=2 Modifier with openSSL in a dual core system. Some devices (i.e.
mobile, limited capacity, etc.) could require too much time, or have their
batteries drained because of this computation. Maybe an interaction through
DHCP, or maybe other protocol could solve the problem (or maybe this is out
of any standardization effort)

Best regards,
Alberto

-----Mensaje original-----
De: James Kempf [mailto:[email-masked]] 
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,

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "marcelo bagnulo braun" 

Fred

---

From: "James Kempf" <[email-masked]>
Date: Wed, 20 Jun 2007 11:52:30 -0700

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" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Thomas Narten" 
<[email-masked]>
Cc: "INT Area" <[email-masked]>
Sent: Wednesday, June 20, 2007 10:27 AM
Subject: Re: DHCPv6 and CGA (was: Re: [Int-area] SeND & CGA Extensions BOF)

- Ralph