[CGA-EXT] Re: CGA Extensions BOF situation

Hi,

First of all, i would like to thank Jari for his support during all  
this process and his ideas about how to move forward with this.

I think that in order to be in good shape for having a bof for  
Vancouver, we need discussion on the different proposed work items.

I include a list of work items that were included in the proposed  
charter or that were mentioned during the discussion.

I would encourage people that are interested in the different items and  
would like to see them included in the charter for the next bof  
proposal for vancouver to express themselves on the mailing list and if  
possible to write a short draft (or update an old draft describing the  
motivations for the work. If people are interested in working in some  
of the items, please let me know and i can put you in contact with  
other people that would be also interested in the same topic.

Here is a list of work items open for discussion

------------------------------------------------
Work Originally included in the proposed charter
------------------------------------------------

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

---------------------------------
Additional work to be considered
---------------------------------

- Moving RFC3971 and RFC3972 to draft standard (J.Kempf)

- SeND extensions to perform source address validation at the local  
link level (F. Baker)
   see message  
http://www1.ietf.org/mail-archive/web/int-area/current/msg00792.html

- Extensions to secure Multicast Listener Discovery Version 2 (MLDv2)  
for IPv6 (J. Laganier)
   see message  
http://www1.ietf.org/mail-archive/web/int-area/current/msg00807.html
   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.

- Definition of EKU for the X.509 certs used for securing Router  
Discovery, that authorizes use as a router (D. Thaler)
   see message  
http://www1.ietf.org/mail-archive/web/int-area/current/msg00803.html

- Prefix delegation and certificate delegation (J.M. Combes)
   see message  
http://www1.ietf.org/mail-archive/web/int-area/current/msg00802.html

- SeND optimizations for wireless environments (W. Haddad) based on  
draft-haddad-mipshop-optisend-02
   http://tools.ietf.org/html/draft-haddad-mipshop-optisend-02
   Abstract:
    This memo describes a new set of mechanisms, which aims to increase
    the Secure Neighbor Discovery (SEND) protocol usability by reducing
    the required processing power on small devices and adapting it to
    mobile environment requirements while maintaining its efficiency.

- Cryptographic layering enforcement (CLE) (G. Montenegro) based on  
draft-montenegro-send-cga-rr-01.txt

http://www.join.uni-muenster.de/Dokumente/drafts/draft-montenegro-send- 
cga-rr-01.txt
   Abstract:
    The known security vulnerabilities in Neighbor Discovery have not
    been properly dealt with.  This note suggests some techniques based
    on cryptographically generated addresses and probes that may be
    applied even in the absence of a pre-established security
    relationship between the parties involved.

- Link Layer HBA Based on  
http://www.join.uni-muenster.de/Dokumente/drafts/draft-laganier-send- 
ll-hba-00.txt
   Abstract:
    The current mechanisms used by Secure Neighbor Discovery (SEND) to
    secure the Neighbor Discovery Protocol (NDP) relies almost solely on
    public key cryptography (i.e.  Certificates and/or Cryptographically
    Generated Addresses).  While these approaches provide very strong
    guarantees on the authenticity of an IP address to link layer address
    mapping, they are computationally expensive, which might be a problem
    on resource-constrained devices.

    It is also recognized in the SEND specification that it does not
    compensate for an insecure link layer; more specifically, no
    protections are offered against spoofing, link disruption, or bombing
    DoS attacks launched at the link layer.  Accordingly, this note
    suggests an alternative to the current specification of SEND which
    leverage on the deemed required link layer security to secure NDP.
    This technique is based on the use of a specific kind of IPv6
    addresses, the so-called Link Layer Hashed Based Addresses (LL-HBA),
    and of link layer address reachability tests.

    When the link layer security prevents attacker to redirect frames at
    the link layer layer, this technique allows to provide some level of
    security to NDP while relying solely on symmetric (i.e.,
    computationally inexpensive) cryptography.

Comments on this or other potential work is welcome

Regards, marcelo

El 15/06/2007, a las 13:19, Jari Arkko escribió:

>
> This is a heads up of what is going on with the
> CGA Extensions BOF proposal.
>
> The proposal for a WG is clear and well justified,
> particularly in the areas that relate to maintenance
> of existing RFCs. Chartering work for maintaining
> an existing spec is an obviously useful thing.
> There has been a fair number of people interested
> in this, and the discussion has identified possible
> new work items. Some of the work items related to
> new uses (source address validation, IKEv2) have
> been more controversial and need further
> documentation & discussion.
>
> The main question mark relating to this BOF has
> been the state of implementation and deployment of
> SEND. The IETF should spend effort only when technology
> has promise of making a significant impact in real-world
> networking. We have privately been told that efforts
> are underway, however.
>
> After discussions with Marcelo, IAB, IESG, and the
> IP Directorate, Marcelo and I have decided to
> postpone the BOF to Vancouver. By Vancouver,
> we expect the following to have happened:
>
> - Additional documents become available and
>   are discussed on the list. This is particularly
>   needed for the maintenance items that come
>   up during recent int-area list discussion and
>   in the new uses of CGAs in other contexts than
>   SEND.
>
> - More information about implementation status and
>   real-world usage plans has become available.
>
> - An interoperability event has been held. Marcelo
>   is planning one for the fall.
>
> - A charter discussion is held on the list to
>   determine which of many possible items are
>   actually the most interesting ones.
>
> With these items completed, we expect the meeting
> in Vancouver to conclude that a WG should be
> created, and move on to progress work. We
> expect people to work on the above items
> starting from now.
>
> Jari
>

_______________________________________________
CGA-EXT mailing list
CGA-EXT@ietf.org
https://www1.ietf.org/mailman/listinfo/cga-ext