>1. Are well known ports archaic? If so, can we request that the
IANA
> do away with the distinction?
I don't know whether I would use the word "archaic", but the distinction
between < 1024 and >= 1024 is certainly Unix-specific. In the Windows
operating systems, the port range 1-1023 i
Hi -
> From: "Christian Huitema" <[EMAIL PROTECTED]>
> To: "Eliot Lear" <[EMAIL PROTECTED]>; "IETF Discussion"
> Cc: "IANA" <[EMAIL PROTECTED]>; "Lisa Dusseault" <[EMAIL PROTECTED]>;
> "netconf&quo
On Sat, 18 Mar 2006 10:44:13 -0800, "Christian Huitema"
<[EMAIL PROTECTED]> wrote:
> >1. Are well known ports archaic? If so, can we request that the
> IANA
> > do away with the distinction?
>
> I don't know whether I would use the word "archaic", but the distinction
> between < 1024 a
> A more interesting question is this: what are the odds that a user
> process will accidentally grab the port number before the system
> process gets to it? The notion of a "privileged" port number is
> certainly preposterous; that said, putting services in a range that
> ordinary applications te
On Sat, 18 Mar 2006 12:41:25 -0800, "Christian Huitema"
<[EMAIL PROTECTED]> wrote:
> If there is a reserved range, then it
> is easy to start dynamic allocation outside the range.
Yes -- this is my point. I don't care about Unix-style privileged
ports (and have never liked them anyway), but putti
I would not that starting dynamic ports above 1024 or even above 4096
is not sufficient. There are already services with assigned ports
higher than that. And it keeps growing. The IANA list of well-known
ports is quite long.
If we could go back and start over, something like dynamic DNS and
> All that aside, the IANA has a distinction (based on history)
> between ports below 1024 and those above. And whne asking
> for a port number assignment, one specifies which range one
> wants. I had least can not find a coherent strategy for what
> should be on one side or the other of tha
The whole idea of fixed ports is broken.
The idea that there are only 1024 or even 65535 Internet applications is
broken.
The Internet has a signalling layer, the DNS. Applications should use it.
The SRV record provides an infinitely extensible mechanism for advertising
ports.
Fixed ports do no
On Sat, 2006-03-18 at 09:38 -0800, Eliot Lear wrote:
> This therefore leads to two questions for the community:
>
>1. Are well known ports archaic? If so, can we request that the IANA
> do away with the distinction?
>2. If they are not archaic, under what circumstances should they b
While in general I would like to see this approach taken, this
particular case is a perfect example of where I think one can not
reasonably do that. The protocol is for the purpose of configuring a
router. The router that needs to be configured could easily be
between the network engineer and
Steven M. Bellovin wrote:
On Sat, 18 Mar 2006 12:41:25 -0800, "Christian Huitema"
<[EMAIL PROTECTED]> wrote:
If there is a reserved range, then it
is easy to start dynamic allocation outside the range.
Yes -- this is my point. I don't care about Unix-style privileged
ports (and have never l
The whole idea of fixed ports is broken.
The idea that there are only 1024 or even 65535 Internet applications is
broken.
agree with you so far.
The Internet has a signalling layer, the DNS. Applications should use it.
strongly disagree. DNS is a huge mess. It is slow and unreliable. In
This therefore leads to two questions for the community:
1. Are well known ports archaic? If so, can we request that the IANA
do away with the distinction?
2. If they are not archaic, under what circumstances should they be
allocated?
My opinion:
they are archaic and should
Hallam-Baker, Phillip wrote:
> The whole idea of fixed ports is broken.
...
> The Internet has a signalling layer, the DNS. Applications should use it.
> The SRV record provides an infinitely extensible mechanism for advertising
> ports.
And with what port would I reach this magical DNS that wou
> From: Joe Touch [mailto:[EMAIL PROTECTED]
> And with what port would I reach this magical DNS that would
> provide the SRV record for the DNS itself?
You use fixed ports for the bootstrap process and only for the bootstrap
process.
> > Fixed ports do not work behind NAT. Anyone who wants
> On Sat, 2006-03-18 at 09:38 -0800, Eliot Lear wrote:
> > This therefore leads to two questions for the community:
> >
> >1. Are well known ports archaic? If so, can we request that the IANA
> > do away with the distinction?
> >2. If they are not archaic, under what circumstances sh
Regardless of what the community consensus is on:
1. Are well known ports archaic?
I want to comment that on this:
If so, can we request that the IANA
do away with the distinction?
The IETF decides, and the IANA will then be responsible for implementing the
decision.
Brian
Hallam-Baker, Phillip wrote:
>> From: Joe Touch [mailto:[EMAIL PROTECTED]
>
>> And with what port would I reach this magical DNS that would
>> provide the SRV record for the DNS itself?
>
> You use fixed ports for the bootstrap process and only for the bootstrap
> process.
Which means that t
On Sat, Mar 18, 2006 at 02:09:47PM -0800,
Hallam-Baker, Phillip <[EMAIL PROTECTED]> wrote
a message of 163 lines which said:
> The Internet has a signalling layer, the DNS. Applications should
> use it. The SRV record provides an infinitely extensible mechanism
> for advertising ports.
I agre
On Sun, Mar 19, 2006 at 12:42:17PM -0800,
Ned Freed <[EMAIL PROTECTED]> wrote
a message of 35 lines which said:
> The privileged port concept has some marginal utility on multiuser
> systems where you don't Joe-random-user to grab some port for a well
> known service.
"had", not "has". The con
Title: Re: Guidance needed on well known ports
Refusing new registrations is what I meant by closing the registry.
Of course it is not possible to change the way deployed systems work retrospectively.
The question was about a new protocol.
We are about to see several thousand new web
Title: Re: Guidance needed on well known ports
Dns is essential already.
Firewalls can cope
-Original Message-
From: Joe Touch [mailto:[EMAIL PROTECTED]]
Sent: Sun Mar 19 21:02:42 2006
To: [EMAIL PROTECTED]; ietf@ietf.org; netconf@ops.ietf.org
Subject: Re: Guidance
Title: Re: Guidance needed on well known ports
Two points here.
First, I totally agree with Phillip that closing
the registry is the right direction to head. It would be lovely if this became a
consideration in new protocol work at the IETF. I'm not sure how quickly we can
actually
Dns is essential already.
false. but even to the extent that this is true, this is a bug, not a
feature.
Firewalls can cope
but new applications can't.
Keith
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Stephane Bortzmeyer wrote:
On Sun, Mar 19, 2006 at 12:42:17PM -0800,
Ned Freed <[EMAIL PROTECTED]> wrote
a message of 35 lines which said:
The privileged port concept has some marginal utility on multiuser
systems where you don't Joe-random-user to grab some port for a well
known service
On Mon, 2006-03-20 at 12:09 +0100, Stephane Bortzmeyer wrote:
> Ned Freed <[EMAIL PROTECTED]> wrote:
> > The privileged port concept has some marginal utility on multiuser
> > systems where you don't Joe-random-user to grab some port for a well
> > known service.
>
> "had", not "has". The concept
In general I agree with Phillip but not in this case due to the risks of
circular dependencies.
Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Stephane Bortzmeyer wrote:
> On Sun, Mar 19, 2006 at 12:42:17PM -0800,
> Ned Freed <[EMAIL PROTECTED]> wrote
> a message of 35 lines which said:
>
>
>> The privileged port concept has some marginal utility on multiuser
>> systems where you don't Joe-random-user to grab some port for a well
>> kn
Ned Freed wrote:
But does that student have access to the root account on servers which
are part of the networking infrastructure? Who cares if Joe User
blows up his own config. on a PC that nobody else depends on but Joe?
But if nobody has local access to these servers, why is it is
neces
> you shouldn't allow unrestricted access to the network from unmanaged
> hosts, that's a recipe for disaster.
no, what's a disaster is to use source IP addresses or port numbers as
an indication of trustworthiness on any network that extends beyond a
single room. the notion that you can "manage"
Title: Re: Guidance needed on well known ports
I concur.
On the firewalls issue I see no problem moving from port numbers to a coherent architected alternative.
What we should fear is the emergence of numerous ad hoc schemes because nobody proposed an acceptable common architecture. I am
Ned Freed wrote:
Stephane Bortzmeyer wrote:
> On Sun, Mar 19, 2006 at 12:42:17PM -0800,
> Ned Freed <[EMAIL PROTECTED]> wrote
> a message of 35 lines which said:
>
>
>> The privileged port concept has some marginal utility on multiuser
>> systems where you don't Joe-random-user to grab some por
> - Conclusion 2: There is no reason for standards to uphold the
> distinction between <1024 and >1024 any more.
I agree that the requirement on UNIX-like systems to be root in order
to bind to ports < 1024 is, in hindsight, a Bad Idea - but mostly
because of insufficient privilege granularity.
Title: Re: Guidance needed on well known ports
The idea of requiring a privillege to access certain ports can have utility.
The idea of requiring root in a monolithic two level system like unix is a very bad one indeed. Http and smtp servers should not run as root. Forcing them to is bad o
> We have to work with what we have here, that unfortunately means original dns
> plus the srv record.
I never cease to be amazed at people who insist on taking things that
basically work fairly well and replacing them with more complex
mechanisms that are known to work more slowly and less reli
> From: Keith Moore
> Regarding SRV, it's not acceptable to expect that as a condition of
> deploying a new application, every user who wishes to run that
> application be able to write to a DNS zone. Most users do not have DNS
> zones that they can write to.
Yes. Architectur
On Mon, 20 Mar 2006 12:47:46 -0500 (EST), [EMAIL PROTECTED] (Noel
Chiappa) wrote:
> Another option, now that I think about it, though, is a TCP option which
> contained the service name - one well-known port would be the "demux port",
> and which actual application you connected to would depend on
> From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
>> Another option, now that I think about it, though, is a TCP option
>> which contained the service name - one well-known port would be the
>> "demux port", and which actual application you connected to would
>> depend on the va
> It's the concept of well-known ports that's broken, not the provision for 65K
> ports.
offhand I don't see why we need two kinds of names for services,
because that creates the need for a way to map from one constant to
another - and that mapping causes failures which seem entirely
unnecessary.
Noel Chiappa wrote:
> From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
>> Another option, now that I think about it, though, is a TCP option
>> which contained the service name - one well-known port would be the
>> "demux port", and which actual application you connected to would
Ned Freed wrote:
>
>> But does that student have access to the root account on servers which
>> are part of the networking infrastructure? Who cares if Joe User
>> blows up his own config. on a PC that nobody else depends on but Joe?
>
> But if nobody has local access to these servers, why is it
Joe Touch wrote on Monday 20 March 2006:
>
> Hallam-Baker, Phillip wrote:
> >> From: Joe Touch [mailto:[EMAIL PROTECTED]
> >
> >> And with what port would I reach this magical DNS that would
> >> provide the SRV record for the DNS itself?
> >
> > You use fixed ports for the bootstrap process a
Hallam-Baker, Phillip wrote:
The idea of requiring a privillege to access certain ports can have utility.
The idea of requiring root in a monolithic two level system like unix is
a very bad one indeed. Http and smtp servers should not run as root.
Forcing them to is bad o/s design.
Bind is c
Steven M. Bellovin wrote:
On Mon, 20 Mar 2006 12:47:46 -0500 (EST), [EMAIL PROTECTED] (Noel
Chiappa) wrote:
Another option, now that I think about it, though, is a TCP option which
contained the service name - one well-known port would be the "demux port",
and which actual application you conn
> > - Conclusion 2: There is no reason for standards to uphold the
> > distinction between <1024 and >1024 any more.
> I agree that the requirement on UNIX-like systems to be root in order
> to bind to ports < 1024 is, in hindsight, a Bad Idea - but mostly
> because of insufficient privilege granu
On Mon, 20 Mar 2006 21:20:04 +0100, Peter Dambier
<[EMAIL PROTECTED]> wrote:
> How bout the NIS portmapper on port 111 and RFC 1057
>
Most services do not use RPC. Virtually all of our TCP client-server
protocols would run unchanged after connection establishment with
TCPMUX.
-
It's been suggested to me that RFC 3639 might be
relevant to this thread.
Brian
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
On Mon, 2006-03-20 at 11:51 -0500, Keith Moore wrote:
> > you shouldn't allow unrestricted access to the network from unmanaged
> > hosts, that's a recipe for disaster.
>
> no, what's a disaster is to use source IP addresses or port numbers as
> an indication of trustworthiness on any network that
Stephane Bortzmeyer writes:
> On Sun, Mar 19, 2006 at 12:42:17PM -0800,
> Ned Freed <[EMAIL PROTECTED]> wrote
> a message of 35 lines which said:
>> The privileged port concept has some marginal utility on multiuser
>> systems where you don't Joe-random-user to grab some port for a
>> well known
Simon Leinen wrote:
Stephane Bortzmeyer writes:
On Sun, Mar 19, 2006 at 12:42:17PM -0800,
Ned Freed <[EMAIL PROTECTED]> wrote
a message of 35 lines which said:
The privileged port concept has some marginal utility on multiuser
systems where you don't Joe-random-user to grab some port for a
Noel Chiappa wrote:
> > From: Keith Moore
>
> > Regarding SRV, it's not acceptable to expect that as a condition of
> > deploying a new application, every user who wishes to run that
> > application be able to write to a DNS zone. Most users do not have DNS
> > zones that th
Steven M. Bellovin wrote:
> On Mon, 20 Mar 2006 12:47:46 -0500 (EST), [EMAIL PROTECTED] (Noel
> Chiappa) wrote:
>
>> Another option, now that I think about it, though, is a TCP option which
>> contained the service name - one well-known port would be the "demux port",
>> and which actual applica
Noel Chiappa wrote:
> > From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
>
> >> Another option, now that I think about it, though, is a TCP option
> >> which contained the service name - one well-known port would be the
> >> "demux port", and which actual application you connected
PS...
Joe Touch wrote:
>
> Noel Chiappa wrote:
>> > From: Keith Moore
>>
>> > Regarding SRV, it's not acceptable to expect that as a condition of
>> > deploying a new application, every user who wishes to run that
>> > application be able to write to a DNS zone. Most users do not
Noel Chiappa <[EMAIL PROTECTED]> wrote:
>Yes. Architecturally speaking, it's somewhat dubious that information
>which really only needs to be localized to the host (application<->port
>binding) has to be sent to the DNS.
>
>It would be easy to run a tiny little USP "binding" server that took in
>a
> From: Joe Touch <[EMAIL PROTECTED]>
>> Noel Chiappa wrote:
>>> From: Keith Moore
>>> Regarding SRV, it's not acceptable to expect that as a condition of
>>> deploying a new application, every user who wishes to run that
>>> application be able to write to a DNS zone. M
Ack on Noel's other points, but this is worth mentioning...
> But we cannot assume a hosts' DNS is available for that purpose. For
> most of us, the DNS entry isn't under our control, nor is it likely
to
> be for the forseeable future.
Keith and I concurred on that.
Noel
I have le
On Thu, 23 Mar 2006 20:56:51 -0800, Joe Touch <[EMAIL PROTECTED]> wrote:
>
>
> Since it seems like this might be useful, I'll pull a draft together on
> how to do this without 1078's extra connection, more like the
> late-binding we do in datarouter, very shortly...
>
1078 doesn't use an extra
> From: "Spencer Dawkins" <[EMAIL PROTECTED]>
> I have learned not to tell people (especially Keith and Noel)
Hey, I'm nowhere near as hypergolic on this as Keith is... :-)
> that DNS is the right answer to all questions,
Well, it works fine for what it was designed to do. Problem i
Joe Touch wrote:
> Since it seems like this might be useful, I'll pull a draft together on
> how to do this without 1078's extra connection, more like the
> late-binding we do in datarouter, very shortly...
>
This sounds like a neat extension.
Eliot
> > From: "Spencer Dawkins" <[EMAIL PROTECTED]>
>
> > I have learned not to tell people (especially Keith and Noel)
>
> Hey, I'm nowhere near as hypergolic on this as Keith is... :-)
"hypergolic"... great word! (even if a tad unflattering...)
> > that DNS is the right answer to all
Noel Chiappa wrote:
> > From: Joe Touch <[EMAIL PROTECTED]>
>
> >> Noel Chiappa wrote:
>
> >>> From: Keith Moore
...
> >> It would be easy to run a tiny little U[D]P "binding" server that
> >> took in an application name (yes, we'd have to register those, but
> >> stri
On Friday, March 24, 2006 08:23:20 AM -0500 "Steven M. Bellovin"
<[EMAIL PROTECTED]> wrote:
On Thu, 23 Mar 2006 20:56:51 -0800, Joe Touch <[EMAIL PROTECTED]> wrote:
Since it seems like this might be useful, I'll pull a draft together on
how to do this without 1078's extra connection,
On Thursday, March 23, 2006 09:40:06 PM -0800 Stuart Cheshire
<[EMAIL PROTECTED]> wrote:
Right now there are a couple of hundred application-layer protocols
implemented that work this way.
And wow is there a lot of MDNS broadcast traffic on my network.
___
Jeffrey Hutzelman wrote:
>
>
> On Friday, March 24, 2006 08:23:20 AM -0500 "Steven M. Bellovin"
> <[EMAIL PROTECTED]> wrote:
>
>> On Thu, 23 Mar 2006 20:56:51 -0800, Joe Touch <[EMAIL PROTECTED]> wrote:
>>
>>>
>>
>>>
>>> Since it seems like this might be useful, I'll pull a draft together on
>
> From: Joe Touch <[EMAIL PROTECTED]>
> TCPMUX doesn't 'handoff'. It expects that .. the service desired is
> served off of its port once opened after the initial exchange
> (in-band).
> .. The downside is that it then forces a two-step demultiplexing of
> incoming packets;
On Apr 6, 2006, at 6:37 PM, Noel Chiappa wrote:
Why can't the TCPMUX listener just bind the correct application to
the TCB
(after figuring out what the appropriate application is), and then
forget
about the connection, leaving it entirely to the application to
deal with?
All packets which
On Thu, 6 Apr 2006 21:37:49 -0400 (EDT), [EMAIL PROTECTED] (Noel
Chiappa) wrote:
> > From: Joe Touch <[EMAIL PROTECTED]>
>
> > TCPMUX doesn't 'handoff'. It expects that .. the service desired is
> > served off of its port once opened after the initial exchange
> > (in-band).
>
In thinking about this some more if we end up with a TCPMUX like
approach for TCP, how shall UDP, SCTP, et al be handled? Is it okay to
handle them differently?
Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
On Apr 6, 2006, at 6:37 PM, Noel Chiappa wrote:
> Why can't the TCPMUX listener just bind the correct application to
> the TCB
> (after figuring out what the appropriate application is), and then
> forget
> about the connection, leaving it entirely to the application to
> deal with?
> All pac
Hi, Noel (et al.),
Noel Chiappa wrote:
> > From: Joe Touch <[EMAIL PROTECTED]>
>
> > TCPMUX doesn't 'handoff'. It expects that .. the service desired is
> > served off of its port once opened after the initial exchange
> > (in-band).
> > .. The downside is that it then forces
Eliot Lear wrote:
> In thinking about this some more if we end up with a TCPMUX like
> approach for TCP, how shall UDP, SCTP, et al be handled? Is it okay to
> handle them differently?
I'm addressing this in the draft (in progress).
UDP can't support the idea; there's no option space.The alte
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, all,
In response to some discussion on this mailing list, the following ID
has been submitted. It's intended to become a TCPM work item (thus the
header) if there's sufficient interest.
PLEASE TAKE FURTHER DISCUSSION TO THAT LIST ([EMAIL PROTECTE
Refusing new registrations is what I meant by closing the registry.
This would be a disaster. It would mean that application designers
would just pick ports at random (some do this already) and there would
be no mechanism for preventing conflicts.
Regarding SRV, it's not acceptable to expec
74 matches
Mail list logo
