gmane.ietf.csi

Call for comments on draft-rafiee-6man-ssas-01.txt

Hosnieh Rafiee — 2013-01-21T23:56:20

Dear all,

I have considered your comments and updated our draft rfc accordingly. Feel free to add further comments.

Thank you,
Hosnieh



Filename: draft-rafiee-6man-ssas
Revision: 01
Title: A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration (SSAS)
Creation date: 2013-01-21
WG ID: Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-01.txt
Status:          http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas
Htmlized:        http://tools.ietf.org/html/draft-rafiee-6man-ssas-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-rafiee-6man-ssas-01

Abstract:
   The default method for IPv6 address generation uses a organitionally
   unique identifier assigned by the IEEE Standards Association and the
   extension identifier by the hardware manufacturer [1] (section 2.5.1
   RFC-4291) [RFC4291]. This means that a node will always have the same
   Interface ID (IID) whenever it connects to a new network. Because

Re: CGA-EXT Digest, Vol 47, Issue 2

Hosnieh Rafiee — 2013-01-14T00:37:15

Dear Roque,

 

between your proposal and changing a CGA by using a different modifier from
time to time? In >your case you have a timestamp but the modifier can be
arbitrary.

 

I also use a modifier. The difference between SSAS and CGA is the direct
usage of a public key as a part of the IP address. So, SSAS also generates a
random address and the chances of address collision is also minimized
because SSAS uses SHA2. If we want to use SHA2 for CGA, we would need to
forget about a sec value  higher than 0 because of the generation time is
dependent on the condition of 16 by sec value that must be equal to zero.

For the generation of CGA, the subnet prefix is required. This generation
must be in real time and cannot be in offline. For privacy, you usually need
to change your IP address regularly. Unfortunately, to generate a CGA, it
takes all the CPU power to accomplish this generation. This might have an
adverse effect on the other services trying to use that CPU. This is why an
algorithm needing less com

Re: CGA-EXT Digest, Vol 47, Issue 2

Roque Gagliano (rogaglia — 2013-01-07T17:00:31

Hosnieh,

On Jan 7, 2013, at 5:05 PM, Hosnieh <ietf-Tj2eAaDKJQZBDgjK7y7TUQ< at >public.gmane.org<mailto:ietf< at >rozanak.com>> wrote:



Dear Rogue,

Thank you for your comments and questions.






The problem is one of privacy. Addresses need to change in order to protect privacy. In this vain it then becomes beneficial and important to be able to generate the IID more quickly. For nodes in the network it is enough to use SSAS without thinking about the use of certificates because that is all that is needed to prove address ownership. At the same time, it is recommended to use vehicles outlined in other RFCs to prevent all nodes from claiming to be a router.

So if the problem you want to solve is privacy, what is the big difference between your proposal and changing a CGA by using a different modifier from time to time? In your case you have a timestamp but the modifier can be arbitrary.


So being able to generate the address faster along with reducing the verification time does not convince you? It is already a

Re: CGA-EXT Digest, Vol 47, Issue 2

Hosnieh — 2013-01-07T16:05:30


Dear Rogue,

Thank you for your comments and questions.






The problem is one of privacy. Addresses need to change in order to protect
privacy. In this vain it then becomes beneficial and important to be able to
generate the IID more quickly. For nodes in the network it is enough to use SSAS
without thinking about the use of certificates because that is all that is
needed to prove address ownership. At the same time, it is recommended to use
vehicles outlined in other RFCs to prevent all nodes from claiming to be a
router.






So being able to generate the address faster along with reducing the
verification time does not convince you? It is already a given that the use of
CGA for a sec value over 1 is not feasible. Even when using a sec value of 0 the
verification time using CGA is much higher than that for SSAS. The conclusion
drawn from this is that, in the event of DoS attacks, SSAS enable nodes have the
ability to process more packets per minute than do those using CGA.






As I explained in my

Re: CGA-EXT Digest, Vol 47, Issue 2

Roque Gagliano (rogaglia — 2013-01-07T09:40:53

Hosnieh,

I have some comments:
- Why this is an important problem to be addressed is not clear in the text other than saying "CGA are computing intensive", which is arguable depending on network sizes and equipment 
- You need to add text to the document on where the improvement resides. You mentioned something on the answer to Ahmad but that is still not convincing.
- You mention that the strength of your algorithm requires that the key pair needs to be changed every 2 days. In the case you are using SEND, this means generating new certificates for every node every 2 days. This seams like a non-starter IMHO.
- Please include the reference to your studies instead of saying "Our experimental results show a definite improvement ".

BTW, there other proposals for privacy extensions today that you should mention: https://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02

Roque.

On Jan 6, 2013, at 9:40 PM, Hosnieh Rafiee <ietf-Tj2eAaDKJQZBDgjK7y7TUQ< at >public.gmane.org> wrote:

Re: CGA-EXT Digest, Vol 47, Issue 2

Hosnieh Rafiee — 2013-01-06T20:40:12

Dear Ahmad,

Thank you so much for your comments. 

Signature options which are attached to the DNP messages.

As I explained in my last email to Jeremy, It just updates SEND and does not
replace it. It updates SEND because of the signature contents. I also
explained in the draft that we used the same timestamp as is used in SEND.

or 1. In this case the computation of the CGA (SEND) would be equivalent to
the complexity of your approach.  
I compared it with both sec value 0 and sec value 1. I did not consider sec
value higher because it is not really feasible in practice that someone wait
for 2 or 3 hours to days to generate an address. CGA for 1 it is 600 times
more. For zero it is about 10 to 20 times more. 

The computation of this algorithm is faster than that for CGA and also the
verification process is much faster. In the verification process you do not
need to do all the CGA generation processing in reverse in order to verify
it. With CGA you also have to include the verification time for the
signat

Re: Call for comments on draft-rafiee-6man-ssas-00.txt

Al-Sadeh, Ahmad — 2013-01-06T20:09:53

Hosnieh,
I have read your draft. And I have the following comments.
SEND already offers what you are looking for. It has the Timestamp and the Signature options which are attached to the DNP messages. So, the new benefits of your approach are not clear to me.
I agree with the claim that CGA is compute intensive, but one can use Sec=0 or 1. In this case the computation of the CGA (SEND) would be equivalent to the complexity of your approach.  Therefore the enhancements that are proposed to protect the user privacy by setting a lifetime for the generated address (e.g. 2 days) or generating the key pairs by CGA code can be directly applied to the CGA and SEND implementation without significant change to proposed standard.
In Section 5, “… it provides proof of address ownership at a speed that is about 600 times faster than that of the CGA algorithm.”
For which Sec value this comparison was done?
Regards,
Ahmad AlSadeh

________________________________
From: cga-ext-bounces-EgrivxUAwEY< at >public.gmane.org [cg

Call for comments on draft-rafiee-6man-ssas-00.txt

Hosnieh Rafiee — 2013-01-04T20:13:25

Dear All,

This draft addresses the following problem:
Unfortunately the existing drafts do not consider the integration of
security and privacy  for the generation of the Interface ID (IID). This
draft tries to offer a solution to this problem while at the same time
considering the generation and verification times and complexity of the
existing algorithms. Please take a look. Comments are greatly appreciated.
Thank you,
Hosnieh



Filename: draft-rafiee-6man-ssas
Revision: 00
Title: A Simple Secure Addressing Generation Scheme for IPv6
AutoConfiguration (SSAS)
Creation date: 2013-01-02
WG ID: Individual Submission
Number of pages: 13
URL:
http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-00.txt
Status:          http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas
Htmlized:        http://tools.ietf.org/html/draft-rafiee-6man-ssas-00


Abstract:
   The default method for IPv6 address generation uses two unique
   manufacturer IDs that are assigned by the IEEE Standards Association
   [1] (

abandonning draft-ietf-csi-dhcpv6-cga-ps

marcelo bagnulo braun — 2012-12-08T08:36:41

Hi,

After several iterations with the IESG, we believe that we should 
abandon draft-ietf-csi-dhcpv6-cga-ps. The reasons include among others 
that some of the reccomendations of the document are already being 
discussed in dhc, so the document has served its purpose already.

If you have comments, they are welcome.

Regards, marcelo

Second WGLC for draft-ietf-csi-dhcpv6-cga-ps

marcelo bagnulo braun — 2011-07-13T07:39:12

A new version of the draft has been posted addressing the issues raised 
during IESG review.
since the draft had major changes, we are issuing a second WGLC.
Please review and comment before the 1st of august.

The draft is at http://tools.ietf.org/html/draft-ietf-csi-dhcpv6-cga-ps-07

Regards, marcelo

RFC3971: clarification about destination address for CPSmessages

Jean-Michel Combes — 2010-12-09T16:17:44

Hi,

I have an issue with text in RFC3971 regarding the ADD process and
especially the destination address for CPS messages sent by a host.

Section 6.4.6 mentions:
"When soliciting certificates for a router, a host MUST send
Certification Path Solicitations either to the All-Routers multicast
address, if it has not selected a default router yet, or to the
default router's IP address, if a default router has already been
selected."

Section 6.4.1 confirms that destination address is either All-Routers
multicast address or the default router's IP address:
"Destination Address
         Typically the All-Routers multicast address, the
Solicited-Node multicast address, or the address of the host's default
router."

I don't understand why the CPS message is not sent directly (i.e.
unicast address) to the router advertising the RA message (which
triggers the sending of the CPS message) received by the host.

Thanks in advance for any clarification!

Best regards.

JMC.

Fwd: New Version Notification fordraft-ietf-csi-send-cert-08

Roque Gagliano — 2010-10-07T10:55:23

RV: New Version Notification fordraft-ietf-csi-proxy-send-05

Alberto García — 2010-09-28T15:07:53

Hi,
I have posted a new version of draft-ietf-csi-proxy-send, version -05 which
addresses some comments made by the IESG (including the 2 KeyPurposeId's
introduced in draft-ietf-csi-send-cert-07)

Regards,
Alberto

-----Mensaje original-----
De: IETF I-D Submission Tool [mailto:idsubmission-EgrivxUAwEY< at >public.gmane.org] 
Enviado el: martes, 28 de septiembre de 2010 17:00
Para: alberto-lKqjX1hQmNLe5aOfsHch1g< at >public.gmane.org
CC: suresh.krishnan-IzeFyvvaP7pWk0Htik3J/w< at >public.gmane.org; julienl-zC7DfRvBq/JWk0Htik3J/w< at >public.gmane.org;
marco.bonola-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org
Asunto: New Version Notification for draft-ietf-csi-proxy-send-05 


A new version of I-D, draft-ietf-csi-proxy-send-05.txt has been successfully
submitted by Alberto Garcia-Martinez and posted to the IETF repository.

Filename: draft-ietf-csi-proxy-send
Revision: 05
Title: Secure Proxy ND Support for SEND
Creation_date: 2010-09-28
WG ID: csi
Number_of_pages: 29

Abstract:
Secure Neighbor Discovery (SEND) specifies a meth

Fwd: New Version Notification fordraft-ietf-csi-send-cert-07

Roque Gagliano — 2010-09-24T10:57:15

Re: Key Purpose Id specification anddraft-ietf-csi-proxy-send

Alberto García — 2010-09-24T09:30:03

Re: Key Purpose Id specification anddraft-ietf-csi-proxy-send

Roque Gagliano — 2010-09-23T15:53:12

Re: Key Purpose Id specification anddraft-ietf-csi-proxy-send

Alberto García — 2010-09-17T12:56:05

Hi Roque,

|  -----Mensaje original-----
|  De: Roque Gagliano [mailto:rogaglia-FYB4Gu1CFyUAvxtiuMwx3w< at >public.gmane.org]
|  Enviado el: jueves, 16 de septiembre de 2010 11:16
|  Para: Alberto García
|  CC: cga-ext-EgrivxUAwEY< at >public.gmane.org
|  Asunto: Re: [CGA-EXT] Key Purpose Id specification and
draft-ietf-csi-proxy-send
|

[...]

|  > c) could be to have 2 Key Purpose Ids for proxy operation instead of
one
|  (therefore replacing id-kp-sendProxy), in which case the following text
could be
|  included in draft-ietf-csi-send-cert, section 7:
|  
|  I take option c).
|  
|  When I first thought about this, I remembered the old times of modem
access
|  and Proxy-ARP in routers. I see now a use-case for
"id-kp-sendProxiedOwner"
|  even without considering MIP6.
|  
|  I agree that we should go this path, it will make a better set of
documents.
|  However, I believe that if we go this path, we need also to make sure
that there
|  is a synchronization between this document and the proxy document to
reflect
|

Re: Key Purpose Id specification anddraft-ietf-csi-proxy-send

Roque Gagliano — 2010-09-16T09:15:50

Re: [dhcwg] Follow up request for reviewofdraft-ietf-csi-dhcpv6-cga-ps

Ted Lemon — 2010-09-15T23:39:54

This does help, thanks.   I continue to think that the DHCP server is not a good place to offload the work, but I see the logic in wanting to do it, anyway, so I withdraw my objection.

Re: [dhcwg] Follow up request for reviewofdraft-ietf-csi-dhcpv6-cga-ps

Laganier, Julien — 2010-09-15T15:56:01

Ted,

Some clarifications:

Ted Lemon wrote:

If you have a look at the CGA generation algorithm described in RFC 3972 you will see that there are potentially two distinct computationally intensive tasks:

1. generation of public-private (RSA) key pair
2. generation of a CGA modifier value for a given Security Parameter (Sec) as per RFC 3972. (The Sec is used to harden the resistance of brute force attacks on the 64-bits IIDs of CGAs.)

#2 above might become computationally intensive for values of the Sec higher than zero (if it's zero any Modifier satisfies 3972). Back in 2002 I remember running the algorithm on then standard personal computers (e.g., x86 / ~1GhZ) and it would took ~20 seconds for Sec = 1 and a couple of minutes for Sec = 2. I do not remember going higher...

I understand the proposal is to offload #2 to the server while #1 would not be. 

IMHO it does not any make sense to offload when Sec is set to 0 because the computational load is nil. 

When Sec is set to 1 the computational load of #

Re: [dhcwg] Follow up request for review ofdraft-ietf-csi-dhcpv6-cga-ps

Sheng Jiang — 2010-09-15T01:47:13

Hi, Ted,

There are actually two very different concerns you have. I reply below. 

Before that, I would like to state: as an informational document, draft-ietf-csi-dhcpv6-cga-ps aims
to analyze the all possible interactions between cga and dhcpv6. Whether these possibilities are
going to be defined as actual solutions in the future, it is another matter. In this draft, all we
say is there are such possibilities, their benefits and issues  (if you want, we can put more
analysis regarding to potential issues of this possibility). You may notice in this 04 version, we
have removed "Solution Requests" charpter, which was in previous version. We are not defining
solutions, even not requesting to define such solutions.

Your first concern is the security of this delegation operation. In all cases, the private key is
not transported through the network. The private key is only kept and used by its owner. This does
not say the delegation operation is security. Actually, other parameters and cga generation result
al