Subject: [CGA-EXT] (no subject)

From: Julien Laganier <[email-masked]>
Date: Fri, 6 Jun 2008 17:44:11 +0200

Folks, 

Sorry for the noise, but another update of the Secure Proxy ND Support 
for SEND has been posted. It fixes some misreferences and has a 
filename matching the WG name, thus it should appear in the 
tools.ietf.org page.

The new draft has support for ND proxy as per:
- ND proxies [RFC4389]
- MIPv6 Home Agent [RFC3775]
- PMIPv6 Mobility Access Gateway [I-D.ietf-netlmm-proxymip6]

You can find it there:

<http://www.ietf.org/internet-drafts/draft-krishnan-csi-proxy-send-00.txt>

Comments are still welcome!

--julien

Subject: New Version Notification for draft-krishnan-csi-proxy-send-00
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 6 Jun 2008 08:24:12 -0700 (PDT)

A new version of I-D, draft-krishnan-csi-proxy-send-00.txt has been successfuly submitted by Julien Laganier and posted to the IETF repository.

Filename:	 draft-krishnan-csi-proxy-send
Revision:	 00
Title:		 Secure Proxy ND Support for SEND
Creation_date:	 2008-06-06
WG ID:		 Independent Submission
Number_of_pages: 22

Abstract:
Secure Neighbor Discovery (SEND) specifies a method for securing
Neighbor Discovery (ND) signaling against specific threats.  As
specified today, SEND assumes that the node advertising an address is
the owner of the address and is in possession of the private key used
to generate the digital signature on the message.  This means that
the Proxy ND signaling initiated by nodes that do not possess
knowledge of the address owner's private key cannot be secured using
SEND.  This document extends the current SEND specification with
support for Proxy ND, the Secure Proxy ND Support for SEND.

The IETF Secretariat.

_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Tony Cheneau <[email-masked]>
Date: Thu, 12 Jun 2008 17:10:41 +0200

Hello,

PSO is defined (at least in the format) in the same way as SEND's
RSA Signature Option. This involves that you have again to deduce the
size of the Digital Signature (as stated by a previous mail in this ML)
which isn't that great.
In my opinion, it should be possible to add a "padding lenght field" or
something to specify the size of the Digital Signature in the 16 bits
"reserved field". Am I missing a point here ?

In figure 1, the last message between the ND proxy and Host A indicates
B link-layer (B_LL) in the TLLAO. Shouldn't it be P_LL (the address of
the outgoing interface) instead ?

Thanks in advance and don't hesitate to correct me if I'm wrong.

Best regards,
	Tony Cheneau

Le Fri, 6 Jun 2008 17:44:11 +0200,
Julien Laganier <[email-masked]> a écrit :

> Folks, 
> 
> Sorry for the noise, but another update of the Secure Proxy ND
> Support for SEND has been posted. It fixes some misreferences and has
> a filename matching the WG name, thus it should appear in the 
> tools.ietf.org page.
>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 12 Jun 2008 18:09:45 +0200

Hello,

> size of the Digital Signature (as stated by a previous mail in this
> ML) which isn't that great.
> In my opinion, it should be possible to add a "padding lenght field"
> or something to specify the size of the Digital Signature in the 16
> bits "reserved field". Am I missing a point here ?

Right, this is the same format. I think there's value in using the same 
format for options with similar content -- regularity is hardly bad 
when it comes to coding.

I'd be fine to change that format if we change the SEND Signature 
format. However that would have some drawbacks w.r.t. backward 
compatibility.

> In figure 1, the last message between the ND proxy and Host A
> indicates B link-layer (B_LL) in the TLLAO. Shouldn't it be P_LL (the
> address of the outgoing interface) instead ?

You're right. That's another typo. Thanks.

--julien

> > Support for SEND has been posted. It fixes some misreferences and
> > has a filename matching the WG name, thus it should appear in the
> > tools.ietf.org page.
> >