Subject: [CGA-EXT] about draft-jiang-csi-dhcpv6-cga-ps-01.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 11 Mar 2009 10:44:51 +0100

Hi,

I have reviewed the document and i have some comments.  I think the 
document needs to be improved both editorially and in term of its contents.
In term of contents, i don't think there is anything wrong in the 
document, but i think some important parts of the analysis are missing. 
See review below.
In editorial terms, the writing needs to be improved a lot. In its 
current form, the document is hard to follow due to this. I have 
included some editorial comments, but overall the document needs to be 
rewritten to improve its readability.
Regards, marcelo

Regards, marcelo

Network Working Group                                     Sheng Jiang
Internet Draft                                              Sean Shen
Intended status: Standards Track          Huawei Technologies Co., Ltd
Expires: July 12, 2009                               January 8th, 2009

             DHCPv6 and CGA Interaction: Problem Statement
                                    
                  draft-jiang-csi-dhcpv6-cga-ps-01.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html

   This Internet-Draft will expire on July 12, 2009.

Abstract

   This document presents a problem statement for the possible
   interactions between DHCPv6 and CGA. Firstly, in order to support the
   co-existing scenarios of DHCPv6 and CGA, Some operations are
   clarified for the interaction of DHCPv6 servers and CGA-associated
   hosts. Then, some extended scenarios are also discussed in this
   document, including using CGAs in DHCPv6 operations to enhance the
   security features and using DHCPv6 to serve the CGA generation.

Table of Contents

   1. Introduction................................................2
   2. Terminology.................................................2
   3. Co-existing of DHCPv6 and CGA................................2
   4. What DHCPv6 can do for CGA...................................3

Jiang & Shen            Expires July 12, 2009                 [Page 1]

Internet-Draft  draft-jiang-csi-dhcpv6-cga-ps-01.txt      January 2009

   5. What CGA can do for DHCPv6...................................4
   6. Security Considerations......................................5
   7. IANA Considerations.........................................5
   8. Solution Requests...........................................5
   9. References..................................................5
      9.1. Normative References....................................5
      9.2. Informative References..................................6
   Author's Addresses.............................................7
   Copyright Notice...............................................8
    
1. Introduction

   Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] can
   assign addresses statefully. Although there are other ways to assign
   IPv6 address [RFC4862, RFC4339], DHCPv6 is still useful when
   administrator desire more control over addressing.

MB> s/desire/desires (but i would probably use a different wording in 
any case)

   Besides, DHCPv6
   also be used to distribute other information when dialog state is
   critical [RFC4242].  

MB> is also used or will also be used or can also be used, but be used

   Cryptographically Generated Addresses (CGA) [RFC3972] are IPv6
   addresses for which the interface identifiers are generated by
   computing a cryptographic one-way hash function from a public key and
   auxiliary parameters. By using the associate public & private keys as
   described in SEcure Neighbor Discovery (SEND) [RFC3971], CGA can
   protect Neighbor Discovery Protocol (NDP) [RFC4861], i.e. it provides
   address validation and integrity protection for NDP messages.

   This document presents a problem statement for the possible
   interactions between DHCPv6 and CGA. Firstly, in order to support the
   co-existing scenarios of DHCPv6 and CGA, Some operations are

MB>s/Some/some

   clarified for the interaction of DHCPv6 servers and CGA-associated
   hosts.

MB>rephrase

   Then, some extended scenarios are also discussed in this
   document, including using CGAs in DHCPv6 operations to enhance the
   security features and using DHCPv6 to serve the CGA generation.

MB> which security features?

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

MB>why you need this in a problem statement?

3. Co-existing of DHCPv6 and CGA

   As an important IPv6 technique, CGA is used efficiently on the
   stateless address configuration of IPv6 address [RFC4862].

MB>what do you mean is used efficiently?

   The public
   key system associated with CGA address provides message origin

Jiang & Shen            Expires July 12, 2009                 [Page 2]

Internet-Draft  draft-jiang-csi-dhcpv6-cga-ps-01.txt      January 2009

   validation and integrity protection without negotiation and
   transportation of key materials.

   The current CGA specifications does not mandate which device

MB>s/does/do

   generates a CGA address. In many cases, a CGA address is generated by
   the associated key pair owner, which normally is also the host that
   will use the CGA address.

   However, in a DHCPv6-managed network, hosts should obtain IPv6
   addresses only from a DHCPv6 server. This difference of roles needs
   to be carefully considered during the interaction of CGA and DHCPv6.

   Operations, as clarified in the next paragraph, support the co-
   existing of CGA's host self-generate address mechanism and DHCPv6
   managed address mechanism.

MB>rephrase

   This can be solved by validation procedure,

MB>what can be solved?

   which has been defined in
   the current DHCPv6. A node requests DHCPv6 server to grant a CGA
   generated by the node itself,

MB> it is not clear what this means

   listing the CGA addresses in IA options,
   which has been defined in [RFC3315]. According to whether the CGA
   matches the CGA-related configuration parameters of the network, the
   DHCPv6 server sends an acknowledgement to the node, grant the usage
   of the CGA or indicate the node that it must generate a new CGA with
   the CGA-related configuration parameters of the network. In the
   meantime, the DHCPv6 server has had the opportunity to log the
   address/host combination.

4. What DHCPv6 can do for CGA

   In the current CGA specifications, there is a lack of procedures to
   enable proper management of CGA generation.

MB> not sure what do you mena, but current CGA specs define perfectly 
well the CGA generation procedure

   Administrators should be
   able to configure parameters used to generate CGA.

MB> They are. Admin configure the SEc, the prefix and so on. I guess 
what you mean is that they should be able to centrally manage them or 
they need to automatically distribute the information

   For example,
   DHCPv6 server should be able to assign subnet prefix or certificates
   to CGA address owner. In some scenarios, the administrator may
   further want to enforce some parameters, particularly, the demanded
   security related parameters such as SEC value.

MB> right not only enforce, but also securely distribute. I mean, you 
are distributing
security sensitive information

   In the CGA generation procedure, the large computational consumption
   is needed to generate the Modifier field of a CGA address. This CPU
   intensive operation can represent time and/or battery consumption
   problems for end hosts (i.e. mobile devices) with limited computing
   ability and/or restricted battery power. In these cases, a mechanism
   to delegate the computation of the modifier should be provided. It is
   possible that the whole CGA generation procedure is delegated to the
   DHCPv6 server.

MB> this is especially true for large SEC values

 
Jiang & Shen            Expires July 12, 2009                 [Page 3]

Internet-Draft  draft-jiang-csi-dhcpv6-cga-ps-01.txt      January 2009

   Generating a key pair, which will be used to generate CGA, also
   requires large computation. Generation and distribution of a key pair
   can also be done by DHCPv6 server.

MB> you need to analyise much more the security implications of this

   DHCPv6 can help on these issues by providing more relevant functions.

MB> not obvious to me dhcpv6 fulfills with the security requirements 
needed for
some of the operations you describe above

   New DHCPv6 options may be defined to carry management parameters from
   DHCPv6 server to the client. A new DHCPv6 prefix assignment option
   may be define to propagate a subnet prefix. More DHCPv6 options may
   be defined to propagate more CGA-relevant configuration information,
   such as SEC value, certification information, SEND proxy information,
   etc.

   New interaction behavior between DHCPv6 server and client with a set
   of new DHCPv6 options may be defined to allow computation delegation.
   A node may initiate a DHCPv6 request to the DHCPv6 server for the
   computation of the Modifier or the CGA address.

MB>but in the case the client ask for a modifier, it needs to send 
information, i.e. the public key
I think more detailed analysis of how this could work and what are the 
implication is needed here

   The server either
   computes by itself, or redirects the computation require to another
   server.

MB>rephrase

   Once the server obtains the modifier or the CGA address, it

MB> obtains or generates?

   responds to the node with the modifier or the resulting address and
   the corresponding CGA Parameters Data Structure.

MB> it may be possible that the dhcp server is the one who knows the sec 
value. So the host asks for the generation of the modifier and the 
server delivers the modifier and the sec parameter. Then, you need to 
mention that the CGA generation procedure is affected by this. I think 
more thourough analysis is needed in this section

   New DHCPv6 options may be defined to support the interactions that a
   DHCPv6 server generates a key pair for hosts.

5. What CGA can do for DHCPv6

   DHCPv6 is vulnerable to various attacks particularly fake attack.

MB>what is a fake attack? an attack that is not real? :-)

   In
   the basic DHCPv6 specifications, regular IPv6 addresses are used. It
   is possible for a malicious attacker to use a fake address to spoof
   or launch an attack. A malicious fake DHCPv6 server can provide
   incorrect configuration to the client in order to divert the client
   to communicate with malicious services, like DNS or NTP. It may also
   mount a denial of service attack through mis-configuration of the
   client that causes all network communication from the client to fail.
   Fake DHCPv6 server may also collect some critical information from
   the client. Attackers may be able to gain unauthorized access to some
   resources, such as network access.

MB> isn't there a referecne to a dhcp threat analysis? there should be...

   The usage of CGA can efficiently improve the security of DHCPv6.

MB> i understnad that you mean that the dhcp server would has a CGA as 
its own address right? If this is the case, you need to mention it 
epxlicitly, cause, at this point i am not sure what you have in mind for 
this

 Thus
   the address of a DHCP message sender, which can be a DHCP server, a
   reply agent or a client, can be verified by a receiver.

MB> this is not obvious how to me. I mean, i think you need to identify 
the different threats for dhcp, (it would be better if such analysis 
already exsited) and then figure out what cha can do for each of the 
identified threats

   It improves
   communication security of DHCPv6 interaction. This mechanism is
   applicable in environments where physical security on the link is not
   assured (such as over wireless) or where available security
   mechanisms are not sufficient, and attacks on DHCPv6 are a concern.

MB> another issue that i think you need to analyze is how this fits with 
other dhcp security tools. I am not sure if there are any, but you need 
to understand if this solves an open problem or whether there are 
already solutions. If there are alternative security solutions, you need 
to understnad why this one is better or what are the benefits.

 
Jiang & Shen            Expires July 12, 2009                 [Page 4]

Internet-Draft  draft-jiang-csi-dhcpv6-cga-ps-01.txt      January 2009

   Of course, as an assumption, the advantage of CGA can be taken only
   when CGA addresses are used in DHCPv6 communications.

6. Security Considerations

   As Section 5 of this document has discussed, CGA can provide
   additional security features for DHCPv6. When one defines solution
   using the DHCPv6 to configure CGA, which has been mentioned in
   Section 4 of this document, more consideration should be taken to
   evaluate whether the new mechanism bring in security vulnerabilities.  

7. IANA Considerations

   There are no IANA considerations in this document.

8. Solution Requests

   As we discussed through this document, CGA and DHCPv6 can provide
   additional service or security features for each other. Solutions
   that define the details of abovementioned interactions are worthy
   exploring.

9. References

9.1. Normative References

   [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for
             IPv6", RFC3315, July 2003.

   [RFC3971] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor
             Discovery (SEND) ", RFC 3971, March 2005.

   [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972,
             March 2005.

   [RFC4242] S. Venaas, T. Chown, B. Volz, "Information Refresh Time
             Option for Dynamic Host Configuration Protocol for IPv6
             (DHCPv6)", RFC4242, November 2005.

   [RFC4861] T. Narten, E. Nordmark, W. Simpson, H. Soliman, "Neighbor
             Discovery for IP version 6 (IPv6)", RFC4861, September 2007.

   [RFC4862] S. Thomson, T. Narten, "IPv6 Stateless Address
             Autoconfiguration", RFC4862, September 2007.

 
Jiang & Shen            Expires July 12, 2009                 [Page 5]

Internet-Draft  draft-jiang-csi-dhcpv6-cga-ps-01.txt      January 2009

9.2. Informative References

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels", RFC2119, March 1997.

   [RFC4339] J. Jeong, Ed., "IPv6 Host Configuration of DNS Server
             Information Approaches", RFC4339, February 2006.

 
Jiang & Shen            Expires July 12, 2009                 [Page 6]

Internet-Draft  draft-jiang-csi-dhcpv6-cga-ps-01.txt      January 2009

Author's Addresses

   Sheng Jiang
   Huawei Technologies Co., Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Phone: 86-10-82836774
   Email: [email-masked]
    
   Sean Shen
   Huawei Technologies Co., Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Phone: 86-10-82836072
   Email: [email-masked]

 
Jiang & Shen            Expires July 12, 2009                 [Page 7]

Internet-Draft  draft-jiang-csi-dhcpv6-cga-ps-01.txt      January 2009

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

 
Jiang & Shen            Expires July 12, 2009                 [Page 8]

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 13 Mar 2009 08:56:59 +0800

Hi, Marcelo,

Thanks so much for your reply and comments. They are really helpful. We are
appreciate your help. I will integrate your comments into our next version with
these further analysis your suggested. We will also work on the editorial as well.
Hopefully, next version would meet the standard.

Best regards,

Sheng

>-----Original Message-----
>From: marcelo bagnulo braun [mailto:[email-masked]] 
>Sent: Wednesday, March 11, 2009 5:45 PM
>To: [email-masked]; JiangSheng 66104; Sean Shuo Shen; 
>gabriel montenegro
>Subject: about draft-jiang-csi-dhcpv6-cga-ps-01.txt
>
>Hi,
>
>I have reviewed the document and i have some comments.  I 
>think the document needs to be improved both editorially and 
>in term of its contents.
>In term of contents, i don't think there is anything wrong in 
>the document, but i think some important parts of the analysis 
>are missing. 
>See review below.
>In editorial terms, the writing needs to be improved a lot. In 
>its current form, the document is hard to follow due to this. 
>I have included some editorial comments, but overall the 
>document needs to be rewritten to improve its readability.
>Regards, marcelo
>
>
>Regards, marcelo
>
>
>
>>
>>
>>
>>
>>
>>
>>