RE: 6MAN Agenda for IETF86

Dear Mark,

>I'm curious what the specific problem with SEND is. Is it the lack of
commonly available implementations, or the manual work to bootstrap it (IIRC
that is required), or both? The IETF obviously can't >solve the former. If
it is the latter, I wonder if the "Better-Than-Nothing" model, used for
IPsec in RFC5386, could be applied to SEND?

One problem with SEND is that the time it takes for the CGA algorithm
generation is not fast enough for IP address generation and more importantly
the verification process using CGA is not fast enough either. A second
problem concerns the Public Key Infrastructure.
For the first problem, I offered the use of SSAS which is faster. For the
second problem I have another solution, but first I need to check some of
the other new RFCs about Certification and  I will do this before the IETF
meeting so that I can also include it in my draft.

Thank you,
Hosnieh

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Mark
Smith
Sent: Tuesday, March 05, 2013 9:18 PM
To: Michael Richardson; Karl Auer
Cc: ipv6@ietf.org
Subject: Re: 6MAN Agenda for IETF86

Hi,

----- Original Message -----
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> To: Karl Auer <kauer@biplane.com.au>
> Cc: ipv6@ietf.org
> Sent: Wednesday, 6 March 2013 5:48 AM
> Subject: Re: 6MAN Agenda for IETF86
> 
> 
>>>>>>  "Karl" == Karl Auer <kauer@biplane.com.au>
> writes:
>     Karl> On Mon, 2013-03-04 at 16:02 -0800, Bob Hinden wrote:
>     >> A Simple Secure Addressing Generation Scheme for IPv6
>     >> AutoConfiguration draft-rafiee-6man-ssas-01.txt [...]
>     >> DHCPv6/SLAAC Address Configuration Interaction Problem 
> Statement
>     >> draft-liu-bonica-dhcpv6-slaac-problem-01.txt
>     >>
>     >> We did not think there had been enough discussion or interest 
> on
>     >> the w.g. list to guarantee a speaking slot.  We allocated short
>     >> slots at the end of the session if there is time before the
>     >> meeting ends.  If anyone (other than the authors) think one of
>     >> these should be given more time, please speak up.
> 
>     Karl> For what it's worth it seems to me that there is a gaping 
> hole
>     Karl> around securing ND. IPSec is obviously ridiculous, SEND is
>     Karl> only marginally less ridiculous. Maybe SSAS is a way forward? 
> 
> SEND looked at AH and realized that it couldn't be used, so IPsec is a 
> non-starter.  I'd like to know what you know about SEND that the SEND 
> WG didn't...
> 

I'm curious what the specific problem with SEND is. Is it the lack of
commonly available implementations, or the manual work to bootstrap it (IIRC
that is required), or both? The IETF obviously can't solve the former. If it
is the latter, I wonder if the "Better-Than-Nothing" model, used for IPsec
in RFC5386, could be applied to SEND? 

Regards,
Mark.

> SASS is similar, but uses a different algorithm, and you don't have to 
> recalculate each time you move.  For nodes that don't move, it seems 
> identical.
> 
> --
> Michael Richardson
> -on the road-
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------