draft-ietf-6man-dns-options-bis-06.txt   draft-ietf-6man-dns-options-bis-07.txt 
Network Working Group J. Jeong Network Working Group J. Jeong
Internet-Draft Brocade/ETRI Internet-Draft Brocade/ETRI
Obsoletes: 5006 (if approved) S. Park Obsoletes: 5006 (if approved) S. Park
Intended status: Standards Track SAMSUNG Electronics Intended status: Standards Track SAMSUNG Electronics
Expires: January 8, 2011 L. Beloeil Expires: January 27, 2011 L. Beloeil
France Telecom R&D France Telecom R&D
S. Madanapalli S. Madanapalli
Ordyn Technologies Ordyn Technologies
July 7, 2010 July 26, 2010
IPv6 Router Advertisement Options for DNS Configuration IPv6 Router Advertisement Options for DNS Configuration
draft-ietf-6man-dns-options-bis-06 draft-ietf-6man-dns-options-bis-07
Abstract Abstract
This document specifies IPv6 Router Advertisement options to allow This document specifies IPv6 Router Advertisement options to allow
IPv6 routers to advertise a list of DNS recursive server addresses IPv6 routers to advertise a list of DNS recursive server addresses
and a DNS search list to IPv6 hosts. and a DNS search list to IPv6 hosts.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 1, line 43 skipping to change at page 1, line 43
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2011. This Internet-Draft will expire on January 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
5.3. Procedure of DNS Configuration . . . . . . . . . . . . . . 8 5.3. Procedure of DNS Configuration . . . . . . . . . . . . . . 8
5.3.1. Procedure in IPv6 Host . . . . . . . . . . . . . . . . 8 5.3.1. Procedure in IPv6 Host . . . . . . . . . . . . . . . . 8
5.3.2. Warnings for DNS Options Configuration . . . . . . . . 9 5.3.2. Warnings for DNS Options Configuration . . . . . . . . 9
6. Implementation Considerations . . . . . . . . . . . . . . . . 10 6. Implementation Considerations . . . . . . . . . . . . . . . . 10
6.1. DNS Repository Management . . . . . . . . . . . . . . . . 10 6.1. DNS Repository Management . . . . . . . . . . . . . . . . 10
6.2. Synchronization between DNS Server List and Resolver 6.2. Synchronization between DNS Server List and Resolver
Repository . . . . . . . . . . . . . . . . . . . . . . . . 11 Repository . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Synchronization between DNS Search List and Resolver 6.3. Synchronization between DNS Search List and Resolver
Repository . . . . . . . . . . . . . . . . . . . . . . . . 12 Repository . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 13
7.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Changes from RFC 5006 . . . . . . . . . . . . . . . . 16 Appendix A. Changes from RFC 5006 . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The purpose of this document is to standardize IPv6 Router The purpose of this document is to standardize IPv6 Router
Advertisement (RA) option for DNS configuration in IPv6 hosts Advertisement (RA) option for DNS configuration in IPv6 hosts
specified in an earlier experimental specification [RFC5006] and also specified in an earlier experimental specification [RFC5006] and also
to define a new RA option for Domain Name Search lists. to define a new RA option for Domain Name Search lists.
Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
Autoconfiguration provide ways to configure either fixed or mobile Autoconfiguration provide ways to configure either fixed or mobile
skipping to change at page 13, line 36 skipping to change at page 13, line 36
the DNS query. The processing of these DNSSL domain name is the DNS query. The processing of these DNSSL domain name is
finished here. finished here.
The handling of expired DNSSLs is as follows: Whenever an entry The handling of expired DNSSLs is as follows: Whenever an entry
expires in the DNS Search List, the expired entry is deleted from expires in the DNS Search List, the expired entry is deleted from
the DNS Search List, and also the DNSSL domain name corresponding the DNS Search List, and also the DNSSL domain name corresponding
to the entry is deleted from the Resolver Repository. to the entry is deleted from the Resolver Repository.
7. Security Considerations 7. Security Considerations
The security of the RA options for DNS configuration does not affect In this section, we analyze security threats related to DNS options
ND protocol security [RFC4861]. This is because learning DNS and then suggest recommendations to cope with such security threats.
information via the RA options cannot be worse than learning bad
router information via the RA options. Thus, the vulnerability of ND 7.1. Security Threats
is not worse and is a subset of the attacks that any node attached to
a LAN can do independently of ND. A malicious node on a LAN can For RDNSS option, an attacker could send an RA with a fraudulent
promiscuously receive packets for any router's MAC address and send RDNSS address, misleading IPv6 hosts into contacting an unintended
packets with the router's MAC address as the source MAC address in DNS server for DNS name resolution. Also, for DNSSL option, an
the L2 header. As a result, L2 switches send packets addressed to attacker can let IPv6 hosts resolve a host name without DNS suffix
the router to the malicious node. Also, this attack can send into an unintended host's IP address with a fraudulent DNS search
redirects that tell the hosts to send their traffic somewhere else. list.
The malicious node can send unsolicited RA or Neighbor Advertisement
(NA) replies, answer RS or Neighbor Solicitation (NS) requests, etc. These attacks are similar to Neighbor Discovery attacks that use
Also, an attacker could send an RA with a fraudulent RDNSS address, Redirect or Neighbor Advertisement messages to redirect traffic to
which is presumably an easier avenue of attack than becoming a rogue individual addresses of malicious parties. That is, as a rogue
router and having to process all traffic for the subnet. This attack router, a malicious node on a LAN can promiscuously receive packets
is similar to Neighbor Discovery attacks that use Redirect or for any router's MAC address and send packets with the router's MAC
Neighbor Advertisement messages to redirect traffic to individual address as the source MAC address in the L2 header. As a result, L2
addresses to malicious parties. In general, the attacks related to switches send packets addressed to the router to the malicious node.
RDNSS and DNSSL are similar to both Neighbor Discovery attacks and Also, this attack can send redirects that tell the hosts to send
their traffic somewhere else. The malicious node can send
unsolicited RA or Neighbor Advertisement (NA) replies, answer RS or
Neighbor Solicitation (NS) requests, etc. Thus, the attacks related
to RDNSS and DNSSL are similar to both Neighbor Discovery attacks and
attacks against unauthenticated DHCP, as both can be used for both attacks against unauthenticated DHCP, as both can be used for both
"wholesale" traffic redirection and more specific attacks. "wholesale" traffic redirection and more specific attacks.
If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as However, the security of these RA options for DNS configuration does
a security mechanism for ND, all the ND options including the RDNSS not affect ND protocol security [RFC4861]. This is because learning
and DNSSL options are automatically included in the signatures, so DNS information via the RA options cannot be worse than learning bad
the transport for the RA options is integrity-protected; that is, router information via the RA options. Therefore, the vulnerability
SEND can prevent the spoofing of these DNS options with signatures. of ND is not worse and is a subset of the attacks that any node
Also, SEND enables an IPv6 host to verify that the sender of an RA is attached to a LAN can do independently of ND.
7.2. Recommendations
The Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a
security mechanism for ND. It is RECOMMENDED that ND use SEND to
allow all the ND options including the RDNSS and DNSSL options to be
automatically included in the signatures. Through SEND, the
transport for the RA options is integrity-protected; that is, SEND
can prevent the spoofing of these DNS options with signatures. Also,
SEND enables an IPv6 host to verify that the sender of an RA is
actually a router authorized to act as a router. However, since any actually a router authorized to act as a router. However, since any
valid SEND router can still insert RDNSS and DNSSL options, SEND valid SEND router can still insert RDNSS and DNSSL options, the
cannot verify which one is or is not authorized to send the options. current SEND cannot verify which one is or is not authorized to send
the options. Thus, this verification of the authorized routers for
ND options will be required. [ID-csi-send-cert] specifies the usage
of extended key for the certificate deployed in SEND. This document
defines the roles of routers (i.e., routers acting as proxy and
address owner) and explains the authorization of the roles. The
mechanism in this document can be extended to verify which routers
are authorized to insert RDNSS and DNSSL options.
It is common for network devices such as switches to include It is common for network devices such as switches to include
mechanisms to block unauthorized ports from running a DHCPv6 server mechanisms to block unauthorized ports from running a DHCPv6 server
to provide protection from rogue DHCP servers. That means that an to provide protection from rogue DHCP servers. That means that an
attacker on other ports cannot insert bogus DNS servers using DHCPv6. attacker on other ports cannot insert bogus DNS servers using DHCPv6.
The corresponding technique for network devices is recommended to The corresponding technique for network devices is RECOMMENDED to
block rogue Router Advertisement messages including the RDNSS and block rogue Router Advertisement messages including the RDNSS and
DNSSL options from unauthorized nodes. DNSSL options from unauthorized nodes.
An attacker may provide a bogus DNS Search List option in order to An attacker may provide a bogus DNS Search List option in order to
cause the victim to send DNS queries to a specific DNS server when cause the victim to send DNS queries to a specific DNS server when
the victim queries non-fully qualified domain names. For this the victim queries non-fully qualified domain names. For this
attack, the DNS resolver in IPv6 hosts can mitigate the vulnerability attack, the DNS resolver in IPv6 hosts can mitigate the vulnerability
with the recommendations in [RFC1535], [RFC1536], and [RFC3646]. with the recommendations mentioned in [RFC1535], [RFC1536], and
[RFC3646].
8. IANA Considerations 8. IANA Considerations
The RDNSS option defined in this document is using the IPv6 Neighbor The RDNSS option defined in this document is using the IPv6 Neighbor
Discovery Option type in RFC 5006 [RFC5006] assigned by the IANA as Discovery Option type in RFC 5006 [RFC5006] assigned by the IANA as
follows: follows:
Option Name Type Option Name Type
RDNSS option 25 RDNSS option 25
skipping to change at page 15, line 9 skipping to change at page 15, line 31
DNSSL option (TBD) DNSSL option (TBD)
The IANA registry for these options is: The IANA registry for these options is:
http://www.iana.org/assignments/icmpv6-parameters http://www.iana.org/assignments/icmpv6-parameters
9. Acknowledgements 9. Acknowledgements
This document has greatly benefited from inputs by Robert Hinden, This document has greatly benefited from inputs by Robert Hinden,
Pekka Savola, Iljitsch van Beijnum, Brian Haberman, Tim Chown, Erik Pekka Savola, Iljitsch van Beijnum, Brian Haberman, Tim Chown, Erik
Nordmark, Dan Wing, and Jari Arkko. The authors sincerely appreciate Nordmark, Dan Wing, Jari Arkko, Ben Campbell, Vincent Roca, and Tony
their contributions. Cheneau. The authors sincerely appreciate their contributions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997. Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H.
"Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, Soliman, "Neighbor Discovery for IP Version 6
September 2007. (IPv6)", RFC 4861, September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6
Address Autoconfiguration", RFC 4862, September 2007. Stateless Address Autoconfiguration", RFC 4862,
September 2007.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation
Specification", RFC 1035, November 1987. and Specification", RFC 1035, November 1987.
10.2. Informative References 10.2. Informative References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", [RFC1034] Mockapetris, P., "Domain Names - Concepts and
RFC 1034, November 1987. Facilities", RFC 1034, November 1987.
[RFC3315] Droms, R., Ed., "Dynamic Host Configuration Protocol for [RFC3315] Droms, R., Ed., "Dynamic Host Configuration
IPv6 (DHCPv6)", RFC 3315, July 2003. Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration
(DHCP) Service for IPv6", RFC 3736, April 2004. Protocol (DHCP) Service for IPv6", RFC 3736,
April 2004.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic [RFC3646] Droms, R., Ed., "DNS Configuration options for
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Dynamic Host Configuration Protocol for IPv6
December 2003. (DHCPv6)", RFC 3646, December 2003.
[RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC5006] Jeong, J., Park, S., Beloeil, L., and S.
"IPv6 Router Advertisement Option for DNS Configuration", Madanapalli, "IPv6 Router Advertisement Option
RFC 5006, September 2007. for DNS Configuration", RFC 5006, September 2007.
[RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS
Information Approaches", RFC 4339, February 2006. Server Information Approaches", RFC 4339,
February 2006.
[RFC3971] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", [RFC3971] Arkko, J., Ed., "SEcure Neighbor Discovery
RFC 3971, March 2005. (SEND)", RFC 3971, March 2005.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive [RFC5358] Damas, J. and F. Neves, "Preventing Use of
Nameservers in Reflector Attacks", BCP 140, RFC 5358, Recursive Nameservers in Reflector Attacks",
October 2008. BCP 140, RFC 5358, October 2008.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress
Defeating Denial of Service Attacks which employ IP Source Filtering: Defeating Denial of Service Attacks
Address Spoofing", BCP 38, RFC 2827, May 2000. which employ IP Source Address Spoofing", BCP 38,
RFC 2827, May 2000.
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction [RFC1535] Gavron, E., "A Security Problem and Proposed
With Widely Deployed DNS Software", RFC 1535, Correction With Widely Deployed DNS Software",
October 1993. RFC 1535, October 1993.
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P.,
Miller, "Common DNS Implementation Errors and Suggested and S. Miller, "Common DNS Implementation Errors
Fixes", RFC 1536, October 1993. and Suggested Fixes", RFC 1536, October 1993.
[ID-csi-send-cert] Gagliano, R., Krishnan, S., and A. Kukec,
"Certificate profile and certificate management
for SEND", Work in Progress, June 2010.
Appendix A. Changes from RFC 5006 Appendix A. Changes from RFC 5006
The following changes were made from RFC 5006 "IPv6 Router The following changes were made from RFC 5006 "IPv6 Router
Advertisement Option for DNS Configuration": Advertisement Option for DNS Configuration":
o Added DNS Search List (DNSSL) Option to support the advertisement o Added DNS Search List (DNSSL) Option to support the advertisement
of DNS suffixes used in the DNS search along with RDNSS Option in of DNS suffixes used in the DNS search along with RDNSS Option in
RFC 5006. RFC 5006.
 End of changes. 27 change blocks. 
76 lines changed or deleted 109 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/