Stephen Sprunk <[EMAIL PROTECTED]> writes:
...
>It's already happening. There is a large (and growing) number of corporate
>networks where 802.1x is mandatory -- if you don't do it, you simply can't
>connect. I've also run into a fair number that require registering MAC
>addresses (default is
Thus spake "Stephen Kent" <[EMAIL PROTECTED]>
Boy are you in for a shock when you try to connect to an ethernet with
802.1x.
I have yet to do so. I do have the facility on my Mac, but I've never had
to turn it on.
You need to get out more.
Authentication is being built into the NIC cards.
At 17:44 20/07/2005, Hallam-Baker, Phillip wrote:
> layered defenses are a good notion, but mostly when the layers are
> under the same administrative control. all too often people forget
> that relying on the security provided by someone else is a risky
> proposition, as in your example of ISPs
Which is exactly the point.
John
- Original message -
From:Steven M. Bellovin <[EMAIL PROTECTED]>
To:Spencer Dawkins <[EMAIL PROTECTED]>
Cc:IETF Discussion
Subject:Re: Port numbers and IPv6
In message <[EMAIL PROTECTED]>, "Spencer Dawkins" writes:
>
Phil,
> layered defenses are a good notion, but mostly when the layers are
under the same administrative control. all too often people forget
that relying on the security provided by someone else is a risky
proposition, as in your example of ISPs providing ingress filtering.
I would resta
> layered defenses are a good notion, but mostly when the layers are
> under the same administrative control. all too often people forget
> that relying on the security provided by someone else is a risky
> proposition, as in your example of ISPs providing ingress filtering.
I would restate you
Phil,
...
Boy are you in for a shock when you try to connect to an ethernet with
802.1x.
I have yet to do so. I do have the facility on my Mac, but I've never
had to turn it on.
Authentication is being built into the NIC cards. At some point in the
future it will not be possible for any d
> > Most people think that carriers
> >should not be allowing people to inject bogons.
> >
> >Modern security architectures do not rely exclusively on application
> >security. If you want to connect up to a state of the art corporate
> >network the machine has to authenticate.
>
> the notion t
At 2:35 PM -0700 7/19/05, Hallam-Baker, Phillip wrote:
> Host and application security are not the job of the network.
They are the job of the network interfaces. The gateway between a
network and the internetwork should be closely controlled and guarded.
Nobody is really proposing embedding s
On 19-jul-2005, at 23:35, Hallam-Baker, Phillip wrote:
Host and application security are not the job of the network.
They are the job of the network interfaces. The gateway between a
network and the internetwork should be closely controlled and guarded.
You may want to read up on the end-to
On Tue, 19 Jul 2005 09:44:57 -0700
"Hallam-Baker, Phillip" <[EMAIL PROTECTED]> wrote:
> > I'm concerned this may usher in DNS SRV message filtering in
> > addition to protocol port filtering.
>
> Why?
>
> My post pointed out that use of SRV is essentially neutral with
> respect to protocol fil
> Host and application security are not the job of the network.
They are the job of the network interfaces. The gateway between a
network and the internetwork should be closely controlled and guarded.
Nobody is really proposing embedding security into the Internet backbone
(at least not yet). Bu
Filtering can always be done, that is the right of the network
administrator doing the filtering. That some users won't like it is
indeed an issue, but that is political and not technical.
Thinking of this as a "right" is the wrong way to think about it. A
more relevant question is whether t
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of John Kristoff
> On Fri, 15 Jul 2005 11:48:28 -0700
> "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> wrote:
>
> > There are certain limitations to the SRV prefix scheme but
> these are
> > entirely fixable. All we actually need is on
On Tue, 2005-07-19 at 09:23 -0500, John Kristoff wrote:
> On Fri, 15 Jul 2005 11:48:28 -0700
> "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> wrote:
>
> > There are certain limitations to the SRV prefix scheme but these are
> > entirely fixable. All we actually need is one new RR to allow one
> > lev
On Fri, 15 Jul 2005 11:48:28 -0700
"Hallam-Baker, Phillip" <[EMAIL PROTECTED]> wrote:
> There are certain limitations to the SRV prefix scheme but these are
> entirely fixable. All we actually need is one new RR to allow one
> level of indirection to be introduced. With that in place it is
> possi
> warning... implementing control by denying information (such
> as not telling
> the bad guy which port the secured-by-obscurity process is
> ACTUALLY running
> on) is not terribly good security. It is certainly reasonable
> control over
> people who want to be controlled ("management"), b
Hallam-Baker, Phillip wrote:
I'm saying that one source system can generate more than 64K
IMAP4 sessions. These are systems running various sorts of
proxies, so they are in effect hosting many clients at once.
True, but if we are running IPv6 then surely the solution to this
problem would be
--On fredag, juli 15, 2005 13:11:09 -0700 "Hallam-Baker, Phillip"
<[EMAIL PROTECTED]> wrote:
From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED]
On Friday, July 15, 2005 11:48:28 AM -0700 "Hallam-Baker, Phillip"
<[EMAIL PROTECTED]> wrote:
Agree, for the most part. Fixed port numbers
On 04:16 16/07/2005, Steven M. Bellovin said:
In message <[EMAIL PROTECTED]>, Masataka Ohta
writes:
>Steven M. Bellovin wrote:
>
>> Circa 1974, in a computer architecture class, I heard Fred Brooks point
>> out that *every* successful computer design eventually ran out of address
>> space. The
Which is exactly the point.
John
- Original message -
From:Steven M. Bellovin <[EMAIL PROTECTED]>
To:Spencer Dawkins <[EMAIL PROTECTED]>
Cc:IETF Discussion
Subject:Re: Port numbers and IPv6
In message <[EMAIL PROTECTED]>, "Spencer Dawkins" writes:
>
In message <[EMAIL PROTECTED]>, "Spencer Dawkins" writes:
>It would be OK if someone smart responded to this posting, but until
>they show up, http://www.ietf.org/rfc/rfc2960.txt is showing
>
>- a 16-bit source and destination port numbers in the common header
>(3.1), AND
>
>- a 16-bit stream ide
In message <[EMAIL PROTECTED]>, Masataka Ohta writes:
>Steven M. Bellovin wrote:
>
>> Circa 1974, in a computer architecture class, I heard Fred Brooks point
>> out that *every* successful computer design eventually ran out of address
>> space. The same applies to network protocols.
>
>An interes
It would be OK if someone smart responded to this posting, but until
they show up, http://www.ietf.org/rfc/rfc2960.txt is showing
- a 16-bit source and destination port numbers in the common header
(3.1), AND
- a 16-bit stream identifier (3.3.1), AND
- a 32-bit Payload Protocol Identifier (3
> On Fri, Jul 15, 2005 at 09:58:29AM -0700, Ned Freed wrote:
> > >Out of curiosity, doesn't SCTP have a bigger port space (or its
> > >moral equivalent)? If so, would that be a better option?
> >
> > I have in fact on several occasions proposed using SCTP as a transport for
> > various email servi
Steven M. Bellovin wrote:
> Circa 1974, in a computer architecture class, I heard Fred Brooks point
> out that *every* successful computer design eventually ran out of address
> space. The same applies to network protocols.
An interesting theory.
It explains why IPv6 can't be successful.
> > From: Ned Freed <[EMAIL PROTECTED]>
> >> You're saying that there are servers which have close to (or more)
> >> than 65K connections to a *single client IP address* (i.e. it may be a
> >> NAT, with a number of hosts behind it)?
> > Yes, that is exactly what I am saying
>
Thus spake "Noel Chiappa" <[EMAIL PROTECTED]>
> From: Ned Freed <[EMAIL PROTECTED]>
Let me make sure I understand you here:
> IMAP4 has the characteristic that you often have a huge number
> of incoming connections, only a few of which are active at any
> given time. Designing serv
> From: Ned Freed <[EMAIL PROTECTED]>
>> You're saying that there are servers which have close to (or more)
>> than 65K connections to a *single client IP address* (i.e. it may be a
>> NAT, with a number of hosts behind it)?
> Yes, that is exactly what I am saying
Wow. Can yo
In message <[EMAIL PROTECTED]>, Noel Chiappa writes
:
>> From: Ned Freed <[EMAIL PROTECTED]>
>
>Let me make sure I understand you here:
>
>> IMAP4 has the characteristic that you often have a huge number of
>> incoming connections, only a few of which are active at any given time.
>
> > From: Ned Freed <[EMAIL PROTECTED]>
> Let me make sure I understand you here:
> > IMAP4 has the characteristic that you often have a huge number of
> > incoming connections, only a few of which are active at any given time.
> > Designing servers to accomodate huge numbers of c
> From: Ned Freed <[EMAIL PROTECTED]>
Let me make sure I understand you here:
> IMAP4 has the characteristic that you often have a huge number of
> incoming connections, only a few of which are active at any given time.
> Designing servers to accomodate huge numbers of connections
> From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED]
> On Friday, July 15, 2005 11:48:28 AM -0700 "Hallam-Baker, Phillip"
> <[EMAIL PROTECTED]> wrote:
> Agree, for the most part. Fixed port numbers do have some
> operational
> advantages, though...
They certainly have operational advantage
On Friday, July 15, 2005 11:48:28 AM -0700 "Hallam-Baker, Phillip"
<[EMAIL PROTECTED]> wrote:
It seems to me that the underlying problem here is that fixed port
numbers is not really the right solution to the protocol identification
problem.
When this was first proposed the number of machin
On 15-jul-2005, at 21:05, Ken Raeburn wrote:
For TCP, the issue is less critical as there are already other
mechanisms that allow us to move away from well known port
numbers. One is the SRV DNS record that I mentioned yesterday, but
if you set your way back machine to 1988 you'll find RFC
On Jul 15, 2005, at 11:59, Iljitsch van Beijnum wrote:
For TCP, the issue is less critical as there are already other
mechanisms that allow us to move away from well known port numbers.
One is the SRV DNS record that I mentioned yesterday, but if you set
your way back machine to 1988 you'll fin
> I'm saying that one source system can generate more than 64K
> IMAP4 sessions. These are systems running various sorts of
> proxies, so they are in effect hosting many clients at once.
True, but if we are running IPv6 then surely the solution to this
problem would be to simply request some num
It seems to me that the underlying problem here is that fixed port
numbers is not really the right solution to the protocol identification
problem.
When this was first proposed the number of machines on the Internet was
small and there was no DNS, only the host file.
The port number allocation sc
Ned Freed wrote:
Mind you, I'm not saying that TCP needs to be redesigned ASAP to allow
for a
larger number of source ports. IMO the pain would probably outweigh the
gain.
But that doesn't mean nobody is hitting the 65536 limit imposed by
source port
numbers. They are, it causes problems, an
--On Friday, 15 July, 2005 13:54 -0400 John Day
<[EMAIL PROTECTED]> wrote:
>>
>> Does this discussion suggest that it is time to start taking a
>> look at TCPng? If not now, at some point in the future that
>> we can anticipate?
>>
>> (those are questions, not proposals, requests, or statemen
On 15-jul-2005, at 19:14, Ned Freed wrote:
>> If they are, they're probably using some kind of proxy or NAT setup,
>> for instance, having SSL sessions decrypted and then forwarded to the
>> actual server port, making all the sessions seem to come from the
>> same address.
> Exactly. SSL har
Does this discussion suggest that it is time to start taking a
look at TCPng? If not now, at some point in the future that we
can anticipate?
(those are questions, not proposals, requests, or statements of
belief)
Perhaps, but aren't we about 30 years late in getting rid of the
kludge of wel
--On Friday, 15 July, 2005 10:31 -0700 Bob Hinden
<[EMAIL PROTECTED]> wrote:
> It was for the pragmatic reason of not wanting to redesign IP
> and TCP at the same time. This would have made the overall
> IPng effort much harder. At the time, there wasn't a pressing
> need to redesign TCP. I d
On Fri, Jul 15, 2005 at 09:58:29AM -0700, Ned Freed wrote:
> >Out of curiosity, doesn't SCTP have a bigger port space (or its
> >moral equivalent)? If so, would that be a better option?
>
> I have in fact on several occasions proposed using SCTP as a transport for
> various email services. I did
On 15-jul-2005, at 19:14, Ned Freed wrote:
If they are, they're probably using some kind of proxy or NAT setup,
for instance, having SSL sessions decrypted and then forwarded to the
actual server port, making all the sessions seem to come from the
same address.
Exactly. SSL hardware is certain
David,
I was looking more for an explanation of how and why it was decided to
be out of scope.
The arguments for considering it to be in scope would have been:
- the TCP and UDP "pseudo-headers" needed to be changed anyway to
accomodate IPv6 addresses (see section 8.1 of RFC 2460);
- the
On 15-jul-2005, at 18:11, Ned Freed wrote:
> The specific case I've seen is with IMAP4. IMAP4 has the
> characteristic that you often have a huge number of incoming
> connections, only
> a few of which are active at any given time.
I know what you mean, I've seen my Mac generate more than a
Ned Freed wrote:
Mind you, I'm not saying that TCP needs to be redesigned ASAP to allow
> for a
> larger number of source ports. IMO the pain would probably outweigh the
> gain.
> But that doesn't mean nobody is hitting the 65536 limit imposed by
> source port
> numbers. They are, it causes pro
On 15-jul-2005, at 18:11, Ned Freed wrote:
Demultiplexing should happen on source and destination IP addresses
and source and destination port numbers. Assuming the server's IP
address and port number are given, that allows for a 65536 sessions
towards each possible IP address connected to the n
On 15-jul-2005, at 3:25, Ned Freed wrote:
>> It would not make much sense, between 2 hosts you can already have
>> 65536*65536 possible connections*, which should be more than
>> enough(tm) ;) I wonder if there are any hosts actually using more
>> than
>> 65536 connections at the same time.
On 15-jul-2005, at 17:36, Noel Chiappa wrote:
Demultiplexing should happen on source and destination IP
addresses and
source and destination port numbers. ... that allows for a 65536
sessions towards each possible IP address connected to the network.
It depends on what protocol you are talk
> From: Iljitsch van Beijnum <[EMAIL PROTECTED]>
>> you can only have 65536 connections to a single service on a given
>> port.
> Demultiplexing should happen on source and destination IP addresses and
> source and destination port numbers. ... that allows for a 65536
> se
--On Friday, 15 July, 2005 01:20 +0100 David Hopwood
<[EMAIL PROTECTED]> wrote:
> The arguments for considering it to be in scope would have
> been:
>
> - the TCP and UDP "pseudo-headers" needed to be changed
> anyway to
> accomodate IPv6 addresses (see section 8.1 of RFC 2460);
>
> -
On 15-jul-2005, at 3:25, Ned Freed wrote:
It would not make much sense, between 2 hosts you can already have
65536*65536 possible connections*, which should be more than
enough(tm) ;) I wonder if there are any hosts actually using more
than
65536 connections at the same time.
True enough, h
> > I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase
> > the port number space. I know it's off-topic here, but anyone know why
> > they didn't? It surely must have been considered.
> It would not make much sense, between 2 hosts you can already have
> 65536*65536 possible conn
Scott Bradner wrote:
I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase
the port number space. I know it's off-topic here, but anyone know why
they didn't? It surely must have been considered.
That was considered to be part of TCPng, and as best I recall was
explicitly out of
On Thu, 2005-07-14 at 15:54 +0100, David Hopwood wrote:
> Brian E Carpenter wrote:
> > 3. Thus I come to the key question - how high should the bar be for
> > assignments in clearly constrained namespaces? This month's poster
> > child is IPv6 option numbers, but at an even more basic level, we
> >
> I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase
> >the port number space. I know it's off-topic here, but anyone know why
> >they didn't? It surely must have been considered.
> >
>
> That was considered to be part of TCPng, and as best I recall was
> explicitly out of scope
In message <[EMAIL PROTECTED]>, David Hopwood writes:
>Brian E Carpenter wrote:
>> 3. Thus I come to the key question - how high should the bar be for
>> assignments in clearly constrained namespaces? This month's poster
>> child is IPv6 option numbers, but at an even more basic level, we
>> should
Brian E Carpenter wrote:
3. Thus I come to the key question - how high should the bar be for
assignments in clearly constrained namespaces? This month's poster
child is IPv6 option numbers, but at an even more basic level, we
should probably be more worried about port numbers, where we seem
prett
60 matches
Mail list logo
