Dave, 1) Having the DHCP server do dynamic update is not necessarily just for addresses allocated by DHCP. See http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is a DHC WG draft. Thanks a lot for your answer. Please check the consideration section of the draft you referred to. The stated approach is prone to attacks as it is solely about an extra management efforts and not security approaches. To prevent the attacks it also stated using SEND. Now the question is, when you want to use SEND to secure your local network, my approach is also applicable and better fits than TSIG itself as you do not need to generate public private keys, CGA and you use the same value available there. DHCPv6 is only useful when you would like to have more management and administration control on your network. But, if you only want to know who used which address, you do not need to go to extra configuration , you need just a passive monitoring system in the network to sniff all ICMPv6 unsolicited Neighbor advertisement packets and delete them from the monitoring database if receive no more NA messages from that node. (frequently nodes update their cache and send NA) 2- Is not true. DNS information is not the only information obtained through DHCP, it's a general purpose mechanism through which many things are, and can be, obtained. It is a bad idea to try to pollute RAs with such information (for one, you're limited to the MTU in RAs). See RFC 5505 section 2.3 for some more discussion. DNS information is just an information missing in NDP. For addressing not more option is required for a node. I am not quite understand and convinced that why every time you change the talk to DHCPv6. I am talking about the networks where SEND is used and not DHCPv6. I do not have any discussion about whether or not the DNS options in RAs is the best.
3- RFC 6434 section 6 even states "Hosts will need to decide which mechanism (or whether both) should be implemented." The fact that we actually have two mechanisms is a bad thing. This is why based on the network requirements, administrator can choose which one to use. 3) The main feedback some of us provided is that the proposal would be far more widely applicable and useful if it just passed a public key and used the leap of faith model like SSH, rather than narrowing the use case significantly and depending on implementation of CGA, which isn't really implemented/deployed in practice today. It is not true. Please check this website http://en.wikipedia.org/wiki/Secure_Neighbor_Discovery_Protocol . And about using SSH, It might be a good solution to this problem (but so general) that if you like we can work on that on a separate draft together. The CGA-TSIG focused on a solution to this problem in IPv6 network when using SEND in local security. I am not agree with you in this sentence " it is far applicable ", because when for the local security you use SEND you can easily use this approach without any configuration for your clients side. Thank you, Hosnieh P.S. I also included DANE WG. From: Dave Thaler [mailto:[email protected]] Sent: Wednesday, November 07, 2012 8:40 PM To: Rafiee, Hosnieh; Suresh Krishnan ([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: (CGA-TSIG) answers to some of the comments Quick response... 1) Having the DHCP server do dynamic update is not necessarily just for addresses allocated by DHCP. See http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is a DHC WG draft. 2) "RFC 6106, the router advertisement contains the DNS information also so there is no need for DHCP server configuration" Is not true. DNS information is not the only information obtained through DHCP, it's a general purpose mechanism through which many things are, and can be, obtained. It is a bad idea to try to pollute RAs with such information (for one, you're limited to the MTU in RAs). See RFC 5505 section 2.3 for some more discussion. RFC 6434 section 6 even states "Hosts will need to decide which mechanism (or whether both) should be implemented." The fact that we actually have two mechanisms is a bad thing. 3) The main feedback some of us provided is that the proposal would be far more widely applicable and useful if it just passed a public key and used the leap of faith model like SSH, rather than narrowing the use case significantly and depending on implementation of CGA, which isn't really implemented/deployed in practice today. -Dave From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Rafiee, Hosnieh Sent: Wednesday, November 7, 2012 10:28 AM To: Suresh Krishnan ([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [Int-area] (CGA-TSIG) answers to some of the comments Thanks to Julian, Suresh and others for all their comments on my presentation. Following are the answers to the questions raised and, hopefully, this will clarify the main purpose of this draft: - A comment was made that DHCP can update the clients' DNS records on behalf of the clients so they see any no reason for this draft as DHCPv6 can update the DNS records for the clients on behalf of them. Here we are talking about another IPv6 addressing mechanism, i.e., Neighbor Discovery Protocol (RFC 4861) and not DHCPv6. NDP is a new addressing mechanism included in the IPv6 suite that functions like ARP, discovering other neighbor nodes, ICMP, and address configuration automatically. By default, all operating systems support this functionality and, for windows, it is the default method of addressing. - Why do some administrators prefer to use NDP instead of DHCPv6? With NDP no DHCP server configuration is required. - Usage of NDP protocol All kinds of networks like campus, companies whether they are public and private - How can a client or a server in IPv6 networks set its IP address using NDP When you connect your computer to an IPv6 network, your computer generates its IP address automatically and then processes duplicate address detection by using 5 types of ICMPv6 messages. Your computer also sets its global address by using the router advertisement. The administrator just needs to enable NDP on his router and configure it to advertise his available prefixes. It is a great way to manage the network. - The problem with NDP WAS (solved now) Before, it did not support the DNS option and it took the DNS information from the DHCP server, BUT NOW, according to a new extension to NDP, in RFC 6106, the router advertisement contains the DNS information also so there is no need for DHCP server configuration. What is the problem now in this local network - what gap CGA-TSIG fills Briefly: It provides local security in IPv6 networks without the need for extra configuration as it uses the current security parameters and mechanism available on this network, i.e., SEND. When node addresses change over time in IPv6 networks for privacy reasons, CGA-TSIG provides the necessary security in IPv6 networks for the DNS authentication process. This solution works very well in local networks, but also is applicable in global networks. - Local security is an important issue: In IPv6 networks that use NDP, there is no central server available to perform the updates to DNS records on behalf of the client. As local security is important, as well as global security, CGA-TSIG provides a solution for the automation of this process and allows for client authentication with DNS servers as well as the ability to update their own records. The question that might arise here is, why local security is important?: The answer here is the same as that provided for the use of SEcure Neighbor Discovery in IPv6 networks. Many attacks are internal and not via the Internet. When, because of flaws or viruses or..., a host in a network is infected that gives the attacker control of that host the role of local security is highlighted. In this case the attacker is inside your network and using the legitimate nodes inside your network for their malicious purposes. Therefore, if you just think about global security, you have just partly secured your network! If we also consider the case where the host's generates their IP address and keep it as long as it is connected to the same network. When this legitimate node, for the first time, join to a network, if TSIG or other security mechanisms are used, the administrator needs to generate this shared secret so that it is only shared between this host and the DNS server. Thus CGA-TSIG reduces this task, while at the same time, provides the security necessary for DNS servers and clients. - Privacy is the second or another important issue: In Europe, privacy is a very important issue. An example of that is in Germany that the ISPs are forced to change their range of IP addresses frequently. In this case, for every change, the administrators of the sub-networks, using these ISPs, need to reconfigure their clients and servers to again use the security mechanism for authentication purposes. CGA-TSIG is the solution. It can provide this authentication without the need for more configuration - Global security: the same approach is applicable for authentication purposes among the DNS servers on the Internet if they are under the privacy rules that force them to change their ISP's prefix, as was explained in my first point Finally : DNS serves or clients only need use the cached CGA data and do not need to regenerate CGA! This is an important point because only a few changes need be made to the current implementation of DNS server. I will provide you with the list of more attacks later. Some of the attacks that CGA-TSIG can prevent are found in Security consideration section at the following link: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-00#section-4 I welcome all questions and comments that can help to clear up the purpose of this draft. Thank you all for your help. It is greatly appreciated. Thank you again, Hosnieh
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
