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