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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
--> Sent: Friday, June 30, 2006 10:37 AM
--> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
--> Cc: [email protected]; [email protected]
--> 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:[EMAIL PROTECTED]
--> > Sent: Friday, June 30, 2006 2:01 AM To: JINMEI Tatuya Cc:
--> [email protected];
--> > [email protected] 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,
--> [EMAIL PROTECTED] 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
--> [email protected]
--> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--> --------------------------------------------------------------------
-->
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
