Hi Eric, I tried to qualify my claim in section 7 (security considerations). You can see the following revised draft reflecting all the comments from you and others during this last call: http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-j eong-dnsop-ipv6-dns-discovery-09.txt
Thanks. Paul > -----Original Message----- > From: Gray, Eric [mailto:[EMAIL PROTECTED] > Sent: Friday, June 30, 2006 11:54 AM > To: [EMAIL PROTECTED] > Cc: [email protected]; Mark Townsley > Subject: RE: Last Call: 'IPv6 Router Advertisement Option for DNS Configuration' to > Experimental RFC (draft-jeong-dnsop-ipv6-dns-discovery) > > 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
