Hi Jinmei,
-----Original Message----- From: JINMEI Tatuya /
神明達哉 [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 12, 2006 4:07 AM To: [EMAIL PROTECTED] Cc:
[EMAIL PROTECTED]; ipv6@ietf.org; iesg@ietf.org Subject: Re: Last Call:
'IPv6 Router Advertisement Option for DNS Configuration' to Experimental
RFC (draft-jeong-dnsop-ipv6-dns-discovery)
>>>>> On 30 Jun 2006 09:36:59 -0500,
>>>>> [EMAIL PROTECTED] said:
> 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:
(snip)
> 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].
Although this text is not inaccurate, I suspect it doesn't address the
real concern. First, as Pekka indicated, it's dubious whether TSIG
can effectively used for transaction security between stub clients and
recursive DNS servers due to the key management issue. Also, TSIG
authentication is generally ineffective without the corresponding
server address especially in the scenario we are discussing, even
though it's theoretically true that a TSIG key is identified by a
domain-name (not an address). But if the client is configured with
the server address corresponding to the TSIG key, why would it need
this RA option in the first place?
The main objective of this "S flag" gives the hint of DNS service
availability to both the globally roaming hosts in the Internet and the
locally roaming hosts within an administratively managed network, such as
company network and campus network.
In some sense, your point is true. However, in order to provide the DNS
resolution service for the globally roaming hosts which is away from its
home network, I believe that the TSIG-based approach is a good candidate.
The actual key management between stub clients and recursive DNS servers is
out of scope in this document.
So, the real question is whether we really need the "S flag",
considering the current operational trend and reality. I suspect the
answer is negative, and if so, I'd rather suggest we remove this flag
in this initial specification. If we have a reasonable scenario where
this flag can be used safely and in a realistic way in the future,
we can then extend the "Reserved" field.
As one scenario, let's assume that an administer network consists of
multiple subnets. One subnet's router advertises the RDNSS option with
S-flag on. Some mobile host obtains the available RDNSS address through the
RDNSS option. Even though the mobile host moves into another subnet that
does not advertise any RDNSS option, it can know that the RDNSS in the
previous subnet can still be used for DNS resolution.
Let me suggest the new text about this issue:
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 in the routers towards the RDNSSes can be applied for the
source IP addresses of DNS Query messages [15]. That is, 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. The routers discard the
DNS Query messages whose source IP addresses do not belong to their
administered network.
To provide the recursive DNS resolution service for the globally
roaming hosts that are away from their home network, the TSIG-based
authentication can be used for authenticating the hosts [14][16].
The RDNSSes discard the DNS Query messages of the DNS queriers that
do not share the same keys with them. Thus, the RDNSS option's
S-flag does not increase the vulnerability.
...
[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)",
Thanks.
Paul
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
