Re: [mif] apps-team review of draft-ietf-mif-dns-server-selection
<teemu.savolainen@nokia.com> Thu, 15 September 2011 10:55 UTC
Return-Path: <teemu.savolainen@nokia.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6E821F87C2 for <mif@ietfa.amsl.com>; Thu, 15 Sep 2011 03:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.091
X-Spam-Level:
X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qijUk8mHMaqX for <mif@ietfa.amsl.com>; Thu, 15 Sep 2011 03:55:12 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 67A6521F85F6 for <mif@ietf.org>; Thu, 15 Sep 2011 03:55:12 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8FAumec019493; Thu, 15 Sep 2011 13:57:22 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 13:57:01 +0300
Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 15 Sep 2011 12:57:01 +0200
Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Thu, 15 Sep 2011 12:57:00 +0200
From: teemu.savolainen@nokia.com
To: msk@cloudmark.com
Thread-Topic: apps-team review of draft-ietf-mif-dns-server-selection
Thread-Index: AcxyrBw6zVCShQsaRQaFoCi5Am4oqAALTEuAAAtSoYAAHq+RsA==
Date: Thu, 15 Sep 2011 10:57:00 +0000
Message-ID: <916CE6CF87173740BC8A2CE4430969620257496F@008-AM1MPN1-032.mgdnok.nokia.com>
References: <F5833273385BB34F99288B3648C4F06F13512DFC2A@EXCH-C2.corp.cloudmark.com> <916CE6CF87173740BC8A2CE44309696202573D36@008-AM1MPN1-032.mgdnok.nokia.com> <F5833273385BB34F99288B3648C4F06F13512DFC58@EXCH-C2.corp.cloudmark.com>
In-Reply-To: <F5833273385BB34F99288B3648C4F06F13512DFC58@EXCH-C2.corp.cloudmark.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Company Confidential; Project=None;
x-titus-version: 3.3.8.1
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Io6FujjSfNcXJGUP9WUdfQoJmpfVHi50dPq5KK9wdv8YWMOnlWEAV7vitTS8DUHPOf+v+0rDoqIXDlYBGAkr4aFmlVX72DYkzc7FMyhxe1AE8JaiM8N+owe8T46p+5odYFpcc3S+UERsY5D3pIS96GmVqZGZtQWAUs09Yxm1Ek/ZYVTro9BId1kuOpfCWBge+hJ0ptecrs9ytVuIdhk7jdg+3nvOdW/pcJuz+sJe2aL250googH0+uPDSPjEzpjeNw==
x-originating-ip: [10.162.78.119]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_01C9_01CC73AF.5559A0B0"
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Sep 2011 10:57:01.0514 (UTC) FILETIME=[326C2AA0:01CC7396]
X-Nokia-AV: Clean
Cc: mif@ietf.org
Subject: Re: [mif] apps-team review of draft-ietf-mif-dns-server-selection
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Sep 2011 10:55:13 -0000
Hi, inline > -----Original Message----- > From: ext Murray S. Kucherawy [mailto:msk@cloudmark.com] > Sent: 14. syyskuuta 2011 21:21 > To: Savolainen Teemu (Nokia-CTO/Tampere) > Cc: apps-review@ietf.org; apps-ads@tools.ietf.org > Subject: RE: apps-team review of draft-ietf-mif-dns-server-selection > > Fine with me, though I can't reply to mif since I'm not on it so I've > dropped it > from this reply. Feel free to forward this as well. And I can't send to apps-review nor apps-ads, so I'll reply to MIF - hence mailing lists will get every other mail.. > I still think the use of "suffix" is odd, though it's hard to argue that > it's > technically incorrect. For foobar.nokia.com, I would think "nokia.com" is > the > domain name, not a suffix attached to the name "foobar". I'd be more > comfortable with calling "foobar" a prefix, but even that doesn't seem right > to me. > > If you really like the term "suffix", I suggest putting a paragraph > somewhere > early on saying "When we use the term 'DNS suffix', we actually mean a > domain name that is the root of future queries in common" or something like > that. I really liked:) But I looked a bit to RFC3397 (DHCP Domain Search Option) and as that used solely "domain" term, I now remove all "suffix" instances and now that text e.g. says: -- To build the list in an optimal way, a node SHOULD ask with DHCP which DNS servers of each network interface are most likely to be able to successfully serve forward lookup requests matching to specific domain or reverse (PTR record) lookup requests matching to specific network addresses (later referred as "network"). -- > I suggest: > > It is worth noting is that network specific IP addresses can cause > problems also for a single-homed node, if the node retains DNS cache during > movement from one network to another. After the network change, a node > may > have entries in its DNS cache that are no longer correct or appropriate for > its > new network position. Copied as proposed. > OK. In that case, I suggest that this be stated either before the normative > stuff begins, or along with it, to show how important it is that this be the > way > things are done. > > Another approach would be to spell out the security implications of not > precisely following the algorithm later on in Section 10. How about following Security section (I also now splitted it into subtopics): 10. Security Considerations 10.1. Attack vectors It is possible that attackers might try to utilize OPTION_DNS_SERVER_SELECT option to redirect some or all DNS queries sent by a resolver to undesired destinations. The purpose of an attack might be denial-of-service, preparation for man-in-the-middle attack, or something akin. Attackers might try to lure specific traffic by advertising domains and networks from very small to very large scope or simply by trying to place attacker's DNS server as the highest priority default server. The best countermeasure for nodes is to implement validating DNSSEC aware resolvers. Trusting on validation done by a DNS server is a possibility only if a node trusts the DNS server and can use a secure channel for DNS messages. 10.2. Trust levels of network interfaces Decision on trust levels of network interfaces depends very much on deployment scenario and types of network interfaces. For example, unmanaged WLAN may be considered less trustworthy than managed cellular or VPN connections. The decision on levels of trust may be made by implementation, by node administrators, or for example by other standards defining organizations as part of system design work. 10.3. Importance of following the algorithm The Section 4 uses normative language for describing node internal behavior in order to ensure nodes would not open up new attack vectors by accidental use of DNS server selection options. During the standards work consensus was that it is safer to not to enable this option always by default, but only when deemed useful and safe. > > The -04 version should have cleared several > > of these "IPv6 focus" issues (by talking about network addresses instead > > of > > prefixes), but I guess checking again would not hurt. On the other hand, > > IPv6 really is the focus here, as multi-interface behavior with IPv4 > > anyway > > is terrible mess due widespread usage of RFC1918 addressed networks (and > > that's why I'm secretly hoping DHC WG would say they don't want to use > DHCP > > option code for this option and hence this technology must be IPv6- > > only:-D. > > This is also text you might want to add in there, perhaps in a later section > or > an appendix, explaining why doing this in IPv4 space is more challenging. > Referring to another document that already discusses this is fine as well. I'm not sure this document is best for that discussion (because it is way larger than DNS server selection )... the mif problem statement section 4.1 situation 4 and section 4.2 situation 3 refers already to this problem, and that draft is referred first thing in section 1. > I think the thing that's nagging me the most about 4.1 is this: "Therefore, > a > DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be > validated using DNSSEC if DNS queries sent to other servers are still > pending." > If my node is DNSSEC-aware and connected simultaneously to the public > internet and a corporate VPN, but neither the public nameserver nor the one > on the corporate VPN use DNSSEC, then by this rule my node can't use any > reply at all. It seems to me that ought to be a SHOULD NOT, because this is > a > case where my resolver can just use whatever replies it gets. > > It could also be that you're saying you SHOULD NOT use any replies until (a) > you get a DNSSEC one back or (b) you get all of them back and none of them > are DNSSEC-protected in which case you can use any of them at your > discretion. If that's the case, then you should say so. It seems we indeed need to clarify this one. The text misses a paragraph even it seems. This is actually quite big issue I'm afraid and probably Andrew and Ted have something to say as well.. For both DNSSEC-aware and DNSSEC-unaware cellular devices it is extremely important that in the common case DNS queries are not always sent out via all interfaces, as that would consume way too much battery. A tradeoff decision. Can you btw know in advanced whether a DNS server (like behind VPN) is able to perform validation or not before receiving answer from them? Would it be useful information to learn via this option "bit for telling if DNS resolver supports validation"? I'm now adding following key paragraph to section 4.1 (including moving some text from other paragraphs there). Please comment: -- A node SHALL send requests to DNS servers in the order defined by the priority list until an acceptable reply is received, all replies are received, or a time out occurs. In the case of a requested name matching to a specific domain or network rule accepted from any interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be validated using DNSSEC until all DNS servers on the priority list have been contacted or timed out. This protects against possible redirection attacks. In the case of the requested name not matching to any specific domain or network, first received response from any DNS server MAY be considered acceptable. A DNSSEC- aware node MAY always contact all DNS server in an attempt to receive a response that can be validated, but contacting all DNS servers is not mandated for the default case as in some deployments that would consume excess resources. -- > You might just keep everything and rank them in decreasing order of trust, > evaluated through some appropriate means (known friendly networks first, > secured networks second, public networks third), and then search top-to- > bottom when you're preparing to send a query. That's just off the top of my > head though; you guys are the experts here. :-) Sounds too complex... What if just allowing appending the information if received from different DHCPv6 server but same interface, and not accepting an option for each DNS server only once and from the most trusted interface. So have it like this instead, then: -- If the OPTION_DNS_SERVER_SELECT contains a DNS server address already learned from other DHCPv6 servers of the same network, and contains new domains or networks, the node SHOULD append the information to the information received earlier. The node MUST NOT remove previously obtained information. However, the node SHOULD NOT extent lifetime of earlier information either. In the case of conflicting DNS server address is learned from less trusted interface, the node MUST ignore the new information. -- > Fair enough. It's a minor point, but I would probably be more comfortable > with: > > Use of OPTION_DNS_SERVER_SELECT is ideal in the following environments, > but SHOULD NOT be enabled by default otherwise: Hmm.. I guess the old text of "MUST NOT unless configured to do so" equals meaning of "SHOULD NOT". Changing as you proposed unless someone raises voices against? > Your call; removing it is fine, pointing the reader to a useful technology > to fill > that gap is fine too. I think I'll leave it out for now, let's see if others have comments. E.g. BBF that refers to this document refers also those address selection documents.. and also the v6ops doc I mentioned. > > trademarked. I suggest "wireless network". > > > > Teemu>That part was removed at the same time the text talking about > leaking > > names was removed.. > > Why was that removed? I thought it was a good point. Because Andrew was very strongly against that point - i.e. against even hinting that it might be somehow possible to keep private namespaces private. > Good work, thanks for your response! Thanks, and thank you for good review (that is triggering major clarifications). Best regards, Teemu
- Re: [mif] apps-team review of draft-ietf-mif-dns-… teemu.savolainen
- Re: [mif] apps-team review of draft-ietf-mif-dns-… teemu.savolainen