Re: [CGA-EXT] WGLC for draft-ietf-csi-dhcpv6-cga-ps-01.txt

In order to expedite the work on this draft and since the comments 
received seem to be more than editorial, i would suggest that the 
authors do send a proposed text to the mailing list for discussion as 
soon as possible (rather than waiting for the WGLC to end and submit a 
new version of the draft)

Regards, marcelo


El 21/04/10 4:52, Sheng Jiang escribió:
> Dear Alberto,
>
> Thanks for your comments. Most of them will be addressed in an update
> version after WGLC among with other comments we may received. Detailed
> replies in lines.
>
> Best regards,
>
> Sheng
>
>    
>> -----Original Message-----
>> From: Alberto García [mailto:alberto@it.uc3m.es]
>> Sent: Tuesday, April 20, 2010 6:25 PM
>> To: 'marcelo bagnulo braun'; cga-ext@ietf.org
>> Cc: draft-ietf-csi-dhcpv6-cga-ps@tools.ietf.org
>> Subject: RE: [CGA-EXT] WGLC for draft-ietf-csi-dhcpv6-cga-ps-01.txt
>>
>> Hi,
>> Some comments:
>>
>> In section 4 (What CGA can do for DHCPv6), it would help to
>> describe the scenario in which CGAs can be used, i.e.
>> indicating which of the elements use CGA, and in which part
>> of the DHCP configuration process can be beneficial the use
>> of CGA. Even though the draft is not devoted to solutions, at
>> least it should be shown a scenario in which a possible
>> solution could be developed.
>>      
> CGA can be used for all DHCP messages/processes as long as CGA is available.
> We will make it clearer in the update version.
>
>    
>> In fact, I do not clearly see why using CGA is an advantage in this
>> scenario: CGA are good to state that a node has the
>> authorization to use a given address, but it is not clear to
>> me that it is to say that a node has the authorization to act
>> as something (a DHCP server, a relay). For this, some
>> configuration is required to bind the 'authorization' to the
>> CGA address. How is this done?
>> You then say a possible way of achieving this
>>      
> This kind of authorization is based on pre-configuration conditions. For
> example, a node has been pre-configured a public key of a certain DHCP
> server (or a trust anchor). We will make it clearer in the update version.
>
>    
>> "The minimum level of pre-configuration is to
>>     configure public keys on both parties of communication or have a
>>     third party authority available for users to retrieve public keys."
>>
>> Well, the nice thing of CGA is that you don't need to know in
>> advance keys, but addresses (and the addresses can be
>> securely bound to keys dynamically, by means of conveying the
>> CGA parameter data structure, which is verified to see that
>> the binding is correct).
>>      
> Agree. However, there is no any restriction that CGA can be used with
> authority information together. This draft does not propose any concrete
> solution, but list the possibilities. Of course, we should explain clearly
> the scenario without any pre-configuration. It will be in the update
> version.
>
>    
>> I think the configuration should be just the CGA address. But
>> then, if you need configuration, which is the benefit over IPsec?
>> AFAIU IPsec has a number of benefits on its own: it is the
>> current standard for use in DCHP exchange, it allows
>> negotiation of security parameters so it is more secure than
>> CGAs... The nice thing of CGAs is that in general you use
>> them without configuring anything or just by using them as
>> addresses (you just configure the DNS, and that's all).
>>      
> The same with above.
>
>    
>> May be I'm not understanding properly this part. Can you be
>> more specific?
>> In addition, as a problem statement document, it should be
>> more exhaustive in detailing all the problems which can be
>> addressed by CGAs (even though there is no detail on the solution).
>>      
> If you meant the scenario without any pre-configuration, it will be included
> in the update version. If you think there are other missing, please point
> out. We are glad to include.
>
>    
>> ---
>> In the second paragraph of the introduction you say:
>>
>> "By using the associated public&  private keys
>>     as described by SEcure Neighbor Discovery (SEND)
>> [RFC3971], CGAs can
>>     protect the Neighbor Discovery Protocol (NDP) [RFC4861], i.e. they
>>     can provide address validation and integrity protection for NDP
>>     messages."
>>
>> Although this is true, of course, I don't see the point in
>> just considering here0020one protocol which use CGAs. The
>> draft is about configuring CGAs, and this CGAs can be used
>> for any purpose (SEND, SHIM6, any other). Here it seems there
>> is a specific dependency on SEND, which I think is not the case.
>> I would replace with:
>> "CGAs are used in protocols such as SEND [RFC3971] or SHIM6
>> [RFC5533]."  or something similar.
>>      
> It will be addressed in the update version. Many thanks for your valuable
> comments.
>
> Best regards,
>
> Sheng
>
>    
>> ----
>>
>> Regards,
>> Alberto
>>
>> |  -----Mensaje original-----
>> |  De: cga-ext-bounces@ietf.org [mailto:cga-ext-bounces@ietf.org] En
>> | nombre
>> de
>> |  marcelo bagnulo braun
>> |  Enviado el: martes, 20 de abril de 2010 10:23
>> |  Para: cga-ext@ietf.org
>> |  CC: draft-ietf-csi-dhcpv6-cga-ps@tools.ietf.org
>> |  Asunto: [CGA-EXT] WGLC for draft-ietf-csi-dhcpv6-cga-ps-01.txt
>> |
>> |  Hi,
>> |
>> |  This note issues the WGLC for draft-ietf-csi-dhcpv6-cga-ps-01.txt
>> |  Please, review the document and send your comments before
>> april the 10th.
>> |
>> |  For your convenience, you can find the document at
>> | http://datatracker.ietf.org/doc/draft-ietf-csi-dhcpv6-cga-ps/
>> |
>> |  Regards, marcelo
>> |
>> |  _______________________________________________
>> |  CGA-EXT mailing list
>> |  CGA-EXT@ietf.org
>> |  https://www.ietf.org/mailman/listinfo/cga-ext
>>
>>      
>
>