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 > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
