RE: Last Call: 'IPv6 Router Advertisement Option for DNS Configuration' to Experimental RFC (draft-jeong-dnsop-ipv6-dns-discovery)

[[e-mail]]

Hi Pekka and Jinmei,

I agree with you at the security issue related to "S flag" for the open 
RDNSS service. So I would like to add the following text to the next 
version of my draft:

---------------------------------------------------------------------------
In page 6,
OLD:
        S             1-bit "Service open" flag.  When set, it indicates
                      that RDNSS(es) in the option can be available for
                      IPv6 hosts when they are detached from the origin
                      subnet where they obtained the RDNSSes.  This flag
                      SHOULD be set only if the routers or firewalls in
                      the network allow DNS Query messages to be routed
                      to the destination RDNSS without being filtered
                      out, and the RDNSS is configured to perform
                      recursive queries for all hosts regardless of
                      their addresses.

NEW:
        S             1-bit "Service open" flag.  When set, it indicates
                      that RDNSS(es) in the option can be available for
                      IPv6 hosts when they are detached from the origin
                      subnet where they obtained the RDNSSes.  This flag
                      SHOULD be set only if the routers or firewalls in
                      the network allow DNS Query messages to be routed
                      to the destination RDNSS without being filtered
                      out, and the RDNSS is configured to perform
                      recursive queries for all hosts regardless of
                      their addresses.  Refer to Section 7 (Security
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                      Considerations) for the security issue related to
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                      S flag.
                      ^^^^^^^

In page 10,
NEW:
7.  Security Considerations
   ...

   When the RDNSSes are open to any hosts with "S flag", they might be
   used as reflectors on DOS attacks [14].  In order to prevent such DoS
   attacks from the hosts using spoofed source addresses, the ingress
   filtering can be applied for the source IP addresses of DNS Query
   messages [15].  The locally roaming hosts can be provided with the
   recursive DNS resolution service within an administratively managed
   network, such as company network and campus network, with the ingress
   filtering based on the source IP addresses of DNS Query messages.  To
   provide the globally roaming hosts with the recursive DNS resolution
   service, the TSIG-based authentication can be used for authenticating
   the hosts [14][16].

   ...

   [14]  Damas, J. and F. Neves, "Preventing Use of Nameservers in
         Reflector Attacks",
         draft-ietf-dnsop-reflectors-are-evil-01.txt (Work in Progress),
         June 2006.

   [15]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", BCP 38, RFC 2827, May 2000.

   [16]  Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
         "Secret Key Transaction Authentication for DNS (TSIG)",
         RFC 2845, May 2000.
---------------------------------------------------------------------------

Thanks.

Paul

> -----Original Message----- From: Pekka Savola [mailto:[e-mail]] 
> Sent: Friday, June 30, 2006 2:01 AM To: JINMEI Tatuya Cc: [e-mail]; 
> [e-mail] Subject: Re: Last Call: 'IPv6 Router Advertisement Option 
> for DNS Configuration' to Experimental RFC 
> (draft-jeong-dnsop-ipv6-dns-discovery)
> 
> On Fri, 30 Jun 2006, JINMEI Tatuya wrote:
> > This time I'm also copying the ipv6 list.  In fact, ipv6@ietf would be
> > more suitable place for discussions on this proposal, since it's an
> > extension to ND.
> ...
> 
> Disclaimer: router-side support for this has been added (as it was
> contributed by others) to radvd which I maintain.  However, I do not
> have a strong opinion on this topic one way or the other.
> 
> If this goes forward, as an implementor I'd like to get IANA codepoint
> assigned quickly so that experiments would interoperate (and
> implementors wouldn't need to steal the next unused value or wait for
> draft-fenner-iana-exp-2780-05.txt to get published).
> 
> [whether IPv6 ND was designed for applictions above layer-3]
> >  So,
> >  + I'd first like to confirm whether my understanding about the
> >    'design principle' is correct.  If it's wrong, then I'm fine and
> >    this concern will be resolved.
> >  + if my understanding is correct, I'd like this document to discuss
> >    why this particular option is so special and needs to be defined
> >    despite the violation of the principle, and to add an explicit
> >    note that configuration information around this layer should not
> >    be provided via RA unless there is a very strong reason.
> 
> The IETF doesn't do a very good job of documenting (and gaining
> consensus on) its design principles, so for any opinions you might get
> on this, you would also have opposite opinions, and hence I'm not sure
> how useful pursuing this line of argument is.
> 
> I guess this underlines that to avoid fuss like this in the future,
> better documentation of design principles might avoid ratholes.
> 
> >>                     This flag
> >>                     SHOULD be set only if the routers or firewalls in
> >>                     the network allow DNS Query messages to be routed
> >>                     to the destination RDNSS without being filtered
> >>                     out, and the RDNSS is configured to perform
> >>                     recursive queries for all hosts regardless of
> >>                     their addresses.
> >
> >My understanding is that current operational trend is generally
> >against such "open recursive servers" as documented in
> >draft-ietf-dnsop-reflectors-are-evil-00.txt.  So I'm skeptical about
> >the usefulness of this flag.  Standardizing such a practice may even
> >be regarded as a conflict with the operational trend.
> >
> >I don't have a strong opinion by pointing it out, but I might
> >consider removing this flag.
> 
> This is a good point and at the very least should be pointed out in
> the security considerations.  However, the text as written does not
> preclude DNS server requiring other form of identification (e.g.,
> TSIG) instead of addresses.  In practice, I doubt such authentication
> would be used very often.
> 
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------