RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'ResolutionofFQDN Conflicts among DHCP Clients' to ProposedStandard]

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'ResolutionofFQDN Conflicts among DHCP Clients' to ProposedStandard]

Woundy, Richard
>I would like to discontinue the practice of assigning the domain name
prefix and the DNS servers from DHCP by default. The domain name prefix
should be defined during the MACHINE network configuration alone. The
use of DHCP discovered DNS servers is a major security hazzard.

I hope this isn't a serious proposal. I don't think you realize how much
depends on DHCP-discovered DNS servers.

Two simple examples: (1) millions of residential Internet customers who
wouldn't know what DNS servers to configure into their computers, and
(2) non-computer Internet devices that don't have a simple user
interface to configure the DNS servers, e.g. VoIP endpoints.

I don't think anyone suggests that an end user should not be able to
override the DNS server addresses supplied by the DHCP server.

-- Rich

P.S. Was there a reason why [hidden email] was part of this
distribution???

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf
Of Hallam-Baker, Phillip
Sent: Thursday, December 01, 2005 4:55 PM
To: Ted Lemon
Cc: [hidden email]; [hidden email]; [hidden email]; Pekka
Savola; [hidden email]; Steven M. Bellovin; Sam Hartman; Bernie Volz
(volz)
Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
Call:'ResolutionofFQDN Conflicts among DHCP Clients' to
ProposedStandard]


 

> -----Original Message-----
> From: Ted Lemon [mailto:[hidden email]]
> Sent: Thursday, December 01, 2005 3:58 PM
> To: Hallam-Baker, Phillip
> Cc: Sam Hartman; [hidden email]; Bernie Volz
> (volz); [hidden email]; [hidden email]; [hidden email]; Steven
> M. Bellovin; Pekka Savola
> Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
> Call:'Resolution ofFQDN Conflicts among DHCP Clients' to
> ProposedStandard]
>
> On Thursday 01 December 2005 12:31, Hallam-Baker, Phillip wrote:
> > My criteria here are that the DNS should support an extension
> > mechanism that allows the definition of new records at will without
> > the need to deploy ANY new code at either the client or the server.
>
> Right, we have that.   It's called the RRtype.   Many, many
> type codes are

NO YOU DO NOT

The majority of the deployed DNS infrastructure does not have the
ability to service new RRs.

The opposite claim has been advanced on several occasions but it is
untrue. There is NO version of the Windows DNS server capable of
PRODUCTION publication of new DNS RRs. A registry hack that does not
survive a reboot does not count. Microsoft has shown the actual DNS code
for saving a zone file, new RRs are simply not handled.

Its not just the dns servers, it's the firewalls and a whole
intermediate layer of RPC services that are used to implement DNS calls
in a large number of real environments.


> available.  Requiring the use of additional labels and not
> taking advantage of the very nice DNS update prerequisite
> support because someone doesn't want
> to support transparent addition of RRtypes is pathetic.  

The DNSEXT group has yet to explain how a production quality DNS server
can add support for a new RR without the need for new code. The ability
to add in blobs of raw hex data does not cut it.

 
> We've had the
> capacity to extend option codes in every DHCP server (as well as most
> clients) in existence practically since day one, and that's a
> much more complicated problem than handling new RRtypes.

DHCP should stick to reporting the IP address. The idea that
configuration services should be configured at the network connection
level is ridiculous. The fact I am on an ethernet segment does not mean
that I trust it or want anything to do with it. If I am on public WiFi
the idea is nonsense on stilts.

I would like to discontinue the practice of assigning the domain name
prefix and the DNS servers from DHCP by default. The domain name prefix
should be defined during the MACHINE network configuration alone. The
use of DHCP discovered DNS servers is a major security hazzard. All DNS
transactions should be TSIG signed.

I will accept the use of DHCP to assist initial machine configuration
and local network configuration. Use of an unauthenticated broadcast
protocol for application configuration is nonsense.

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'ResolutionofFQDN Conflicts among DHCP Clients' to ProposedStandard]

Hallam-Baker, Phillip
I agree that users should never need to configure anything. That is why
I have been arguing for some time that the DNS SRV mechanism should be
used to discover POP and SUBMIT servers. I was a roadrunner customer,
then attbi, then comcast. I am fed up having to reconfigure mail server
accounts. This should be taken care of with the SRV record.


What I was arguing against was the notion that the DNS service should be
reconfigured every time the user changes to a new network.

Users today change networks several times a day. Yesterday I connected
to seven different WiFi networks, 2 at the Web consortium, the hotel
network, the next door hotel network, coffee shop, airport, home.

These networks are not very trustworthy to say the least. But my Windows
box quite happily accepts the advertised services. And the ordinary user
simply cannot be expected to hard wire in the comcast servers.


Instead of switching to a new DNS server by default every time I switch
networks the stacks should explictly support roaming and the concept of
a trusted vs non-trusted network.

There should be a network concept of a trusted network service provider
vs casual connections that I simply ship packets through.

I want DHCP to be no more than a bootstrap. So extending it except to
lock down the existing features does not make a lot of sense.


> -----Original Message-----
> From: Woundy, Richard [mailto:[hidden email]]
> Sent: Friday, December 02, 2005 2:31 PM
> To: Hallam-Baker, Phillip; Ted Lemon
> Cc: [hidden email]; [hidden email]; Pekka Savola;
> [hidden email]; Steven M. Bellovin; Sam Hartman; Bernie Volz (volz)
> Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
> Call:'ResolutionofFQDN Conflicts among DHCP Clients' to
> ProposedStandard]
>
> >I would like to discontinue the practice of assigning the domain name
> prefix and the DNS servers from DHCP by default. The domain
> name prefix should be defined during the MACHINE network
> configuration alone. The use of DHCP discovered DNS servers
> is a major security hazzard.
>
> I hope this isn't a serious proposal. I don't think you
> realize how much depends on DHCP-discovered DNS servers.
>
> Two simple examples: (1) millions of residential Internet
> customers who wouldn't know what DNS servers to configure
> into their computers, and
> (2) non-computer Internet devices that don't have a simple
> user interface to configure the DNS servers, e.g. VoIP endpoints.
>
> I don't think anyone suggests that an end user should not be
> able to override the DNS server addresses supplied by the DHCP server.
>
> -- Rich
>
> P.S. Was there a reason why [hidden email] was part of this
> distribution???
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Hallam-Baker, Phillip
> Sent: Thursday, December 01, 2005 4:55 PM
> To: Ted Lemon
> Cc: [hidden email]; [hidden email]; [hidden email];
> Pekka Savola; [hidden email]; Steven M. Bellovin; Sam
> Hartman; Bernie Volz
> (volz)
> Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
> Call:'ResolutionofFQDN Conflicts among DHCP Clients' to
> ProposedStandard]
>
>
>  
>
> > -----Original Message-----
> > From: Ted Lemon [mailto:[hidden email]]
> > Sent: Thursday, December 01, 2005 3:58 PM
> > To: Hallam-Baker, Phillip
> > Cc: Sam Hartman; [hidden email]; Bernie Volz (volz);
> > [hidden email]; [hidden email]; [hidden email]; Steven M. Bellovin;
> > Pekka Savola
> > Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
> > Call:'Resolution ofFQDN Conflicts among DHCP Clients' to
> > ProposedStandard]
> >
> > On Thursday 01 December 2005 12:31, Hallam-Baker, Phillip wrote:
> > > My criteria here are that the DNS should support an extension
> > > mechanism that allows the definition of new records at
> will without
> > > the need to deploy ANY new code at either the client or
> the server.
> >
> > Right, we have that.   It's called the RRtype.   Many, many
> > type codes are
>
> NO YOU DO NOT
>
> The majority of the deployed DNS infrastructure does not have
> the ability to service new RRs.
>
> The opposite claim has been advanced on several occasions but
> it is untrue. There is NO version of the Windows DNS server
> capable of PRODUCTION publication of new DNS RRs. A registry
> hack that does not survive a reboot does not count. Microsoft
> has shown the actual DNS code for saving a zone file, new RRs
> are simply not handled.
>
> Its not just the dns servers, it's the firewalls and a whole
> intermediate layer of RPC services that are used to implement
> DNS calls in a large number of real environments.
>
>
> > available.  Requiring the use of additional labels and not taking
> > advantage of the very nice DNS update prerequisite support because
> > someone doesn't want to support transparent addition of RRtypes is
> > pathetic.
>
> The DNSEXT group has yet to explain how a production quality
> DNS server can add support for a new RR without the need for
> new code. The ability to add in blobs of raw hex data does
> not cut it.
>
>  
> > We've had the
> > capacity to extend option codes in every DHCP server (as
> well as most
> > clients) in existence practically since day one, and that's a much
> > more complicated problem than handling new RRtypes.
>
> DHCP should stick to reporting the IP address. The idea that
> configuration services should be configured at the network
> connection level is ridiculous. The fact I am on an ethernet
> segment does not mean that I trust it or want anything to do
> with it. If I am on public WiFi the idea is nonsense on stilts.
>
> I would like to discontinue the practice of assigning the
> domain name prefix and the DNS servers from DHCP by default.
> The domain name prefix should be defined during the MACHINE
> network configuration alone. The use of DHCP discovered DNS
> servers is a major security hazzard. All DNS transactions
> should be TSIG signed.
>
> I will accept the use of DHCP to assist initial machine
> configuration and local network configuration. Use of an
> unauthenticated broadcast protocol for application
> configuration is nonsense.
>
> _______________________________________________
> dhcwg mailing list
> [hidden email]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>
>

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'ResolutionofFQDN Conflicts among DHCP Clients' to ProposedStandard]

Woundy, Richard
In reply to this post by Woundy, Richard
Phillip,

This discussion seems to be going off-topic to DHCP-DDNS issues... But I
think I ought to respond so that you can understand service provider
issues better. I can talk to the Comcast service provider experience...
which I don't think is terribly unique to either Comcast or cable
providers.

>I was a roadrunner customer, then attbi, then comcast. I am fed up
having to reconfigure mail server accounts. This should be taken care of
with the SRV record.

I am sorry that you had to do this; it must have been pretty annoying. I
was a MediaOne/RoadRunner/ATTBI/Comcast customer over the past few years
-- and not always an employee of those companies.

I really like DNS SRV records, and I have been promoting their use
within my own company. But I don't think it would have helped in any of
these email transitions. Here is some background:

- After AT&T acquired MediaOne (a large US cable company), AT&T lost
(settled?) a lawsuit with another company named MediaOne (an advertising
agency in South Dakota), losing all rights to the name MediaOne,
particularly the mediaone.net domain name. At one point, the advertising
agency supposedly had plans to run their own email servers, offering
email services to former MediaOne (cable) customers for a monthly fee.

- When AT&T acquired MediaOne, AT&T was ordered by the US DoJ
(Department of Justice, Antitrust Division) to divest all interests in
RoadRunner, and AT&T was restricted in its dealings with RoadRunner (aka
ServiceCo) and TimeWarner for two years,
<http://www.usdoj.gov/atr/cases/f4800/4842.htm>. Note that Time Warner
RoadRunner customers were able to keep their rr.com email addresses.

- AT&T has been quite sensitive about the "att" brand name in the
attbi.com domain name, once Comcast acquired AT&T Broadband. Notice now
that the same AT&T brand name is now owned by a large telephone company
(formerly SBC) that competes head-to-head with Comcast for broadband ISP
customers.

Maybe there could have been clever business arrangements and/or
government intervention to overcome these issues. But I am merely an
engineer. I don't get to tell another company to host an SRV record in
their domain.

>These networks are not very trustworthy to say the least. But my
Windows box quite happily accepts the advertised services. And the
ordinary user simply cannot be expected to hard wire in the comcast
servers.

OK, my turn for a personal example. I use my laptop at work and at home.
At work, my laptop learns about corporate DNS servers from DHCP, which
resolve general Internet names as well as names of some internal servers
that are not reachable from the Internet. At home, my laptop learns
about my ISP's DNS servers from DHCP. The ISP DNS servers cannot resolve
the names of some of my corporate internal servers, and the corporate
DNS servers are not reachable from my ISP (unless I use SSH to access my
corporate network, in which case my ISP's DNS servers are irrelevant
anyway).

So while the current operating system behavior doesn't seem to work for
you, it does work very well for me. I suspect it works for a whole lot
more folks than just me.

I suppose your response will be that my laptop should have support for
trusting different networks in different contexts. Ok, read on...

>There should be a network concept of a trusted network service provider
vs casual connections that I simply ship packets through.

Ok, I'll bite... What identifies a trusted network to your
computer/device?

Suppose you consider the Comcast ISP network to be a "trusted network".
As a real-life example, there has been a lot of changes to the Comcast
network in 2005. I am almost positive that your DHCP server has changed
at least once, and that your DNS server has changed several times. More
likely than not, your IP address/subnet has changed at least once. How
would your laptop identify that it is still on a "Comcast network"?

Ok, you might say that you (as an end-user) would know if you were on
the "Comcast network", and you could notify your computer appropriately.
One issue is that some devices (e.g. VoIP endpoints) may not have a user
interface to communicate this information. Another issue is that some
end-users may be mistaken about what network they are on, e.g. their
computer has locked on a wide-open WiFi access point, not that AP that
they think they are supposed to use.

By the way, you seem to assume that the Comcast DNS caching servers are
available to the entire Internet, so that (as a Comcast customer in any
random part of the Internet) you can reach them. I'm not sure it is a
valid assumption, especially when you consider all residential ISP
providers. There is no (scalable) way for an ISP's DNS caching server to
identify you as an ISP customer, as far as I know. A service provider
might legitimately block access to DNS caching servers from devices off
of its ISP footprint, in order to mitigate denial-of-service attacks
from the Internet at large.

Maybe you should document the "trusted network" concept in an
internet-draft, and get consensus to publish it as an RFC. I think you
will find that this is a non-trivial task (for engineering reasons, not
anything political :^).

>I want DHCP to be no more than a bootstrap. So extending it except to
lock down the existing features does not make a lot of sense.

Not sure what you mean by "extending". DHCP servers (and BOOTP servers
before them) have been handing out DNS server IP addresses for some
time. See RFC 1048, dated February 1988 (almost 18 years ago).

-- Rich

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[hidden email]]
Sent: Friday, December 02, 2005 3:18 PM
To: Woundy, Richard; Ted Lemon
Cc: [hidden email]; [hidden email]; Pekka Savola;
[hidden email]; Steven M. Bellovin; Sam Hartman; Bernie Volz (volz)
Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
Call:'ResolutionofFQDN Conflicts among DHCP Clients' to
ProposedStandard]


I agree that users should never need to configure anything. That is why
I have been arguing for some time that the DNS SRV mechanism should be
used to discover POP and SUBMIT servers. I was a roadrunner customer,
then attbi, then comcast. I am fed up having to reconfigure mail server
accounts. This should be taken care of with the SRV record.


What I was arguing against was the notion that the DNS service should be
reconfigured every time the user changes to a new network.

Users today change networks several times a day. Yesterday I connected
to seven different WiFi networks, 2 at the Web consortium, the hotel
network, the next door hotel network, coffee shop, airport, home.

These networks are not very trustworthy to say the least. But my Windows
box quite happily accepts the advertised services. And the ordinary user
simply cannot be expected to hard wire in the comcast servers.


Instead of switching to a new DNS server by default every time I switch
networks the stacks should explictly support roaming and the concept of
a trusted vs non-trusted network.

There should be a network concept of a trusted network service provider
vs casual connections that I simply ship packets through.

I want DHCP to be no more than a bootstrap. So extending it except to
lock down the existing features does not make a lot of sense.


> -----Original Message-----
> From: Woundy, Richard [mailto:[hidden email]]
> Sent: Friday, December 02, 2005 2:31 PM
> To: Hallam-Baker, Phillip; Ted Lemon
> Cc: [hidden email]; [hidden email]; Pekka Savola;
> [hidden email]; Steven M. Bellovin; Sam Hartman; Bernie Volz (volz)
> Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
> Call:'ResolutionofFQDN Conflicts among DHCP Clients' to
> ProposedStandard]
>
> >I would like to discontinue the practice of assigning the domain name
> prefix and the DNS servers from DHCP by default. The domain
> name prefix should be defined during the MACHINE network
> configuration alone. The use of DHCP discovered DNS servers
> is a major security hazzard.
>
> I hope this isn't a serious proposal. I don't think you
> realize how much depends on DHCP-discovered DNS servers.
>
> Two simple examples: (1) millions of residential Internet
> customers who wouldn't know what DNS servers to configure
> into their computers, and
> (2) non-computer Internet devices that don't have a simple
> user interface to configure the DNS servers, e.g. VoIP endpoints.
>
> I don't think anyone suggests that an end user should not be
> able to override the DNS server addresses supplied by the DHCP server.
>
> -- Rich
>
> P.S. Was there a reason why [hidden email] was part of this
> distribution???
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Hallam-Baker, Phillip
> Sent: Thursday, December 01, 2005 4:55 PM
> To: Ted Lemon
> Cc: [hidden email]; [hidden email]; [hidden email];
> Pekka Savola; [hidden email]; Steven M. Bellovin; Sam
> Hartman; Bernie Volz
> (volz)
> Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
> Call:'ResolutionofFQDN Conflicts among DHCP Clients' to
> ProposedStandard]
>
>
>  
>
> > -----Original Message-----
> > From: Ted Lemon [mailto:[hidden email]]
> > Sent: Thursday, December 01, 2005 3:58 PM
> > To: Hallam-Baker, Phillip
> > Cc: Sam Hartman; [hidden email]; Bernie Volz (volz);
> > [hidden email]; [hidden email]; [hidden email]; Steven M. Bellovin;
> > Pekka Savola
> > Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
> > Call:'Resolution ofFQDN Conflicts among DHCP Clients' to
> > ProposedStandard]
> >
> > On Thursday 01 December 2005 12:31, Hallam-Baker, Phillip wrote:
> > > My criteria here are that the DNS should support an extension
> > > mechanism that allows the definition of new records at
> will without
> > > the need to deploy ANY new code at either the client or
> the server.
> >
> > Right, we have that.   It's called the RRtype.   Many, many
> > type codes are
>
> NO YOU DO NOT
>
> The majority of the deployed DNS infrastructure does not have
> the ability to service new RRs.
>
> The opposite claim has been advanced on several occasions but
> it is untrue. There is NO version of the Windows DNS server
> capable of PRODUCTION publication of new DNS RRs. A registry
> hack that does not survive a reboot does not count. Microsoft
> has shown the actual DNS code for saving a zone file, new RRs
> are simply not handled.
>
> Its not just the dns servers, it's the firewalls and a whole
> intermediate layer of RPC services that are used to implement
> DNS calls in a large number of real environments.
>
>
> > available.  Requiring the use of additional labels and not taking
> > advantage of the very nice DNS update prerequisite support because
> > someone doesn't want to support transparent addition of RRtypes is
> > pathetic.
>
> The DNSEXT group has yet to explain how a production quality
> DNS server can add support for a new RR without the need for
> new code. The ability to add in blobs of raw hex data does
> not cut it.
>
>  
> > We've had the
> > capacity to extend option codes in every DHCP server (as
> well as most
> > clients) in existence practically since day one, and that's a much
> > more complicated problem than handling new RRtypes.
>
> DHCP should stick to reporting the IP address. The idea that
> configuration services should be configured at the network
> connection level is ridiculous. The fact I am on an ethernet
> segment does not mean that I trust it or want anything to do
> with it. If I am on public WiFi the idea is nonsense on stilts.
>
> I would like to discontinue the practice of assigning the
> domain name prefix and the DNS servers from DHCP by default.
> The domain name prefix should be defined during the MACHINE
> network configuration alone. The use of DHCP discovered DNS
> servers is a major security hazzard. All DNS transactions
> should be TSIG signed.
>
> I will accept the use of DHCP to assist initial machine
> configuration and local network configuration. Use of an
> unauthenticated broadcast protocol for application
> configuration is nonsense.
>
> _______________________________________________
> dhcwg mailing list
> [hidden email]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>
>

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg