Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
--On onsdag, september 07, 2005 17:29:04 -0700 Stuart Cheshire <[EMAIL PROTECTED]> wrote: The difference between LLMNR and mDNS here seems to be that mDNS *requires* me to use two different names in the two different cases; LLMNR, while it certainly *permits* me to do so, does not *require* it. Absolutely not. mDNS allows you to have a single FQDN, and answer those queries via multicast, but recognizes that we need solid security mechanisms before we can honestly recommend that. Thanks for the clarification, and my apologies for missing that! ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
Harald Tveit Alvestrand wrote: >We're probably rehashing the DNSEXT discussion here, but I wasn't part of >the DNSEXT discussion. > >LLMNR allows me to treat names in a different way than mDNS does. >If I have a name that I'm certain I own (this box is, with high certainty, >the only one in the world named HALVESTR-W2K02.emea.cisco.com), LLMNR >allows me to assert that name on a LAN even when the DNS is not available, >or when that name is not currently asserted in the DNS. > >mDNS, as I understand it, doesn't allow me to do that - I would have to >assert "HALVESTR-W2K02.local", or "HALVESTR-W2K02.emea.cisco.com.local". No, this is completely wrong. There are *two* important goals of mDNS: Goal 1: I have a legitimate FQDN, and connectivity with my peers, but no connectivity to the greater Internet right now. In this mode, mDNS (like LLMNR) is providing "fail-over" for unicast DNS. Even on Mac OS 9, five years ago, if you looked up "www.ietf.org" and had no unicast DNS servers configured, it would look it up via mDNS instead. Goal 2: I have no legitimate FQDN. I just need a temporary no-frills name I can use for the time being. This is so that, for example, every HP printer can ship from the factory with the name "hp-printer.local", which is at least good enough for bootstrapping until the customer has assigned a legitimate FQDN for the printer. This is what mDNS uses the ".local" namespace for. It's a free-for-all sand box where all names are up for grabs and no names are quite trustworthy. LLMNR seeks to solve the first goal but not the second, but in failing to provide a sand box for ad hoc names, it makes the entire DNS namespace a sand box for ad hoc names. mDNS seeks to address both problems, but we're aware that looking up general DNS names via unauthenticated local multicast queries has horrible security implications, and we're aware that today we're not confident that we know how to solve that problem, so the mDNS draft recommends: (14. Enabling and Disabling Multicast DNS) The option to fail-over to Multicast DNS for names not ending in ".local." SHOULD be a user-configured option, and SHOULD be disabled by default because of the possible security issues related to unintended local resolution of apparently global names. (24. Security Considerations) When DNS queries for *global* DNS names are sent to the mDNS multicast address (during network outages which disrupt communication with the greater Internet) it is *especially* important to use DNSSEC, because the user may have the impression that he or she is communicating with some authentic host, when in fact he or she is really communicating with some local host that is merely masquerading as that name. >The difference between LLMNR and mDNS here seems to be that mDNS >*requires* me to use two different names in the two different cases; >LLMNR, while it certainly *permits* me to do so, does not *require* it. Absolutely not. mDNS allows you to have a single FQDN, and answer those queries via multicast, but recognizes that we need solid security mechanisms before we can honestly recommend that. LLMNR allows you to have a single FQDN, and ignores the security risks. Stuart Cheshire <[EMAIL PROTECTED]> * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
At 20:30 01/09/2005, Iljitsch van Beijnum wrote: Here's a philosophical question for you: is it right to force a philosophy on people? Dear Iljitsch, I started that debate with Harald in 2000 at the DNSO/GA over the understanding of "global". This mares many issues. Harald says "yes", I say "no", but I understand the need of "yes" on occasions, when the users want it and for transitions. Like in the Roman constitution. Why not once for all gather all the cons and pros and call for an IAB guidance to get documented if the Internet is a directive system or not, or can be distinctly both, at the same time, or at distinct times. I think it can be both if the concerned areas are clearly defined. For example, could classes help in this case to create a real but crossable boarder? I don't know, just an hint to address the security concern. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
--On 2. september 2005 12:46 +0100 Tony Finch <[EMAIL PROTECTED]> wrote: If you have the zone key, you can do the verification offline. How can you be expected to have the zone key of some random name that just turned up on your network? you can always ask the guy for the zone key (and its signature). you have to get a certificate chain that ends up at a root key you trust, of course. Reducing the problem to a previously unsolved problem but if you only care about whether or not it's locally unique, you don't CARE whether it's authentic or not, so you don't have to fetch anything pgpp8W5SKuesS.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
Steven M. Bellovin wrote: > If you have the zone key, you can do the verification offline. How can you update the (root?) zone key timely, upon key rollover or, worse, accidental publication of the key? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
On Fri, 2 Sep 2005, Steven M. Bellovin wrote: > >How can you verify the signature without an Internet connection with which > >to fetch the key? > > If you have the zone key, you can do the verification offline. How can you be expected to have the zone key of some random name that just turned up on your network? > What's going to happen to your link-local uniqueness when someone adds > a bridge? The same issue arises with new devices turning up on the network. Both LLMNR and mDNS have mechanisms for dealing with uniqueness changes. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
In message <[EMAIL PROTECTED]>, Tony Fin ch writes: >On Fri, 2 Sep 2005, Harald Tveit Alvestrand wrote: >> >> Flight of imagination: DNSSEC-Signed records (with the SIG/KEY chain in >> additional data?) would seem to be one possibility to "prove" that the data >> being presented was "legitimate" under DNS delegation rules, even when you >> don't have a present connection to the Internet. > >How can you verify the signature without an Internet connection with which >to fetch the key? If you have the zone key, you can do the verification offline. > >Why does it make sense to strive for globally-unique names when all that >matters is uniqueness on the local link? > Bellovin's Laws of Networking: 1 Networks interconnect. 2 Networks *always* interconnect. 3 Interconnection happens from the edges, not the center What's going to happen to your link-local uniqueness when someone adds a bridge? --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
On Fri, 2 Sep 2005, Harald Tveit Alvestrand wrote: > > Flight of imagination: DNSSEC-Signed records (with the SIG/KEY chain in > additional data?) would seem to be one possibility to "prove" that the data > being presented was "legitimate" under DNS delegation rules, even when you > don't have a present connection to the Internet. How can you verify the signature without an Internet connection with which to fetch the key? Why does it make sense to strive for globally-unique names when all that matters is uniqueness on the local link? Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
On Sep 1, 2005, at 15:17, Harald Tveit Alvestrand wrote: --On torsdag, september 01, 2005 20:30:56 +0200 Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: "You choose" in the DNS case is because you believe (presumably) in the chain of servers between you, the root node and the authoritative server for my domain; in the LLMNR *or* mDNS case, it would be "because he's here and he says so". What I'm missing in this story is how the application finds out who said so. So either you need to allow "Harald said so" for all applications or for none of them. That is not good. Yep. In the DNS case, "the DNS server I asked said so". In the LLMNR and mDNS case, "the machine that answered my multicast said so". Flight of imagination: DNSSEC-Signed records (with the SIG/KEY chain in additional data?) would seem to be one possibility to "prove" that the data being presented was "legitimate" under DNS delegation rules, even when you don't have a present connection to the Internet. My imagination doesn't fly far enough at this time of night to figure out any relationship beteen a ".local" name and the term "legitimacy". But it's late in the evening, so my imagination is not flying very far - perhaps mDNS works because they deliberately abandoned the idea of name ownership. the TBDS work presumed a shared, common name space (the DNS as we know it today) - where each node is "imprinted" with its FQDN and is tagged w/ an x509 cert. The DNS delegations are signed. a change w/ TBDS is that each node runs a DNS server, not just a stub resolver. so it can ask questions and cache answers and when it (the node) runs "into" an authoritative server for something "higher" in the heirarchy, it can "flush" the more specific data in favor of the authoritative stuff. This does not prevent random nodes from trying to spoof being who they are not, but w/ the extra data (signed delegations & x509 certs) the receiving node does have somewhat more data on which to evaluate the "viability" of any given reply ... With TBDS, it is also possible to assert extensions to the namespace, but they would only be honoured by parties that share the same security/trust "hooks" e.g. if we both know the "secret password" then our use of the .piglet TLD works for us. Others ignore these queries. mDNS seems to have taken this idea but restricted it to a single extention, e.g. .local (and yes, there are many fine minefields here, but the project ran out of funding) YMMV. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
On 2-sep-2005, at 0:17, Harald Tveit Alvestrand wrote: Flight of imagination: DNSSEC-Signed records (with the SIG/KEY chain in additional data?) would seem to be one possibility to "prove" that the data being presented was "legitimate" under DNS delegation rules, even when you don't have a present connection to the Internet. Right. I'm looking forward to seeing a protocol that incorporates this notion. My imagination doesn't fly far enough at this time of night to figure out any relationship beteen a ".local" name and the term "legitimacy". But it's late in the evening, so my imagination is not flying very far - perhaps mDNS works because they deliberately abandoned the idea of name ownership. Don't forget that the purpose of multicast DNS / Zeroconf / Rendezvous / Bonjour is service discovery. When you've discovered a service it's helpful to be able to refer to it by name, but the whole name lookup thing seems almost incidental. YMMV. Well, isn't the purpose of a standards organization to make sure that even though your milage may vary, at least you know whether those miles are 1609 or 1852 meters in length? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
--On torsdag, september 01, 2005 20:30:56 +0200 Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: "You choose" in the DNS case is because you believe (presumably) in the chain of servers between you, the root node and the authoritative server for my domain; in the LLMNR *or* mDNS case, it would be "because he's here and he says so". What I'm missing in this story is how the application finds out who said so. So either you need to allow "Harald said so" for all applications or for none of them. That is not good. Yep. In the DNS case, "the DNS server I asked said so". In the LLMNR and mDNS case, "the machine that answered my multicast said so". Flight of imagination: DNSSEC-Signed records (with the SIG/KEY chain in additional data?) would seem to be one possibility to "prove" that the data being presented was "legitimate" under DNS delegation rules, even when you don't have a present connection to the Internet. My imagination doesn't fly far enough at this time of night to figure out any relationship beteen a ".local" name and the term "legitimacy". But it's late in the evening, so my imagination is not flying very far - perhaps mDNS works because they deliberately abandoned the idea of name ownership. YMMV. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
On Thursday, September 01, 2005 15:31:05 -0400 Daniel Senie <[EMAIL PROTECTED]> wrote: These are the same issues I recall asking about when dynamic DNS was being discussed/proposed. Any machine can make a claim they're whomever they want to be, and that request to insert mapping gets fired off to some distant DNS server who has no idea who the client is. I recall being told that any authorization to use a particular name was out of scope of the protocol. Thanking the person who told me this, I've made it a point to disable dynamic DNS in all envinronments since it's been available in running code. It's useless. Actually, it's not completely useless. DDNS can be highly useful in specific deployments, where requests are authenticated and where there is a suitable authorization policy in place. And yes, policy (authorization or otherwise) generally is out of scope for a well-designed protocol, and for good general-purpose implementations as well. For example, here at CMU most of our authoritative nameservers are updated via DDNS; this allows us to map dynamically-assigned addresses to real hostnames, and to mix names of machines with dynamically- and statically-assigned addresses in the same domain. The trick is that DDNS updates are all authenticated, and the only clients permitted to make such updates are the DHCP servers (which add and remove both forward and reverse records for dynamically-assigned hosts) and the tools which propagate changes from the network registration database (which maintain all the other records). Of course, more precise policies are possible. For example, a site like dyndns.org could allow a particular authenticated DDNS client to point its own name to any address it likes, but not to change any other name. I suppose LLMNR might have its uses, too. But I can't figure out what they are, and whether they are worth the significant amount of confusion and breakage which seem likely to result from widespread deployment of this protocol on the Internet. -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
At 02:08 PM 9/1/2005, Harald Tveit Alvestrand wrote: --On 1. september 2005 14:14 +0100 Tony Finch <[EMAIL PROTECTED]> wrote: LLMNR allows me to treat names in a different way than mDNS does. If I have a name that I'm certain I own (this box is, with high certainty, the only one in the world named HALVESTR-W2K02.emea.cisco.com), LLMNR allows me to assert that name on a LAN even when the DNS is not available, or when that name is not currently asserted in the DNS. This kind of naming is not possible for ad-hoc networks without Internet connectivity and without any domain name registration. it's certainly *possible* (if each participant has some relationship to a domain name owner). The question is whether it's *desirable*. I see naming as 3 parts: - I pick a name - I assert that the name belongs to me - You choose to believe it (or not). With DNS names, "I pick a name" involves seeing which names are free in a DNS zone I have a relationship to (which may be dyndns.org, for instance), and doing the admin steps to reserve it. "I assert" involves me putting it into a DNS zone, and loading that zone onto a DNS server, where you'll presumably pick it up. These are the same issues I recall asking about when dynamic DNS was being discussed/proposed. Any machine can make a claim they're whomever they want to be, and that request to insert mapping gets fired off to some distant DNS server who has no idea who the client is. I recall being told that any authorization to use a particular name was out of scope of the protocol. Thanking the person who told me this, I've made it a point to disable dynamic DNS in all envinronments since it's been available in running code. It's useless. Now in the case of link local, it may or may not be useful for me to claim my machine is www.paypal.com and siphon off the requests of anyone dumb enough to listen to that. Or, perhaps, security considerations really are worth reviewing, even in a link local environment. "You choose" in the DNS case is because you believe (presumably) in the chain of servers between you, the root node and the authoritative server for my domain; in the LLMNR *or* mDNS case, it would be "because he's here and he says so". This could be backed up with certificates if you wanted to, of course. The difference between LLMNR and mDNS here seems to be that mDNS *requires* me to use two different names in the two different cases; LLMNR, while it certainly *permits* me to do so, does not *require* it. This is descending into a philosophical debate... "what's in a name"... Or, "how easy is it to spoof a name, and get the guy sitting next to me to fall for it." ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
On 1-sep-2005, at 20:08, Harald Tveit Alvestrand wrote: I see naming as 3 parts: - I pick a name - I assert that the name belongs to me - You choose to believe it (or not). With DNS names, "I pick a name" involves seeing which names are free in a DNS zone I have a relationship to (which may be dyndns.org, for instance), and doing the admin steps to reserve it. "I assert" involves me putting it into a DNS zone, and loading that zone onto a DNS server, where you'll presumably pick it up. "You choose" in the DNS case is because you believe (presumably) in the chain of servers between you, the root node and the authoritative server for my domain; in the LLMNR *or* mDNS case, it would be "because he's here and he says so". What I'm missing in this story is how the application finds out who said so. So either you need to allow "Harald said so" for all applications or for none of them. That is not good. This could be backed up with certificates if you wanted to, of course. Actually, it couldn't, as there is no provision for this in LLMNR. The difference between LLMNR and mDNS here seems to be that mDNS *requires* me to use two different names in the two different cases; LLMNR, while it certainly *permits* me to do so, does not *require* it. This is descending into a philosophical debate... "what's in a name"... Here's a philosophical question for you: is it right to force a philosophy on people? The trouble with LLMNR is that it has lots of repercussions for applications that don't want it, links that don't want it (that one is true for mDNS as well) and even server operators that don't want it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
On Thu, 2005-09-01 at 20:08 +0200, Harald Tveit Alvestrand wrote: > The difference between LLMNR and mDNS here seems to be that mDNS *requires* > me to use two different names in the two different cases; LLMNR, while it > certainly *permits* me to do so, does not *require* it. Can I read this as "LLMNR SHOULD be used with domains in the .local domain" ? Which puts it really in the same baliwick as mDNS (that is the version that existed before that draft was written with the name mdns ;) One can of course easily remove the check for the .local from the real mDNS and use it for anything else too. Just change the MUST into a SHOULD in the draft and everybody is happy. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
--On 1. september 2005 14:14 +0100 Tony Finch <[EMAIL PROTECTED]> wrote: LLMNR allows me to treat names in a different way than mDNS does. If I have a name that I'm certain I own (this box is, with high certainty, the only one in the world named HALVESTR-W2K02.emea.cisco.com), LLMNR allows me to assert that name on a LAN even when the DNS is not available, or when that name is not currently asserted in the DNS. This kind of naming is not possible for ad-hoc networks without Internet connectivity and without any domain name registration. it's certainly *possible* (if each participant has some relationship to a domain name owner). The question is whether it's *desirable*. I see naming as 3 parts: - I pick a name - I assert that the name belongs to me - You choose to believe it (or not). With DNS names, "I pick a name" involves seeing which names are free in a DNS zone I have a relationship to (which may be dyndns.org, for instance), and doing the admin steps to reserve it. "I assert" involves me putting it into a DNS zone, and loading that zone onto a DNS server, where you'll presumably pick it up. "You choose" in the DNS case is because you believe (presumably) in the chain of servers between you, the root node and the authoritative server for my domain; in the LLMNR *or* mDNS case, it would be "because he's here and he says so". This could be backed up with certificates if you wanted to, of course. The difference between LLMNR and mDNS here seems to be that mDNS *requires* me to use two different names in the two different cases; LLMNR, while it certainly *permits* me to do so, does not *require* it. This is descending into a philosophical debate... "what's in a name"... pgp9p5suz7Mfx.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
On 1-sep-2005, at 15:14, Tony Finch wrote: If I have a name that I'm certain I own (this box is, with high certainty, the only one in the world named HALVESTR-W2K02.emea.cisco.com), LLMNR allows me to assert that name on a LAN even when the DNS is not available, or when that name is not currently asserted in the DNS. This kind of naming is not possible for ad-hoc networks without Internet connectivity and without any domain name registration. Apparently, LLMNR tries to remedy this situation by making it possible. However, the protocol doesn't address the issue of name ownership. We actually have protocols that assert name ownership more or less as a by product: x.509 and the like. An LLMNR that requires responders to have an x.509 certificate for the name they're claiming to hold would at least solve this issue. Obviously such a protocol would be utterly useless in any kind of unmanaged environment where local lookups are most needed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
On Thu, 1 Sep 2005, Harald Tveit Alvestrand wrote: > > LLMNR allows me to treat names in a different way than mDNS does. > If I have a name that I'm certain I own (this box is, with high certainty, the > only one in the world named HALVESTR-W2K02.emea.cisco.com), LLMNR allows me to > assert that name on a LAN even when the DNS is not available, or when that > name is not currently asserted in the DNS. This kind of naming is not possible for ad-hoc networks without Internet connectivity and without any domain name registration. On the other hand, even centrally-managed naming is vulnerable to LLMNR breakage. I have evidence (from MTA EHLO hostnames) that it is fairly common for organizations to make up domain names for their internal networks that do not currently exist but which may be delegated in the future, such as orgint.com or organization.int. This is pretty stupid, but it isn't disrecommended by Microsoft. http://support.microsoft.com/?id=254680 If a future product uses LLNMR instead of dynamic DNS they'll have a lot of unhappy customers who find their internal domain has been delegated since they chose their naming structure. > If we separate the concept of "name ownership" from "name assertion > mechanism", and regard the DNS as just one mechanism of name assertion, then > the problem reduces to "how do I prove that I have rights to the name", rather > than "what name should I assert". The delegation structure of DNS proves the right to a name. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
