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

From: [email-masked]
Date: 12 Jul 2006 09:10:26 -0500

Hi Jinmei,

> -----Original Message----- From: JINMEI Tatuya / 
> &#31070;&#26126;&#36948;&#21705; [mailto:[email-masked]] 
> Sent: Wednesday, July 12, 2006 4:07 AM To: [email-masked] Cc: 
> [email-masked]; [email-masked]; [email-masked] 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-masked] 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-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 13 Jul 2006 17:39:43 +0900

>>>>> On 12 Jul 2006 09:10:26 -0500, 
>>>>> [email-masked] said:

> out of scope in this document.

Without reasonable scheme of key management, TSIG-based approach
cannot be a "candidate" IMO.  It's irresponsible to me to say it's a
candidate, excluding consideration of the difficult part while we
actually know it's almost impossible.

I also think ignoring the reality of key management is against the
sense of the general guideline described in
draft-bellovin-useipsec-04.txt (which is referred to from the I-D
checklist).  Although this draft concentrates on the use of IPsec, I
believe the same guideline should also apply to TSIG or any other
security mechanisms.

In addition, as I pointed out in the previous message, if a TSIG-based
approach is really a candidate, the roaming host is configured with a
TSIG key and with the corresponding server address in practice.  Then
the roaming host doesn't even need the information provided in the RA
option in the first place.  So, the use of S flag can only either be
insecure or meaningless, and that's why I suggest we remove this flag
for now.

Anyway, I believe I've clearly made my point on this issue as input to
the IESG.  If the security ADs are fine with the operation of the S
flag, I won't insist on this point.

					JINMEI, Tatuya