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

["Jaehoon Jeong" <[e-mail]>]

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:[e-mail]]
> Sent: Friday, June 30, 2006 11:54 AM
> To: [e-mail]
> Cc: [e-mail]; 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: [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