Subject: LLMNR Issue 3

From: Rob Austein <[email-masked]>
Date: Sat, 05 Apr 2003 14:13:40 -0500

Please forgive me if I'm confused on the LLMNR issue resolution
protocol, I didn't see an obvious thread on which to follow up on the
proposed resolution to issue #3.

I have some reservations about the solution proposed for LLMNR issue
#3, and while I won't stand in the way, I thought I should explain my
reservations, since I think they expose a split between two
fundamentally different usage models.

The scenario we discussed at the IETF 56 DNSEXT meeting (two laptops
on an ad hoc network, each laptop knows its own FQDN) is the result of
how I think about naming machines.  My laptop's name is the same no
matter where my laptop goes, and to me the whole FQDN is the laptop's
name, not just the leftmost label, because the FQDN is unambiguous.
Because of this, the proposed resolution to issue #3 seems bizzare to
me: here I have a machine that has a perfectly good unambiguous name,
but the protocol won't let me use it, and instead forces me to cons up
a potentially ambiguous name.

I realize that there are operating systems and networks that operate
on the model that only the leftmost label is the host's business, and
everything else is imposed by the local environment, but I don't
operate that way (and yes, my laptop's DHCP client is configured to
override most of the DNS-related information that might come from the
local environment).

So it seems to me that this proposed resolution is somewhat biased in
favor of a particular model for ad-hoc networks at the expense of
other (perhaps better) models, and increases the likelyhood of name
colisions by forcing users who can supply unambiguous names to use
potentially ambiguous names instead.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 5 Apr 2003 14:52:14 -0600

> a potentially ambiguous name.

You're right.   It is bizarre.   It's there for a good reason, which is 
that Joe Average doesn't think his laptop is called 
"joeaverage.myispsdomain.com".   He thinks it's called "joeaverage".   
So if you want Joe Average to be able to exchange data with Jane 
Average (assuming that Jane Average also doesn't think of her laptop as 
having an FQDN) when they meet in a coffee shop to talk about their 
homework, and Joe and Jane average do not use the same ISP, the only 
name that either one of them has a chance of coming up with is 
"joeaverage" or "janeaverage."

I think this falls apart if you think about it a bit, though - chances 
are that Joe and Jane don't even think of their computers as 
"joeaverage" and "janeaverage" - they think of them as "my computer".   
So the only chance Joe and Jane really have of exchanging data is if 
they see a menu with a name that looks right, like "Joe's Computer".   
They're just not going to be able to come up with a name for each 
other's computer otherwise.   So you might as well use an fqdn.

This brings us to the next problem, which is that neither Joe nor Jane 
are likely to have a reasonable basis for assigning an FQDN to their 
computer right now.   For a computer to have an FQDN, it has to have a 
name registered in the DNS.   Any other definition of "having an FQDN" 
is meaningless (correct me if I am wrong).   Neither Joe nor Jane have 
any idea that their computers ought to have FQDNs, and neither Joe nor 
Jane would have any idea how to get their computers' name registered in 
the DNS even if they realized that it would be useful to do so.   So 
for Joe and Jane, it's necessary that LLMNR allow their computers to 
have names without requiring them to go through the process of 
registering FQDNs for their computers.

This gets even more complicated because Joe and Jane's laptops, being 
portable, may very well switch FQDNs as they move from site to site.   
It's quite likely that both laptops do DHCP from time to time, either 
when they're connecting at home or at work.   It's also likely that 
their respective DHCP servers sometimes assign FQDNs to their laptops, 
unbeknownst to them.   It is extremely unlikely that Joe or Jane will 
be aware of this, and so if their laptops use those names--and only 
those names--in LLMNR, Joe and Jane won't be able to identify their 
laptops.

So I would say that it's fine for your computer to claim it's 
sra-vroom.hactrn.net using LLMNR, as long as Joe and Jane's computers, 
which haven't been explicitly configured with FQDNs, but may have been 
dynamically configured with FQDNs, don't do so.   And if we have to 
pick one or the other behavior as the default, the behavior should 
favor Joe and Jane, because unlike you, they are not prepared to defend 
themselves from misconfiguration.

I should point out that neither Joe nor Jane need be dunces in this 
scenario - they just aren't networking geeks, and don't want to be 
forced to be.   Also, I am making no assertions about whether or not 
Joe and Jane are a couple; this scenario works with all configurations 
of Joe and Jane, and also with Joe and Dave, and with Jane and Rebecca, 
and so on.   :')

---

From: Bill Manning <[email-masked]>
Date: Sun, 6 Apr 2003 09:18:11 -0700 (PDT)

% > The scenario we discussed at the IETF 56 DNSEXT meeting (two laptops
% > on an ad hoc network, each laptop knows its own FQDN) is the result of
% > how I think about naming machines.  My laptop's name is the same no
% > matter where my laptop goes, and to me the whole FQDN is the laptop's
% > name, not just the leftmost label, because the FQDN is unambiguous.
% > Because of this, the proposed resolution to issue #3 seems bizzare to
% > me: here I have a machine that has a perfectly good unambiguous name,
% > but the protocol won't let me use it, and instead forces me to cons up
% > a potentially ambiguous name.

	amen.  thats why the TBDS project chose to key off the FQDN for
	its version of mDNS.

% "joeaverage" and "janeaverage" - they think of them as "my computer".   
% So the only chance Joe and Jane really have of exchanging data is if 
% they see a menu with a name that looks right, like "Joe's Computer".   
% They're just not going to be able to come up with a name for each 
% other's computer otherwise.   So you might as well use an fqdn.

	yup.

% 
% This brings us to the next problem, which is that neither Joe nor Jane 
% are likely to have a reasonable basis for assigning an FQDN to their 
% computer right now.   For a computer to have an FQDN, it has to have a 
% name registered in the DNS.   Any other definition of "having an FQDN" 
% is meaningless (correct me if I am wrong).   Neither Joe nor Jane have 
% any idea that their computers ought to have FQDNs, and neither Joe nor 
% Jane would have any idea how to get their computers' name registered in 
% the DNS even if they realized that it would be useful to do so.   So 
% for Joe and Jane, it's necessary that LLMNR allow their computers to 
% have names without requiring them to go through the process of 
% registering FQDNs for their computers.
% 
% This gets even more complicated because Joe and Jane's laptops, being 
% portable, may very well switch FQDNs as they move from site to site.   
% It's quite likely that both laptops do DHCP from time to time, either 
% when they're connecting at home or at work.   It's also likely that 
% their respective DHCP servers sometimes assign FQDNs to their laptops, 
% unbeknownst to them.   It is extremely unlikely that Joe or Jane will 
% be aware of this, and so if their laptops use those names--and only 
% those names--in LLMNR, Joe and Jane won't be able to identify their 
% laptops.

	perhaps. but there  is the disticntion of where your computer is
	vs who named it.  Joe and Jane likely have Internet access.
	They buy that access from someone.  perhaps [email-masked]
	and [email-masked]  it would seem to not bee too much of a reach to
	presume that bbss and aol will tag the connecting machines of their
	customerss with a name - perhaps joe-pc.aol.com and jane-pda.bbss.net
	and assign credentials to them.... volia, FQDNs.

	Now when joe and jane meet at the StarBucks in Memphis, they get
	new IP addresses but their FQDNs stay the same as their creds... case closed.

% 
% So I would say that it's fine for your computer to claim it's 
% sra-vroom.hactrn.net using LLMNR, as long as Joe and Jane's computers, 
% which haven't been explicitly configured with FQDNs, but may have been 
% dynamically configured with FQDNs, don't do so.   And if we have to 
% pick one or the other behavior as the default, the behavior should 
% favor Joe and Jane, because unlike you, they are not prepared to defend 
% themselves from misconfiguration.
% 
% I should point out that neither Joe nor Jane need be dunces in this 
% scenario - they just aren't networking geeks, and don't want to be 
% forced to be.   Also, I am making no assertions about whether or not 
% Joe and Jane are a couple; this scenario works with all configurations 
% of Joe and Jane, and also with Joe and Dave, and with Jane and Rebecca, 
% and so on.   :')
% 
% 
% --
% to unsubscribe send a message to [email-masked] with
% the word 'unsubscribe' in a single line as the message text body.
% archive: <http://ops.ietf.org/lists/namedroppers/>
% 

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Ted Lemon <[email-masked]>
Date: Sun, 6 Apr 2003 12:41:34 -0500

> 	and assign credentials to them.... volia, FQDNs.

Um, Joe and Jane don't know from FQDNs.   And they may use their 
laptops in more places than just home and Starbucks.   So it's entirely 
possible that their laptops have more than one FQDN that could be 
thought of as "the laptop's FQDN."   And then they will see 
inconsistent behavior when they visit Starbucks.   Sometimes 
joe-pc.aol.com will be Joe's laptop's FQDN, and sometimes it'll be 
joe-pc.megacorp-example.com.   Joe and Jane aren't going to be able to 
predict that.

Joe and Jane will learn about FQDNs only when it's to their advantage 
to do so.   I'm not saying that can't happen.   But right now it's not 
particularly to their advantage, so chances are they don't know about 
them.   Joe and Jane think of FQDNs as things that start with www, smtp 
or pop, that only servers have.

I'm all in favor of changing this - in fact, I'm working to change it - 
but I don't think that the design of a protocol should be predicated on 
the success of my efforts.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 06 Apr 2003 17:45:28 +0000

i've just got to beg to differ.

if joe and jane meet in a coffee shop and, via some combination of an
apple-style "chooser" and bluetooth or 802.11 or irda or null-ether cable
see each other at all, then it's probably adequate for them to see rfc1918
ipv4 addresses or link-local ipv6 addresses (or both).  names are a nicety
but one which the palm-beamers seem to do perfectly well without, most of
the time (since most palm owners don't ever name their pda's.)

the more interesting question is: what if it's 802.11 and a large network,
such as an internet cafe.  in that case, one would immediately say that
ip addresses weren't useful since there would be so many of them.  (when
there's only one, it's safe most of the time to assume you know who it is;
when there's a lot more than one, you just don't know who's who.)  but if
we take this one step further, unqualified names don't help.  on a large
network like an 802.11 internet cafe, there's going to be more than one
jane and probably more than one joe.

the cases where the connectivity is limited to small numbers of other-ends
are such that ip addresses (or names like "other end of null-ether cable")
are good enough.

the cases where the connectivity is not so limited are such that only fully
qualified and "universal" names are good enough.

and in either case, higher level security like certificates ought to be used,
since neither ip addresses nor universal fully qualified domain names are
appropriate for either authentication or authorization.