[Gen-art] RE: Last Call: 'IPv6 Router Advertisement Option for DNS Configur ation' to Experimental RFC (draft-jeong-dnsop-ipv6-dns-discovery)

["Gray, Eric" <[e-mail]>]

Paul,

	This change would also satisfy my concerns with section 7
(with the exception that you should also qualify the statements 
that currently imply that the proposal does not introduce new 
security risks).

	I omitted the IPv6 mailing list as they have not seen my
comments...

--
Eric

--> -----Original Message-----
--> From: [e-mail] [mailto:[e-mail]] 
--> Sent: Friday, June 30, 2006 10:37 AM
--> To: [e-mail]; [e-mail]
--> 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) 
--> 
--> 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
--> --------------------------------------------------------------------
--> 

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art