Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration

From: Erik Nordmark <[email-masked]>
Date: Thu, 1 Aug 2002 19:12:14 +0200 (CEST)

> 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.

> 2. Permitting protocol servers to run on a non standard port is not without 
> precedence.  Its been pointed out that Paul Vixie's "named" server allows 
> it to be configured on a specific port. Does this mean that Paul is 
> violating Internet Standards ?  Come to think of it, I don't think I've 
> ever seen a protocol server that did not permit configuration of its 
> protocol port.

I don't think anybody has claimed that servers must always use the
standard port number.

Instead the issue seems to be that the sole reason that these suboptions
are needed i.e. why the standard DHCP options for DNS servers are not 
sufficient. is the claimed need to support non-standard port numbers. 

Why invent a new standard mechanism for this, especially since the utility 
is limited to testing/lab/trials?

  Erik

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

---

From: Josh Littlefield <[email-masked]>
Date: Thu, 01 Aug 2002 16:09:28 -0400

> as I understand it the intent is to make this specification a proposed

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.
[email-masked]                                      250 Apollo Drive
tel: 978-497-8378  fax: same               Chelmsford, MA  01824-3627

---

From: Paul Duffy <[email-masked]>
Date: Thu, 01 Aug 2002 16:01:17 -0400

Thanks Erik,

Re: optional port numbers ...

1. Cablelabs needs it for testing, lab, etc.
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.

...I'm out of arguments.   What specific suggestions do you have would give 
us the port configuration control ?

Thanks,

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 3 Aug 2002 01:51:26 +0200 (CEST)

> 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.)

> PakcetCable (or similar CableLabs standards) support that?

I thought we were talking about an Internet standard, and not
a CableLabs standard.  

  Erik

---

From: Paul Duffy <[email-masked]>
Date: Sat, 03 Aug 2002 00:49:59 -0400

>         RFC 2826 IAB Technical Comment on the Unique DNS Root.

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

>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.

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 5 Aug 2002 07:09:11 +0200 (CEST)

> 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.

> previous email).  The primary argument is to provide flexibility to our 

But ignoring the testing argument (which is an argument
for an experimental RFC and not a standard IMHO)
>3. Not using a standard port makes it slightly less prone to attack by

#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).

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

  Erik

---

From: Paul Duffy <[email-masked]>
Date: Mon, 05 Aug 2002 11:13:22 -0400

>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.

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Mon, 05 Aug 2002 11:21:32 -0400

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

>a different naming system with potentially a different root.

[...]

---

From: Paul Duffy <[email-masked]>
Date: Mon, 05 Aug 2002 13:07:17 -0400

Erik...inline please....

>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.

>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 
PacketCable security architecture (strictly speaking, this is not 
considered part of PacketCable security).  PacketCable makes extensive use 
of Kerberos to authenticate MTAs to the provider network, and IPSec to 
secure traffic between PacketCable components.  If you're curious, 
see  http://www.packetcable.com/specs/PKT-SP-SEC-I05-020116.pdf.

Cheers,

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 6 Aug 2002 13:26:09 +0200 (CEST)

> 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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 6 Aug 2002 13:34:22 +0200 (CEST)

> 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