headers
Josh Littlefield | 1 Aug 2002 22:09
Picon
Favicon

Re: DHCP Option for CableLabs Client Configuration

Erik Nordmark wrote:
>>1.  A primary use case is for testing/lab/trial deployments.  The only way 
>>to configure an MTA (a headless, embedded device) for a non standard port 
>>number would be via the CCC sub-option 4/5 mechanism.
> 
> 
> That seems like an argument for perhaps an experimental RFC, but
> as I understand it the intent is to make this specification a proposed
> standard.
> 

Couldn't this also be a reasonable operational feature?  The use of DNS in 
PacketCable (as specified by these sub-options) is quite restricted.  Using 
non-standard ports may, for example, allow deployment of a specific DNS 
server for PacketCable on the same device as a general nameserver.  Or it 
might just allow extra confidence that the queried server is, in fact, not a 
general purpose Internet DNS server, but a PacketCable specific one.

If CableLabs participants (including operators) have felt the desire to 
deploy these DNS servers on non-standard ports, why shouldn't they be able 
to do that?  Why shouldn't the DHCP configuration info which is specific to 
PakcetCable (or similar CableLabs standards) support that?

--

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
joshl <at> cisco.com                                      250 Apollo Drive
tel: 978-497-8378  fax: same               Chelmsford, MA  01824-3627
Permalink | Reply |
headers
Paul Duffy | 3 Aug 2002 06:49
Picon
Favicon

Re: DHCP Option for CableLabs Client Configuration

At 01:51 AM 8/3/2002 +0200, Erik Nordmark wrote:
> > Couldn't this also be a reasonable operational feature?  The use of DNS in
> > PacketCable (as specified by these sub-options) is quite 
> restricted.  Using
> > non-standard ports may, for example, allow deployment of a specific DNS
> > server for PacketCable on the same device as a general nameserver.  Or it
> > might just allow extra confidence that the queried server is, in fact, 
> not a
> > general purpose Internet DNS server, but a PacketCable specific one.
>
>How does this relate to
>         RFC 2826 IAB Technical Comment on the Unique DNS Root.

Erik, how exactly does a non standard DNS port violate the unique root ?

>I could be wrong bit it seems like folks might be trying to build w
>alled gardens using this "dns on a different port number" as a tool.
>I think we in the IETF should focus on designing the right protocols
>for the Internet and not encourage walled gardens. So why should we add
>additional complexity for this DNS port number thing?
>
>I haven't seen an argument that is convincing to me.
>(And FWIW, the "security through obscurity" argument about using non-standard
>port numbers is actually a reason to not allow a mechanism for alternate
>port numbers; we need to get folks to think about real security.

Security is not Cablelab's primary argument here (recall it was #3 in the 
previous email).  The primary argument is to provide flexibility to our 
customers.
(Continue reading)

Permalink | Reply |
headers
Paul Duffy | 5 Aug 2002 19:07
Picon
Favicon

Re: DHCP Option for CableLabs Client Configuration

Erik...inline please....

> >2. Some MSO's may decide to deploy DNS on non standard ports.  Its a
> >flexibility issue.
> >3. Not using a standard port makes it slightly less prone to attack by
> >script kiddies.
>
>#2 doesn't state why folks see this need. One possibility is
>definitely walled gardens and in general using a different DNS
>tree than the rest of us. I've yet to see any other concrete reason
>for this (and I don't buy flexibility for its own sake).

Rich Woundy has very thoughtfully addressed the "walled garden" issue from 
a service providers point of view.

I have to disagree with you on the flexibility issue.   Hundreds of 
thousands, probably millions, of these "headless" EMTA devices will 
deployed to the field in the next few years.  A conservative approach 
dictates that it should be possible to remotely configure any device 
parameter that might reasonably be expected to require configuration.   We 
feel the protocol port numbers fall into this category.

Remote software upgrades, recall of devices, or a truck roll to the 
customers premises are very expensive and to be avoided.

>And #3 is just security through obscurity which we IMHO have no
>business promoting in our standards.

Yes, this is a very weak argument.  I don't want to leave you with the 
impression that non default port numbers are a key ingredient of the
(Continue reading)

Permalink | Reply |
headers
Erik Nordmark | 6 Aug 2002 13:34
Picon

Re: DHCP Option for CableLabs Client Configuration

> I have to disagree with you on the flexibility issue.   Hundreds of 
> thousands, probably millions, of these "headless" EMTA devices will 
> deployed to the field in the next few years.  A conservative approach 
> dictates that it should be possible to remotely configure any device 
> parameter that might reasonably be expected to require configuration.   We 
> feel the protocol port numbers fall into this category.

I wouldn't use the term "conservative" to describe this - "frivilous
additional complexity for no real benefits" is closer to the words I would use.
 Following this line of argument one could also argue that there
might be a need to run UDP on a protocol number different than the standard
17, etc.

IMHO the criteria should be that the additional flexibility indeed fills
a real need; not that it might be useful.

If this is so critical, why didn't e.g. 3GPP see the need for this when
thinking about deploying hundereds of millions of IP capable mobile phones?

And what about the hundered million or so computers already using IP?
AFAIK there is no mechanism to override the port number used for DNS
even using manual configuration on each box. (E.g. configurable in resolv.conf)

    Erik
Permalink | Reply |
headers
Ralph Droms | 5 Aug 2002 17:21
Picon
Favicon

Re: DHCP Option for CableLabs Client Configuration

How does configuring DNS on a specified port number provide any additional 
ability to provide a DNS service with a different root than configuring the 
client DNS resolver with a specific set of DNS resolvers through DHCP?

- Ralph

At 07:09 AM 8/5/2002 +0200, Erik Nordmark wrote:
> > >How does this relate to
> > >         RFC 2826 IAB Technical Comment on the Unique DNS Root.
> >
> > Erik, how exactly does a non standard DNS port violate the unique root ?
>
>I asked that question with the hope the proponents would think about
>it carefully. Seems like that failed :-)
>
>It seems to me that the DNS as we know it operates on a well-know
>port. Being able to run something using the DNS protocol but
>a different port number sounds like being able to run
>a different naming system with potentially a different root.

[...]

>   Erik
>
>
>_______________________________________________
>dhcwg mailing list
>dhcwg <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg
(Continue reading)

Permalink | Reply |
headers
Erik Nordmark | 6 Aug 2002 13:26
Picon

Re: DHCP Option for CableLabs Client Configuration

> How does configuring DNS on a specified port number provide any additional 
> ability to provide a DNS service with a different root than configuring the 
> client DNS resolver with a specific set of DNS resolvers through DHCP?

Ralph,

I'm trying to determine what significant operational benefits there
are in being able to run DNS on a different port number.
I've yet to see any good explanation of this, hence I'm trying to figure
out what folks might have had in mind. Better support for walled gardens
might have been one thing that some folks might have had in mind.

But I really feel a need to see the significant benefits explained.

  Erik
Permalink | Reply |
headers
Paul Duffy | 5 Aug 2002 17:13
Picon
Favicon

Re: DHCP Option for CableLabs Client Configuration

At 07:09 AM 8/5/2002 +0200, Erik Nordmark wrote:
> > >How does this relate to
> > >         RFC 2826 IAB Technical Comment on the Unique DNS Root.
> >
> > Erik, how exactly does a non standard DNS port violate the unique root ?
>
>I asked that question with the hope the proponents would think about
>it carefully. Seems like that failed :-)

My understanding is that the namespace supported by a DNS server and the 
port the DNS protocol run on are orthogonal.

>It seems to me that the DNS as we know it operates on a well-know
>port. Being able to run something using the DNS protocol but
>a different port number sounds like being able to run
>a different naming system with potentially a different root.
>
> > Security is not Cablelab's primary argument here (recall it was #3 in the
> > previous email).  The primary argument is to provide flexibility to our
> > customers.
>
>But ignoring the testing argument (which is an argument
>for an experimental RFC and not a standard IMHO)
>the remaining arguments are:
> >2. Some MSO's may decide to deploy DNS on non standard ports.  Its a
> >flexibility issue.
> >3. Not using a standard port makes it slightly less prone to attack by
> >script kiddies.
>
>#2 doesn't state why folks see this need. One possibility is
(Continue reading)

Permalink | Reply |
headers
Erik Nordmark | 5 Aug 2002 07:09
Picon

Re: DHCP Option for CableLabs Client Configuration

> >How does this relate to
> >         RFC 2826 IAB Technical Comment on the Unique DNS Root.
> 
> Erik, how exactly does a non standard DNS port violate the unique root ?

I asked that question with the hope the proponents would think about
it carefully. Seems like that failed :-)

It seems to me that the DNS as we know it operates on a well-know
port. Being able to run something using the DNS protocol but
a different port number sounds like being able to run
a different naming system with potentially a different root.

> Security is not Cablelab's primary argument here (recall it was #3 in the 
> previous email).  The primary argument is to provide flexibility to our 
> customers.

But ignoring the testing argument (which is an argument
for an experimental RFC and not a standard IMHO)
the remaining arguments are:
>2. Some MSO's may decide to deploy DNS on non standard ports.  Its a
>flexibility issue.
>3. Not using a standard port makes it slightly less prone to attack by
>script kiddies.

#2 doesn't state why folks see this need. One possibility is
definitely walled gardens and in general using a different DNS
tree than the rest of us. I've yet to see any other concrete reason
for this (and I don't buy flexibility for its own sake).
(Continue reading)

Permalink | Reply |
headers
Erik Nordmark | 3 Aug 2002 01:51
Picon

Re: DHCP Option for CableLabs Client Configuration

> Couldn't this also be a reasonable operational feature?  The use of DNS in 
> PacketCable (as specified by these sub-options) is quite restricted.  Using 
> non-standard ports may, for example, allow deployment of a specific DNS 
> server for PacketCable on the same device as a general nameserver.  Or it 
> might just allow extra confidence that the queried server is, in fact, not a 
> general purpose Internet DNS server, but a PacketCable specific one.

How does this relate to 
	RFC 2826 IAB Technical Comment on the Unique DNS Root.

I could be wrong bit it seems like folks might be trying to build w
alled gardens using this "dns on a different port number" as a tool.

I think we in the IETF should focus on designing the right protocols
for the Internet and not encourage walled gardens. So why should we add
additional complexity for this DNS port number thing?

I haven't seen an argument that is convincing to me.
(And FWIW, the "security through obscurity" argument about using non-standard
port numbers is actually a reason to not allow a mechanism for alternate
port numbers; we need to get folks to think about real security.)

> If CableLabs participants (including operators) have felt the desire to 
> deploy these DNS servers on non-standard ports, why shouldn't they be able 
> to do that?  Why shouldn't the DHCP configuration info which is specific to 
> PakcetCable (or similar CableLabs standards) support that?

I thought we were talking about an Internet standard, and not
a CableLabs standard.
(Continue reading)

Permalink | Reply |

Gmane