RE: [dhcwg] DHCP Option for CableLabs Client Configuration

["Woundy, Richard" <[e-mail]>]

Erik,

A PacketCable MTA is an interesting Internet host, not quite the same as the
computer on which I am composing this email. The MTA provides one or more
RJ-11 jacks for standard phone sets to be plugged into. The MTA is (at least
in this respect) functional from a subscriber point of view, if the attached
phone set(s) can be used to call phone numbers anywhere in the world,
typically to contact phone sets connected the global Public Switched
Telephone Network (PSTN).

In any Voice over IP architecture (including PacketCable), there is an
assumption that not every telephony endpoint is reachable over the Internet.
That means that the architecture must accommodate the case in which a VoIP
endpoint needs to transmit IP datagrams to intermediate systems in order to
signal/communicate with a legacy telephony endpoint in the PSTN. The primary
intermediate systems in the PacketCable architecture are the "Call
Management Server" (for signaling) and the "Media Gateway" (for bearer
traffic).

The PacketCable 1.0 specifications permit an MTA to communicate with another
MTA within the same administrative domain. The specifications do not forbid
MTA communication with an MTA in a different domain, but they do not specify
the necessary technical infrastructure (e.g. maintaining QoS on a stream of
voice traffic between the two backbone networks). The 1.2 specifications
provide some of the infrastructure needed for an MTA to talk to another MTA
in a different administrative domain, e.g. signaling between call management
servers, and enabling interdomain QoS. But at this time, and for the next
several years, most cable operators are just starting to deploy telephony
services using IP over cable (e.g. DOCSIS), in place of dedicated copper
circuits (such as from the local exchange carrier) or other technologies
(proprietary circuit switched telephony over cable). That implies that most
MTA signaling/communication will be mediated through call management servers
and media gateways -- this is a consequence of what operators (and vendors)
are ready to deploy today, rather than a limitation of the PacketCable
architecture itself.

If MTAs communicate at the IP layer only with other systems (MTAs, call
management servers, media gateways, etc.) within the same domain, then it
makes sense to consider using RFC 1918 private addresses for MTA rather than
public addresses. Using private addresses for MTAs is significant in the
case of AT&T Broadband, since this cable operator already has 1,200,000
telephony subscribers (over broadband cable) today. Note that CableLabs, in
fact, would like cable operators to assign public addresses to MTAs for
interdomain communications... but I'm not sure that ARIN would approve of
that choice given our current generation of products, our (lack of)
interdomain qos expertise, and the large consumption of public addresses
that such a decision would entail.

I suppose you might consider what I have described as a "walled garden" for
MTAs. My first reaction is that the end-goal for the PacketCable
architecture is a voice-over-Internet service, not merely a walled garden
service. My second reaction is this -- why does the IETF care about whether
a particular service deployment is a walled garden or not? Do the IETF
standards only support certain business models, and not others? Do the IETF
standards FORBID walled gardens? I thought the IETF was a technical
standards organization, not a business policy standards body.

If you agree that it is reasonable, at least for the next few years, to use
private IP addresses for PacketCable MTAs, then the following paragraph from
the summary of RFC 2826 applies:

   This does not preclude private networks from operating their own
   private name spaces, but if they wish to make use of names uniquely
   defined for the global Internet, they have to fetch that information
   from the global DNS naming hierarchy, and in particular from the
   coordinated root servers of the global DNS naming hierarchy.

Further guidance is provided by RFC 1918 section 3:

   Moving a host from private to public or vice versa involves a change
   of IP address, changes to the appropriate DNS entries, and changes to
   configuration files on other hosts that reference the host by IP
   address.
...
   Indirect references to such addresses should be contained within the
   enterprise. Prominent examples of such references are DNS Resource
   Records and other information referring to internal private
   addresses. In particular, Internet service providers should take
   measures to prevent such leakage.

It would seem rational that, should it makes sense to assign RFC 1918
private IP addresses to MTAs, and since MTAs require DNS fully qualified
host names as VoIP endpoints in PacketCable (and in SGCP/MGCP, and in SIP),
then RFC 1918 seems to endorse the operation of a parallel DNS
infrastructure for the MTAs and VoIP components. And one way to run a
parallel DNS infrastructure is to use different DNS port numbers for the
VoIP service. This is particularly true for smaller operators, with more
limited capital budgets and smaller VoIP subscriber bases.

By the way, I agree with your point on "security through obscurity". Using
different port numbers to "protect DNS" would not be a very compelling
argument for me, either.

-- Rich

P.S. It wasn't originally my idea to put DNS port number configuration into
the CableLabs Client Configuration option, by the way. For a substantial
period of time, I thought it was a "hack". I have only been recently
convinced that there were significant operational advantages to this
configuration parameter.

-----Original Message-----
From: Erik Nordmark [mailto:[e-mail]]
Sent: Friday, August 02, 2002 7:51 PM
To: Josh Littlefield
Cc: Erik Nordmark; Paul Duffy; Thomas Narten; Bernie Volz (EUD); 'Ralph
Droms'; [e-mail]; [e-mail]; [e-mail]; Matt
Osman
Subject: Re: [dhcwg] 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.  

  Erik



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


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