>>>>> 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?
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.
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
--------------------------------------------------------------------
