Subject: RE: Stateless DNS discovery draft

From: [email-masked]
Date: Wed, 17 Apr 2002 11:37:23 +0300

Hi Toshi,

> I absolutely agree.
> 
> In other word, there are typically three players,
> 
> 1) end-host
> 2) site network
> 3) ISP network
> 
> and "Stateless DNS discoery" is a zero-configuration method 
> mainly for 1).
> 
> When the administrator of 2) wants to prepare DNS servers in his/her site
> with assigning the well-know-site-local-uni-cast-addresses to them, 1)
> simply queries to them.
> 
> When the ISP prepares DNS servers in its backbone, the CPE router of 2) acts
> as a dual-sited DNS proxy to relay queries to the the
> well-know-site-local-uni-cast-addresses of the ISP's site, or to the global
> addresses which are informed via ISP-to-Customer (or PE-to-CPE)
> configuration mechanism such as DHCPv6, SLP or papers.

I agree with you, this is a very good and to-the-point summary.

I'd just like to point out that the need is especially crucial in
roaming situations.  It should be possible to 'discover' DNS servers
when roaming in new networks with minimal interaction from the user.

John

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Yamasaki Toshi" <[email-masked]>
Date: Wed, 17 Apr 2002 18:25:50 +0900

Hi John,

>  It should be possible to 'discover' DNS servers?

Yes, that's the point.

Wherever the end-host is, at the office, at home, at a hotspot, or at mobile
enviroment, it simply queries to a well-known-sitelocal/global-address, and
the query is lead to an appropriate DNS server which is prepared by the site
administrator of each situation with manual configuration or
auto-configuration.

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, April 17, 2002 5:37 PM
Subject: RE: Stateless DNS discovery draft

Hi Toshi,

John

---

From: Bill Manning <[email-masked]>
Date: Wed, 17 Apr 2002 04:19:29 -0700 (PDT)

why is there a need for yet another suite of reserved
	"well-known" addresses for DNS servers?
	Am I the only one who feels that this is a significant
	breach of the integrity of the DNS system?
	Or is this simply the path of least resistance and
	folks are willing to abandon the integrity of the data
	that the DNS is publishing? Or will this only be deployed
	once there are other means to verify the integrity of the
	data (can you say DNSSEC? sure you can.)

	There are other ways to discover DNS servers in a
	(roaming/ad-hoc/untethered) environment.  

% Hi John,
% 
% >  It should be possible to 'discover' DNS servers?
% > when roaming in new networks with minimal interaction from the user.
% 
% Yes, that's the point.
% 
% Wherever the end-host is, at the office, at home, at a hotspot, or at mobile
% enviroment, it simply queries to a well-known-sitelocal/global-address, and
% the query is lead to an appropriate DNS server which is prepared by the site
% administrator of each situation with manual configuration or
% auto-configuration.
% 
% ----- Original Message -----
% From: <[email-masked]>
% To: <[email-masked]>; <[email-masked]>;
% <[email-masked]>
% Sent: Wednesday, April 17, 2002 5:37 PM
% Subject: RE: Stateless DNS discovery draft
% 
% 
% Hi Toshi,
% 
% > I absolutely agree.
% >
% > In other word, there are typically three players,
% >
% > 1) end-host
% > 2) site network
% > 3) ISP network
% >
% > and "Stateless DNS discoery" is a zero-configuration method
% > mainly for 1).
% >
% > When the administrator of 2) wants to prepare DNS servers in his/her site
% > with assigning the well-know-site-local-uni-cast-addresses to them, 1)
% > simply queries to them.
% >
% > When the ISP prepares DNS servers in its backbone, the CPE router of 2)
% acts
% > as a dual-sited DNS proxy to relay queries to the the
% > well-know-site-local-uni-cast-addresses of the ISP's site, or to the
% global
% > addresses which are informed via ISP-to-Customer (or PE-to-CPE)
% > configuration mechanism such as DHCPv6, SLP or papers.
% 
% I agree with you, this is a very good and to-the-point summary.
% 
% I'd just like to point out that the need is especially crucial in
% roaming situations.  It should be possible to 'discover' DNS servers
% when roaming in new networks with minimal interaction from the user.
% 
% John
% 
% --------------------------------------------------------------------
% IETF IPng Working Group Mailing List
% IPng Home Page:                      http://playground.sun.com/ipng
% FTP archive:                      ftp://playground.sun.com/pub/ipng
% Direct all administrative requests to [email-masked]
% --------------------------------------------------------------------
% 

-- 
--bill

---

From: "Yamasaki Toshi" <[email-masked]>
Date: Thu, 18 Apr 2002 15:17:24 +0900

I assume an end-host trust the administrator of the site which itself is
connceted to. In other words, it believes that the route(s) to the
well-known addresses are properly configured so that queries are lead to
proper DNS servers.

Yes, there are security issues, but no worse than non-well-known address
methods.

---

From: Bill Manning <[email-masked]>
Date: Thu, 18 Apr 2002 10:33:14 -0700 (PDT)

% I assume an end-host trust the administrator of the site which itself is
% connceted to. In other words, it believes that the route(s) to the
% well-known addresses are properly configured so that queries are lead to
% proper DNS servers.

	this is naive, particularly in a tetherless environment.
	
% 
% Yes, there are security issues, but no worse than non-well-known address
% methods.

	hogwash. if one expects DNS servers to always be available
	at, for example, fe80:dead:beef::53, then -anyone- can make 
	a server available at that address, not just the site admin.
	
% 
% > why is there a need for yet another suite of reserved
% > "well-known" addresses for DNS servers?
% > Am I the only one who feels that this is a significant
% > breach of the integrity of the DNS system?
% > Or is this simply the path of least resistance and
% > folks are willing to abandon the integrity of the data
% > that the DNS is publishing? Or will this only be deployed
% > once there are other means to verify the integrity of the
% > data (can you say DNSSEC? sure you can.)
% >
% > There are other ways to discover DNS servers in a
% > (roaming/ad-hoc/untethered) environment.
% >
% >
% > % Hi John,
% > %
% > % >  It should be possible to 'discover' DNS servers?
% > % > when roaming in new networks with minimal interaction from the user.
% > %
% > % Yes, that's the point.
% > %
% > % Wherever the end-host is, at the office, at home, at a hotspot, or at
% mobile
% > % enviroment, it simply queries to a well-known-sitelocal/global-address,
% and
% > % the query is lead to an appropriate DNS server which is prepared by the
% site
% > % administrator of each situation with manual configuration or
% > % auto-configuration.
% > %
% > % ----- Original Message -----
% > % From: <[email-masked]>
% > % To: <[email-masked]>; <[email-masked]>;
% > % <[email-masked]>
% > % Sent: Wednesday, April 17, 2002 5:37 PM
% > % Subject: RE: Stateless DNS discovery draft
% > %
% > %
% > % Hi Toshi,
% > %
% > % > I absolutely agree.
% > % >
% > % > In other word, there are typically three players,
% > % >
% > % > 1) end-host
% > % > 2) site network
% > % > 3) ISP network
% > % >
% > % > and "Stateless DNS discoery" is a zero-configuration method
% > % > mainly for 1).
% > % >
% > % > When the administrator of 2) wants to prepare DNS servers in his/her
% site
% > % > with assigning the well-know-site-local-uni-cast-addresses to them, 1)
% > % > simply queries to them.
% > % >
% > % > When the ISP prepares DNS servers in its backbone, the CPE router of
% 2)
% > % acts
% > % > as a dual-sited DNS proxy to relay queries to the the
% > % > well-know-site-local-uni-cast-addresses of the ISP's site, or to the
% > % global
% > % > addresses which are informed via ISP-to-Customer (or PE-to-CPE)
% > % > configuration mechanism such as DHCPv6, SLP or papers.
% > %
% > % I agree with you, this is a very good and to-the-point summary.
% > %
% > % I'd just like to point out that the need is especially crucial in
% > % roaming situations.  It should be possible to 'discover' DNS servers
% > % when roaming in new networks with minimal interaction from the user.
% > %
% > % John
% > %
% > % --------------------------------------------------------------------
% > % IETF IPng Working Group Mailing List
% > % IPng Home Page:                      http://playground.sun.com/ipng
% > % FTP archive:                      ftp://playground.sun.com/pub/ipng
% > % Direct all administrative requests to [email-masked]
% > % --------------------------------------------------------------------
% > %
% >
% >
% > --
% > --bill
% >
% >
%

---

From: "Yamasaki Toshi" <[email-masked]>
Date: Fri, 19 Apr 2002 12:54:15 +0900

> a server available at that address, not just the site admin.

Sure :-)
But we are not talking about well-known-LINK-LOCAL, but
well-known-SITE-LOCAL or well-known-GLOBAL.

In this case, how do you do that while you can't control routes?

---

From: Bill Manning <[email-masked]>
Date: Thu, 18 Apr 2002 21:34:54 -0700 (PDT)

% > hogwash. if one expects DNS servers to always be available
% > at, for example, fe80:dead:beef::53, then -anyone- can make
% > a server available at that address, not just the site admin.
% 
% Sure :-)
% But we are not talking about well-known-LINK-LOCAL, but
% well-known-SITE-LOCAL or well-known-GLOBAL.
% 
% In this case, how do you do that while you can't control routes?

	Its harder w/ v4 than v6.  v6, its dirt simple.
	turn on routing for your DNS server. It advertizes
	its self and the well-known address to the local segment.
	Odds are that the well-known prefix is "nearer" from
	this new router than from the "offical" egress point.
	Other nodes, listening to RA/ND see this new router 
	and the well-known prefix. can you say hijack? 
	
	next.  

	(Honestly, have none of you actually run a network
	or is it all just simulation?)

--bill

---

From: [email-masked]
Date: Fri, 19 Apr 2002 13:51:26 +0900

>	and the well-known prefix. can you say hijack? 

	the issues with anycast address is documented in
	draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt (pending IESG review),
	so we don't need to repeat it here.

	i can buy the argument with router advertisement, however, i cannot
	for routing advertisements.  if you don't protect routing
	infrastructure, it's your fault.  routing protocols must be secured
	or you are in trouble.

	btw - both RIPng and OSPFv3 relies upon IPsec over multicast and
	do not define its own security mechanism.  i wonder how many
	implementation can do this.  IPsec over multicast is, i would say,
	hard (not to mention automatic key exchange).

itojun

---

From: "Yamasaki Toshi" <[email-masked]>
Date: Fri, 19 Apr 2002 15:37:28 +0900

> and the well-known prefix. can you say hijack?

That's exactly the words which I expect.

As Itojun said, it's an issue of routing security. As I said,

>Yes, there are security issues, but no worse than non-well-known
> address methods.

you have almost the same issue which you described above, whether you use
well-known or non-well-known.

--- Toshi

---

From: Bill Manning <[email-masked]>
Date: Fri, 19 Apr 2002 01:04:29 -0700 (PDT)

% 	routing protocols must be secured
% 	or you are in trouble.
% itojun

	the problem is, most (all?) routing protocols are
	"trusting" i.e. none are inherently securable. 
	For now, its "bags on the side" if it can be done
	at all.

---

From: Bill Manning <[email-masked]>
Date: Fri, 19 Apr 2002 01:11:57 -0700 (PDT)

% you have almost the same issue which you described above, whether you use
% well-known or non-well-known.
% 
% --- Toshi

	Not so.  with well-known addresses, the hijack works 
	every time.  if the nameservers (like today) are 
	different, depending on inital configuration (/etc/resolv.conf)
	or passed to the node by a dhcp server, then it is much
	harder to hijack every node every time.  

	However, I don't wish to impead the progress of this WG.
	I'll go back to tending my roses.

--bill

---

From: Bob Hinden <[email-masked]>
Date: Fri, 19 Apr 2002 09:57:34 -0700

I disagree.  Hackers who have this level of sophistication can just as 
easily disrupt DHCP(v4or v6) server traffic, DHCP relay traffic, and/or the 
traffic to DNS servers that are advertised by the DHCP servers.

Bob

---

From: Bill Manning <[email-masked]>
Date: Fri, 19 Apr 2002 11:33:50 -0700 (PDT)

and this is ok?  we should tolerate this level of capability?
	I thought we had the chance to build in better capability
	to ensure the integrity of the system instead of maintaining
	the status quo?  The landscape is changing (teatherless)
	and the threats are more pronounced.  Now we could spin this
	in a slightly different manner, where local admins are simply
	trying to get things working in the face of overbearing
	glacial red-tape.  Sort of the same justification many used
	for deployment of NAT.  Not hackers at all, just folks trying
	to get things to work... :)

	However, I really should just let this alone. It might be worth
	the paper to put some of these concerns into the security 
	section of your standards track RFC.

% I disagree.  Hackers who have this level of sophistication can just as 
% easily disrupt DHCP(v4or v6) server traffic, DHCP relay traffic, and/or the 
% traffic to DNS servers that are advertised by the DHCP servers.
% 
% Bob
% 
% At 01:11 AM 4/19/2002, Bill Manning wrote:
% >% you have almost the same issue which you described above, whether you use
% >% well-known or non-well-known.
% >%
% >% --- Toshi
% >
% >         Not so.  with well-known addresses, the hijack works
% >         every time.  if the nameservers (like today) are
% >         different, depending on inital configuration (/etc/resolv.conf)
% >         or passed to the node by a dhcp server, then it is much
% >         harder to hijack every node every time.
% >
% >         However, I don't wish to impead the progress of this WG.
% >         I'll go back to tending my roses.
% >
% >--bill
% >--------------------------------------------------------------------
% >IETF IPng Working Group Mailing List
% >IPng Home Page:                      http://playground.sun.com/ipng
% >FTP archive:                      ftp://playground.sun.com/pub/ipng
% >Direct all administrative requests to [email-masked]
% >--------------------------------------------------------------------
% 
% --------------------------------------------------------------------
% IETF IPng Working Group Mailing List
% IPng Home Page:                      http://playground.sun.com/ipng
% FTP archive:                      ftp://playground.sun.com/pub/ipng
% Direct all administrative requests to [email-masked]
% --------------------------------------------------------------------
%