RE: Winstar says there is no TCP/BGP vulnerability

[Christopher L. Morrow]

On Tue, 20 Apr 2004, Michel Py wrote:

> Christopher / Patrick,
>
> > Christopher L. Morrow wrote:
> > I wasn't clear and for that I'm sorry. Except in the later
> > code trains, or until the recent past (1 year or so) changing
> > the BGP MD5 auth bits required the session to be reset.
>
> Then I'm the one sorry because I never got it to work (I have not tried
> hard, I have to say); I always considered the session reset to be
> annoyance that was part of life. Dumb question: on what platforms is

its annoying until you drop customer traffic over and over on thousands of
bgp sessions... eh? doing this is not nice.

> this working? If my memory is correct nothing below the 7200; I have
> seen numerous cases of peering with platforms such as 3600.
>

if you mean md5 auth, it works from atleast 2501->12008.
if you mean resetting sessions to change keys I believe it's more code
dependent than anythingn else.

>
> > no, removing a route-map or adding a new one is painful,
> > changing it is just normal, no bounce required.
>
> Maybe I have something to learn here.
>
> - The reason I have a route-map in for a peer's BGP session is that I
> want to want to shield myself against a misconfigured peer that
> announces the entire world to me.

caution: there are several ways to do bgp configs, i am comfortable with
the way I do it daily (or how I deal with it daily). Route-maps we use to
massage routes and add/change/delete communities or the like... or for
redist from proto to proto. Not for limiting routes injected, prefix-lists
are better/more efficient for that. For pure: "Don't blow me up with
prefixes" just limit the maximum-prefix to some # over your expected
peer's list.

> - There are cases (such as the peer being a tier-2 customer of UUNET and
> me being a tier-3 customer of UUNET via a different tier-2) when the
> routes seen coming from the peer will have the same length AS-PATH than
> the ones coming from my transit, some other BGP tie-breaking criteria
> favoring the peer over the transit, leading to disaster.

use a route-map to add/remove metric or localpref? or any other settable
thing on your side? or prepend or 

> - I have equally been burned by filtering using a regexp that accepts
> only routes that appear to originate from the peer. Looks good on paper
> but when the peer configures aggregates of their own that leak in their
> BGP, becomes messy. Also been burned with peers configuring
> next-hop-self.

as-path filters are nice for bogon asn's not for limiting peer prefixes :(

> - I think I have a reasonably good understanding of route-maps; however
> I have not found so far a mechanism that could guarantee that, when
> adding/removing seqs from it, there is no transient condition that
> causes the peer wrongly announcing the entire world to you to get all
> his crud into my own table.

limit the max prefixes in cisco it's someting akin to:

neighbor  maximum-prefix 1000

> - In theory, I could add a "route-map blah deny 1" that matches
> everything, then manipulate the subsequent seqs at will, then remove the
> "route-map blah deny 1"; in this situation though, I do not see a clear
> advantage over clearing the session.
> What am I missing?
>

you could tftp in  your config change, that doesn't cause the problems...
then just wait for next update time.

>
> > wrong program, I was referring to his reset_tcp.c program,
>
> Oh, I see. I thought that you meant that saving the password somewhere
> was useless, as any side could recover it by decrypting it from the
> config. My mistake.
>

that too, but the main thing was: "once you write it down you will start a
clock to change time else it's useless"

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Peter Galbavy]

E.B. Dreger wrote:
> I don't think we're even that far along.  If I'm reading FreeBSD
> 4.9 and NetBSD 1.6.2 source correctly,
>
> /usr/src/sys/netinet/in_pcb.c

Should have stretched as far as OpenBSD then. Same file.

> tells all.

> AFAIK, sequential search is about it.  Try a port number, verify
> that the src/dist ip+port combination is available, then go on to
> the next lport if the guessed one is in use.

As far as I can see - I have never read the code before, just the commit
messages - the OpenBSD version does a circular, random search between high
and low targets.

Peter

Re: why use IPv6, was: Lazy network operators

[Kurt Erik Lindqvist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

>> Perhaps ipv6 has some dark spots that may have made upgrading not
>> attractive
>> at this time, but stopping work on it and continuing ipv4 for next 100
>> years
>> is not an option in my view - we just need to put more effort on 
>> things
>> like multihoming support for ipv6 (and its not an unsolvable problem,
>> the
>> cell phone companies are somehow able to deal with greatly increasing
>> number
>> of phones and use of cell phones and roaming works quite well, for me
>> almost everywhere at least).
>
> No, it's not an unsolvable problem. The multi6 WG will in a few weeks
> have a architectural analysis draft published, going through the
> various proposals that have been made (and they are a lot). The
> discussion that is due to follow will need all input it can get. I do
> encourage people to subscribe to the mailinglist and join that
> discussion!

As was pointed out to me, I forgot to say how to subscribe :

http://www.ietf.org/html.charters/multi6-charter.html

- - kurtis -

-BEGIN PGP SIGNATURE-
Version: PGP 8.0.3

iQA/AwUBQIYY96arNKXTPFCVEQL6QACfURBnmYcuW3AKkK9iZv5cKGGpg8wAn2r9
iqUyPzs6GC7qwj/TDr8Ku7E0
=3n0f
-END PGP SIGNATURE-

RE: Winstar says there is no TCP/BGP vulnerability

[Michel Py]

Christopher / Patrick,

> Christopher L. Morrow wrote:
> I wasn't clear and for that I'm sorry. Except in the later
> code trains, or until the recent past (1 year or so) changing
> the BGP MD5 auth bits required the session to be reset.

Then I'm the one sorry because I never got it to work (I have not tried
hard, I have to say); I always considered the session reset to be
annoyance that was part of life. Dumb question: on what platforms is
this working? If my memory is correct nothing below the 7200; I have
seen numerous cases of peering with platforms such as 3600.


> no, removing a route-map or adding a new one is painful,
> changing it is just normal, no bounce required.

Maybe I have something to learn here.

- The reason I have a route-map in for a peer's BGP session is that I
want to want to shield myself against a misconfigured peer that
announces the entire world to me.
- There are cases (such as the peer being a tier-2 customer of UUNET and
me being a tier-3 customer of UUNET via a different tier-2) when the
routes seen coming from the peer will have the same length AS-PATH than
the ones coming from my transit, some other BGP tie-breaking criteria
favoring the peer over the transit, leading to disaster.
- I have equally been burned by filtering using a regexp that accepts
only routes that appear to originate from the peer. Looks good on paper
but when the peer configures aggregates of their own that leak in their
BGP, becomes messy. Also been burned with peers configuring
next-hop-self.
- I think I have a reasonably good understanding of route-maps; however
I have not found so far a mechanism that could guarantee that, when
adding/removing seqs from it, there is no transient condition that
causes the peer wrongly announcing the entire world to you to get all
his crud into my own table.
- In theory, I could add a "route-map blah deny 1" that matches
everything, then manipulate the subsequent seqs at will, then remove the
"route-map blah deny 1"; in this situation though, I do not see a clear
advantage over clearing the session.
What am I missing?


> wrong program, I was referring to his reset_tcp.c program,

Oh, I see. I thought that you meant that saving the password somewhere
was useless, as any side could recover it by decrypting it from the
config. My mistake.


> Remember that once you put the passwd in the config it's exposed
> and the next NOC engineer that leaves will have a copy emailed to
> his home email account before he stomps out :(

You're preaching the choir on this. That being said, the point was how
MD5 could diffuse a DOS attack based on the vulnerability mentioned
earlier; the correlation between a BGP TCP RST DOS attack (especially
against a big networks such as yours) and a NOC engineer leaving is not
quite 1:1. As a matter of fact, if was a NOC engineer planning a DOS
attack against the company I work for, I would stay in just to have the
inside picture.


> Patrick W.Gilmore wrote:
> No medium or large network filters their peers on prefix.  And
> very few small networks do either.  Prefix count, maybe, but
> not individual prefixes.  There are far too many changes on far
> too many peers per day to keep up.

Exactly the same argument as using MD5 or not. When you build this as
part of the operation, yes it means time _and_ money but overall not
that much more and the bigger the network the lesser the
cost-per-router.

I do concede that people such as Rob and myself are sometimes living on
another planet, as there we operate a few networks for fun, not for
money. Nevertheless, time for pet projects is limited is as well as
day-time job ones, and if we lobby for something such as edge filtering
or bogon route-servers, it's because it can be worked out. We just have
the luxury to try without having to justify the time wasted on it.


> Not to mention far, far, far too many chances to screw up
> and get the dreaded phone call in the middle of the night.

Irrelevant:
1) Look at your watch.
2) That's what rookies are for. A NOC rookie screwing up _one_ BGP
session does not mean my phone rings. I'm sure that everyone understands
that, when I was a rookie, I _never_ screwed up a session in the middle
of the night when nobody cares :-)

Michel.

Re: why use IPv6, was: Lazy network operators

[Kurt Erik Lindqvist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


As co-chair of the multi6 WG :

On 2004-04-19, at 02.29, william(at)elan.net wrote:

> Perhaps ipv6 has some dark spots that may have made upgrading not 
> attractive
> at this time, but stopping work on it and continuing ipv4 for next 100 
> years
> is not an option in my view - we just need to put more effort on things
> like multihoming support for ipv6 (and its not an unsolvable problem, 
> the
> cell phone companies are somehow able to deal with greatly increasing 
> number
> of phones and use of cell phones and roaming works quite well, for me
> almost everywhere at least).

No, it's not an unsolvable problem. The multi6 WG will in a few weeks 
have a architectural analysis draft published, going through the 
various proposals that have been made (and they are a lot). The 
discussion that is due to follow will need all input it can get. I do 
encourage people to subscribe to the mailinglist and join that 
discussion!

Best regards,

- - kurtis -

-BEGIN PGP SIGNATURE-
Version: PGP 8.0.3

iQA/AwUBQIWIs6arNKXTPFCVEQLU/wCdFxVLrTswwUL5GQgei+sfuYTJPfwAoNzw
o1GimcbzYp72ngq16PI44Jws
=+GuV
-END PGP SIGNATURE-

Re: Lazy network operators

[Kurt Erik Lindqvist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 2004-04-18, at 01.10, Paul Jakma wrote:

> Hmmm, or rather, there just wont be any demand for IPv6 deployment,
> at least from the edges (consumers, small/medium networks). Why
> bother changing if, despite the (almost indefinitely) availability of
> sparse address space, one can not claim a tiny piece as ones' own?
> Which is IPv4's only problem, at least as seen from the edges.
>

I think you will find that this varies a lot from region to region. 
There is no drive or need for it in the US, there is slightly more 
interest in Europe. But in Asia you will find that their scaling 
problem is completely different.

I believe there will be a change. If it will be IPv6 as we know it 
today, that remains to be seen.

- - kurtis -

-BEGIN PGP SIGNATURE-
Version: PGP 8.0.3

iQA/AwUBQIJadqarNKXTPFCVEQLuBACfZ6nPHPsCoYQaH/X9OzCF87WuhaQAn3nj
FL/3cLcTZyZPIVmV0QXK/hF/
=VsLH
-END PGP SIGNATURE-

Re: Lazy network operators

[Kurt Erik Lindqvist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 2004-04-18, at 04.48, Paul Jakma wrote:

> Well, let's be honest, name one good reason why you'd want IPv6
> (given you have 4)?

That's quite an assumption there.

- - kurtis -

-BEGIN PGP SIGNATURE-
Version: PGP 8.0.3

iQA/AwUBQIJbC6arNKXTPFCVEQLxIwCdGvTFXkzN/0EcNn5yGFkS5Q/UMnAAnRpW
p2XI44odXbqI1eN9A8RqcjTw
=bbPZ
-END PGP SIGNATURE-

Alternatives to MD5 [Re: Winstar says there is no TCP/BGP vulnerability]

[Pekka Savola]

On Tue, 20 Apr 2004, Rodney Joffe wrote:
> However, perhaps someone from Winstar would care to help us all
> understand what the alternative solution is to securing the session via
> MD5? I would *love* an alternative to the 5 days of work we've just gone
> through.

1) Deploy correct ingress/egress filtering at all of your edges, and 

2) Make sure your upstreams/peers do that as well at least for the
p-t-p prefixes you use between you and them.

If you can't assume 2), you need something like GTSM or MD5 for
the BGP sessions between you and your peers/upstreams.

Note that I assume that if customers don't do ingress/egress filtering
for their p-t-p prefixes, they are shooting themselves in the foot,
and are the only people suffering from the resets.  Similar techniques 
as mentioned in the previous paragraph could be applied as well, of 
course.

That is, a thing most people seem to be forgetting that for these TCP 
packets to be processed, they must be spoofed to come from a certain 
source IP address.  If packets spoofed from that address are summarily 
discarded at appropriate places before reaching the infrastructure, 
you're pretty much safe.

-- 
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

RE: TCP/BGP vulnerability - easier than you think

[David Luyer]

> > A significant number of BGP sessions will be with a source
> > port of 11000, 11001 or 11002; BGP sessions are generally
> > quite stable and Cisco routers start the source port at
> > 11000.  So attackers could cause enough disruption just
> > targeting these three source ports.  The other thing the
> > attacker has to guess is which router established the BGP
> > session.  As to IPs which sessions exist on, they can guess
> > from traceroute each inter-provider hop.
> 
> Really?  I certainly hope an attacker tries those three ports on a
> router I know about.  Looking at a random cisco router at a random NAP
> with a significant number of peers, there are a total of zero session
> on those ports.
> 
> Wow, this attack is even easier to avoid than I thought!
> 
> Thanx for proving my point

OK, if you look at half a dozen routers from vendor C, do a
'sh ip bgp nei | in port', depending on the stability of your
network and peering sessions I would expect at least 1 in 4
will be in the 11000 to 11099 range based on some slightly wider
searching.  Granted it's not "the port is always X", but it's
also not true randomization, and most OSs have some constrained
range of ports which will be used (eg. Linux which has a sysctl
tunable "ip_local_port_range") and sequential scanning.

Admittedly, on one large looking glass, I couldn't find any peers
in the 11000 to 11099 range; however that range has been quite
popular in stable production networks I have looked at.

My initial scan covered routers with _very_ stable BGP sessions
(up for months) - for non-multihop BGP, the sessions often come
up just after router reboot and stay up for a very long time.

A few sessions had numbers nowhere near this - which would imply
that once you've killed the existing BGP sessions once, the new
session is likely to use a harder to predict port number if the router
has been up a long time.  Unless you can also extract the current
port numbers from the router somehow (remembering that most routers
use sequential allocation); there are some cases where you may be
able to trick a router into making an outbound tcp connection and
look at the source port (if rsh is enabled or there's any other way
to trigger an outbound connection).

Also if the router is a looking glass or is connected to a looking
glass you can find the port number of the looking glass session and
you can then attempt to kill the looking glass session and see what port 
number it comes back at, giving you a couple of hints as to the port
number other sessions may be at.

> And how do you track a thousand passwords?  Okay, maybe that is not too
> hard.  But how do you guarantee a thousand peers will never screw up
> and forget, lose, fat-finger, etc. a single one of them?  This one I
> would really like to know, 'cause I sure as hell can't figure it out.

The passwords are saved in your router config CVS repository.
They are not encrypted, they are only encoded or stored in plain
text, so you can recover (decode) them if you need to move between
platforms.  You can also store them in your tracking system or
wherever else you store such data.  Or in the worst case you can
negotiate new passwords if you've lost your records.

And if you're thinking of customer passwords, worried about saving
passwords in your config repository and don't want to augment your
customer information systems with the data -- then you can make
some kind of non-reversible hash (eg. md5-based) to generate the
passwords based on the two BGP peers' IP addresses.

> > [*] in any reasonable implementation.  it is possible some old
> > implementation does this wrong, though.
> 
> Guess IOS counts as both old and unreasonable.  I buy that.
> 
> Again with the agreement!  Well, three out of four ain't bad. :)

If this is true, and more CPU is used in checking a MD5 signature
than in checking the ports and sequence number, then I'm sure it
won't be long until someone logs a bug with Cisco to change the
situation.

David.

Re: Xspedius / E.Spire as wellRe: Winstar says there is no TCP/BGP vulnerability

[babylon]

Hmm... Well as Randy pointed out... I did not have the correct tools when 
I configured this on all of Sprintlink in 1996, and I completed it in one
nights maintenance window. All it takes is normal planning. It is not a
pain in the ass... all of the problems you may have faced were corrected
my Mr. Heffernan at Cisco when I ran into them first in 1996. I would
say the rest is laziness or the belief it was unnecessary.

jon

> right. All the whining about how we all should have deployed MD5 years ago
> proves one very important point, it hasn't been deployed widely because it
> is a ROYAL PAIN IN THE [EMAIL PROTECTED]&*. I haven't actually run the tests myself,
> 

Re: Winstar says there is no TCP/BGP vulnerability

[Patrick W . Gilmore]

On Apr 21, 2004, at 12:51 AM, Michel Py wrote:

b) A specific-to-the-peer route-map to filter the routes I receive from
the peer to the peer's blocks, as agreed in the beer drinking meeting
^H^H^H^H BLPA. This route map is not entirely specific, as I also put 
in
stuff such as deny RFC1918 routes ;-)
No medium or large network filters their peers on prefix.  And very few 
small networks do either.  Prefix count, maybe, but not individual 
prefixes.  There are far too many changes on far too many peers per day 
to keep up.  Not to mention far, far, far too many chances to screw up 
and get the dreaded phone call in the middle of the night.


Now, the dumb question:
Given:
1) The context above especially item b
Since item b) is no longer given, your question is invalid.


2) Christopher Morrow's comments below
Explain me what having or not having the MD5 password changes. Either
you're small and/or stupid and do it manually, or you have an automated
system that does it for you.

Christopher L. Morrow wrote:
there is the issue of changing the keys during operations
without impacting the network, eh? Having to bounce every
bgp session in your network can be pretty darned painful...
if you change the key(s) of course.
See above: Changing the route-map is equally painful.
See above: Networks do not filter as per item b).  Since that is 
"equally painful", I guess they should not change the route-map or MD5 
password either.  Hr, someone is again proving my point for me


If you don't you might as well not have keys, since adding
the 3 lines of C code required to Paul Watsons' program
making it do the hashing certainly won't be a big deal, eh?
I'm weak with C. Besides adding "neighbor x.x.x.x password 7 " below
"enable-password 7 " for each peer (which requires recompiling, how
annoying) would you care sharing the 3 said lines for the code below 
:-)
I think you miss the point here.

Or maybe I did.  It's late, instead of possibly misinterpreting another 
person's post, I'll let Chris explain it himself.

--
TTFN,
patrick

Re: Massive stupidity (Was: Re: TCP vulnerability)

[Kurt Erik Lindqvist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 2004-04-20, at 23.09, Richard A Steenbergen wrote:

>  but the massive amount of confusion,
> rumor, and worry which the major router vendors (Cisco and Juniper)
> created by essentially rediscovering the god damn spec and then telling
> only their major customers about so that only rumors could filter down 
> to
> the rest of the industry is absolutely pathetic. If you have a support
> contract and were not told about this "attack" (if you could call it 
> that)
> or were blatantly misinformed as many people seem to have been, you 
> should
> demand to know why you didn't receive better treatment.

this was to the best of my knowledge not handled by Cisco and Juniper 
and also to the best of my knowledge they did not pre-warn any 
customer. But I might be mistaken.

- - kurtis -

-BEGIN PGP SIGNATURE-
Version: PGP 8.0.3

iQA/AwUBQIYJ1qarNKXTPFCVEQIFVACfdbhaVD3lHDhKZvtHUd1ugUUFeToAn1Us
FpSX+E9RmmezY4liEiInxYCR
=hEOv
-END PGP SIGNATURE-

RE: Winstar says there is no TCP/BGP vulnerability

[Christopher L. Morrow]

On Tue, 20 Apr 2004, Michel Py wrote:

> Now, the dumb question:
> Given:
> 1) The context above especially item b
> 2) Christopher Morrow's comments below
> Explain me what having or not having the MD5 password changes. Either
> you're small and/or stupid and do it manually, or you have an automated
> system that does it for you.

I wasn't clear and for that I'm sorry. Except in the later code trains, or
until the recent past (1 year or so) changing the BGP MD5 auth bits
required the session to be reset. Changing your route-map or access-list
or prefix-list will not reset the session... Having to reset sessions to
change 'vital' security parameters seems like a large problem.

So, given this operational headache MD5 auth just doesn't get rolled out,
or when it does, sessions never get their auth info changed. (in practice)
Atleast in more current code and now in 12.0.SOMETHING-S code you can both
change on the fly and have 'fall back' key capability. This makes this
pain less and makes operational pain with md5 less as well.

>
>
> > Christopher L. Morrow wrote:
> > there is the issue of changing the keys during operations
> > without impacting the network, eh? Having to bounce every
> > bgp session in your network can be pretty darned painful...
> > if you change the key(s) of course.
>
> See above: Changing the route-map is equally painful.
>

no, removing a route-map or adding a new one is painful, changing it is
just normal, no bounce required.

> > If you don't you might as well not have keys, since adding
> > the 3 lines of C code required to Paul Watsons' program
> > making it do the hashing certainly won't be a big deal, eh?
>
> I'm weak with C. Besides adding "neighbor x.x.x.x password 7 " below

me too, I'm a chemical engineer... :)

> "enable-password 7 " for each peer (which requires recompiling, how
> annoying) would you care sharing the 3 said lines for the code below :-)
>

wrong program, I was referring to his reset_tcp.c program, which would
only need:
1) your key as a input in argv
2) the requisite option added to the tcp header
3) the hash function applied to the resultant packet before
generation and output.

so, 3 pseudo-code lines... my point here is that the MD5 auth is only as
good as your passwd security, and change procedures. Remember that once
you put the passwd in the config it's exposed and the next NOC engineer
that leaves will have a copy emailed to his home email account before he
stomps out :(

Re: Winstar says there is no TCP/BGP vulnerability

[Rodney Joffe]

Joe,

Joe Rhett wrote:
> 
> I've left your entire message below so that one can see I've removed
> nothing.  Winstar has made NONE of the statements you are interpreting from
> their response.  They have simply stated that they don't support it at this
> moment in time.  I'll grant you that they could have answered "when" or
> "why" or "what else".  But they certainly didn't say anything you are
> suggesting that they have said.

The only network engineer who may NOT have been aware of the building
BGP vulnerability issue over the last week has to be the engineer who is
currently on his annual vacation in Mauritius, and who refuses to take
his Blackberry, Palm, or Satellite phone with him.

And given the frantic activity by every single major backbone to protect
their connections by DEMANDING MD5 authentication, I think it is
disingenuous to suggest that a network like Winstar is merely saying
"They don't support it at this time" because they haven't gotten round
to it. They have to also be saying:

1) We don't believe there is any threat.
2) We don't want to set up MD5 because it is against our religion
3) We don't know *how* to set it up.
4) Our machines can't support setting up MD5.
5) Our network cannot support the outage as we bounce the session.
6) Our customers cannot accept the outage as we bounce the session
7) We're just thinking about it, and our planning process is taking a
long time.
8) We don't care about customer needs, even customers who spend $200k a
year with us.
9) We don't care about customers
and I am sure there are a slew of other possibilities.

But for a network provider to respond to a request from a large customer
who asks that their peering session be authenticated by just responding
"We don't use MD5 for peering currently" shows un unusually ballsy
attitude. There is more to it. Absent a specific, I chose to assume the
first option. I'm happy to hear Winstar's alternative. 

I'm also interested in hearing if Winstar provided the same response to
the other big backbones? MCI, Sprint, AT&T, Level3, Verio, etc. It seems
to me that causing resets regularly forces the router to churn, dealing
with inserting routes into FIB, deleting routes from FIB,  recalculate
FIB. Wash, rinse, repeat. Miscreants have no interest in a single reset.
And it won't take 200 seconds after the first reset. You probably won't
get out of the first window.

I stand by my first comment - Winstar doesn't believe that this is
enough of a threat to even craft a professional response.

> 
> Should we ever meet, I'll remember to never turn down a beer.
> You might think I'm pro-prohibition or something...

No. If you were standing in the way of a scheduled trainwreck, and I
tossed you a schedule, a map, fed you live video of the approaching
train, and tossed you a lifeline, and you said you didn't believe there
was any danger I'd have to wonder.

> 
> On Tue, Apr 20, 2004 at 01:44:44PM -0700, Rodney Joffe wrote:
> >
> > Perhaps we are all making too much of this...
> >
> > It appears that Winstar feels that there is no need for MD5
> > authentication of peering sessions. One of our customers has just had
> > the following response from Winstar following a request to implement MD5
> > on their OC3 connection to Winstar. My first suggestion is to locate
> > another upstream provider (they have 3 already).
> >
> > However, perhaps someone from Winstar would care to help us all
> > understand what the alternative solution is to securing the session via
> > MD5? I would *love* an alternative to the 5 days of work we've just gone
> > through.
> >
> > > -Original Message-
> > > From: Justin Crawford - NMCW Engineer [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, April 20, 2004 11:13 AM
> > > To: xx
> > > Subject: Re: *SPAM* MD5 implimentation on BGP
> > >
> > > x,
> > >
> > > Winstar does not currently run MD5 authentication with our peers.
> > >
> > > Thanks
> > >
> > > Justin
> > >
> > > Thank you for your time and business
> > >
> > > Justin Crawford
> > > Winstar NMCW
> > > Ph: 206-xxx.
> >
> > Has anyone else run in to this with Winstar?
> >
> > --
> > Rodney Joffe
> > CenterGate Research Group, LLC.
> > http://www.centergate.com
> > "Technology so advanced, even we don't understand it!"(SM)
> 
> --
> Joe Rhett  Chief Geek
> [EMAIL PROTECTED]  Isite Services, Inc.

-- 
Rodney Joffe
CenterGate Research Group, LLC.
http://www.centergate.com
"Technology so advanced, even we don't understand it!"(R)

Re: Winstar says there is no TCP/BGP vulnerability

[Patrick W . Gilmore]

On Apr 21, 2004, at 12:11 AM, Rob Thomas wrote:

] Actual data: Over the past three plus years an organization with on 
the
] order of a dozen MD5-ized BGP sessions has has multiple down sessions
] due to, for instance, a peer doing standard (for them) password
] rotation and forgetting to inform the organization.

Yep, that's a problem - a PROCESS problem.  The definition of insanity
is repeating the same behavior over and over and expecting a different
result.  ;)
So you think continuing to use MD5 and not see down sessions due to 
lost passwords would be insane?

Also, PROCESSES are part of running a network.  As any large network 
provider, they will tell you the process of keeping the network up 
costs more than the fiber the network runs on.  In fact, operational 
support and complexity is one of the main reasons large networks give 
for not peering with other networks.


Saying that we've not seen any RST attacks may be correct, but it's
not a predictor of future activity.  No one can do more than model
what may come next.  Prior to February 2001 no one had seen massive
DDoS either.  Anyone still think DDoS isn't a problem?
Of course not.  But I also see a reason to do DDoS attacks.

Rob, you are the biggest proponent of the underground economy I have 
ever seen.  Tell me why a miscreant would waste his time - at *least* 
30 minutes (lowest report I've seen, and possibly hours or days) - 
trying to reset a BGP session when with less effort they could take 
down an entire router?

I can come up with reasons, but they are pretty few and far between, 
especially compared with reasons to take out a whole router.

Can you tell me why these miscreants - people who are lazy just like us 
- would not rather packet the router off the 'Net than do this slow, 
possibly useless exercise?


We manage well over 150 peering sessions with MD5 passwords in place.
This includes bogon peering, route-server peering, and production
traffic peering.  This has grown over the past three years.  The total
number of MD5-related outages:  zero.
In other words, your mileage may vary.  :)
Awesome news.   And your milage *will* vary, since you cannot control 
separate organizations.

--
TTFN,
patrick

Re: Winstar says there is no TCP/BGP vulnerability

[Joe Rhett]

That isn't the point of my post.  Whether or not you think X is a good
idea, having someone technical say "we don't support X currently" does not
mean a host of other things like "we think X is a bad idea" or any other
nonsense like that.

On Tue, Apr 20, 2004 at 08:29:34PM -0700, Michel Py wrote:
> Please forgive me if I'm naive and/or ask a stupid question, but is
> there any reason (besides your platform not supporting it) _not_ to MD5
> your BGP sessions? Geez, on my _home_ router all my v4 BGP sessions are
> MD5ed (v6 not there yet).
> 
> Michel.
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Joe Rhett
> Sent: Tuesday, April 20, 2004 8:07 PM
> To: Rodney Joffe
> Cc: NANOG
> Subject: Re: Winstar says there is no TCP/BGP vulnerability
> 
> 
> I've left your entire message below so that one can see I've removed
> nothing.  Winstar has made NONE of the statements you are interpreting
> from
> their response.  They have simply stated that they don't support it at
> this
> moment in time.  I'll grant you that they could have answered "when" or
> "why" or "what else".  But they certainly didn't say anything you are 
> suggesting that they have said.
> 
> Should we ever meet, I'll remember to never turn down a beer.
> You might think I'm pro-prohibition or something...
> 
> On Tue, Apr 20, 2004 at 01:44:44PM -0700, Rodney Joffe wrote:
> > 
> > Perhaps we are all making too much of this...
> > 
> > It appears that Winstar feels that there is no need for MD5
> > authentication of peering sessions. One of our customers has just had
> > the following response from Winstar following a request to implement
> MD5
> > on their OC3 connection to Winstar. My first suggestion is to locate
> > another upstream provider (they have 3 already).
> > 
> > However, perhaps someone from Winstar would care to help us all
> > understand what the alternative solution is to securing the session
> via
> > MD5? I would *love* an alternative to the 5 days of work we've just
> gone
> > through.
> > 
> > > -Original Message-
> > > From: Justin Crawford - NMCW Engineer [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, April 20, 2004 11:13 AM
> > > To: xx
> > > Subject: Re: *SPAM* MD5 implimentation on BGP
> > > 
> > > x,
> > > 
> > > Winstar does not currently run MD5 authentication with our peers.
> > > 
> > > Thanks
> > > 
> > > Justin
> > > 
> > > Thank you for your time and business
> > > 
> > > Justin Crawford
> > > Winstar NMCW
> > > Ph: 206-xxx.
> > 
> > Has anyone else run in to this with Winstar?
> > 
> > -- 
> > Rodney Joffe
> > CenterGate Research Group, LLC.
> > http://www.centergate.com
> > "Technology so advanced, even we don't understand it!"(SM)
> 
> -- 
> Joe Rhett  Chief
> Geek
> [EMAIL PROTECTED]  Isite Services,
> Inc.

-- 
Joe Rhett  Chief Geek
[EMAIL PROTECTED]  Isite Services, Inc.

Re: TCP RST attack (the cause of all that MD5-o-rama)

[E.B. Dreger]

PWG> Date: Tue, 20 Apr 2004 19:24:37 -0400
PWG> From: Patrick W. Gilmore


PWG> Speaking of good randomization, does anyone have a good
PWG> algorithm to randomize ephemeral ports?  Obviously "pick
PWG> random number, see if port is open, if it is, repeat" is not
PWG> a good idea, especially on a busy host with lots of
PWG> connections.  I was thinking something like "pick 65K
PWG> random numbers on boot, store in file/array, cycle through".

I don't think we're even that far along.  If I'm reading FreeBSD
4.9 and NetBSD 1.6.2 source correctly,

/usr/src/sys/netinet/in_pcb.c

tells all.


PWG> Does anyone know if / how modern OSes randomize ephemeral
PWG> ports?

AFAIK, sequential search is about it.  Try a port number, verify
that the src/dist ip+port combination is available, then go on to
the next lport if the guessed one is in use.


Eddy
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita

RE: Winstar says there is no TCP/BGP vulnerability

[Michel Py]

Patrick / Christopher,

>> Michel Py wrote:
>> Please forgive me if I'm naive and/or ask a stupid question,
>> but is there any reason (besides your platform not supporting
>> it) _not_ to MD5 your BGP sessions? Geez, on my _home_ router
>> all my v4 BGP sessions are MD5ed (v6 not there yet).

> Patrick W.Gilmore wrote:
> There is serious operational overhead in maintaining sync'ed
> passwords between separate organizations.  IOW: Eventually
> someone will screw up and lose the password.
> [large snip]

Thanks for the insight. I have an even dumber question:

Context: set aside the MD5, the way I configure BGP sessions/traffic
from/to peers is as follows:

a) A generic (configured in the peer-group) route-map to filter the
routes I announce to the peer to be only my blocks.

b) A specific-to-the-peer route-map to filter the routes I receive from
the peer to the peer's blocks, as agreed in the beer drinking meeting
^H^H^H^H BLPA. This route map is not entirely specific, as I also put in
stuff such as deny RFC1918 routes ;-)

c) A generic access-list filtering ingress traffic from the peer to me
to allow only traffic which DA is mine. (cracks me up if the peer sets a
default to me :-)

d) A generic access-list filtering egress traffic from me to the peer to
allow only traffic which SA is mine.

Now, the dumb question:
Given:
1) The context above especially item b
2) Christopher Morrow's comments below
Explain me what having or not having the MD5 password changes. Either
you're small and/or stupid and do it manually, or you have an automated
system that does it for you.


> Christopher L. Morrow wrote:
> there is the issue of changing the keys during operations
> without impacting the network, eh? Having to bounce every
> bgp session in your network can be pretty darned painful...
> if you change the key(s) of course.

See above: Changing the route-map is equally painful.

> If you don't you might as well not have keys, since adding
> the 3 lines of C code required to Paul Watsons' program
> making it do the hashing certainly won't be a big deal, eh?

I'm weak with C. Besides adding "neighbor x.x.x.x password 7 " below
"enable-password 7 " for each peer (which requires recompiling, how
annoying) would you care sharing the 3 said lines for the code below :-)

Michel.


#include 
#include 

char xlat[] = {
0x64, 0x73, 0x66, 0x64, 0x3b, 0x6b, 0x66, 0x6f,
0x41, 0x2c, 0x2e, 0x69, 0x79, 0x65, 0x77, 0x72,
0x6b, 0x6c, 0x64, 0x4a, 0x4b, 0x44
};

char pw_str1[] = "password 7 ";
char pw_str2[] = "enable-password 7 ";

char *pname;

cdecrypt(enc_pw, dec_pw)
char *enc_pw;
char *dec_pw;
{
unsigned int seed, i, val = 0;

if(strlen(enc_pw) & 1)
return(-1);

seed = (enc_pw[0] - '0') * 10 + enc_pw[1] - '0';

if (seed > 15 || !isdigit(enc_pw[0]) || !isdigit(enc_pw[1]))
return(-1);

for (i = 2 ; i <= strlen(enc_pw); i++) {
if(i !=2 && !(i & 1)) {
dec_pw[i / 2 - 2] = val ^ xlat[seed++];
val = 0;
}

val *= 16;

if(isdigit(enc_pw[i] = toupper(enc_pw[i]))) {
val += enc_pw[i] - '0';
continue;
}

if(enc_pw[i] >= 'A' && enc_pw[i] <= 'F') {
val += enc_pw[i] - 'A' + 10;
continue;
}

if(strlen(enc_pw) != i)
return(-1);
}   

dec_pw[++i / 2] = 0;

return(0);
}

usage()
{
fprintf(stdout, "Usage: %s -p \n", pname);
fprintf(stdout, "   %s  \n", pname);

return(0);
}

main(argc,argv)
int argc;
char **argv;

{
FILE *in = stdin, *out = stdout;
char line[257];
char passwd[65];
unsigned int i, pw_pos;

pname = argv[0];

if(argc > 1)
{
if(argc > 3) {
usage();
exit(1);
}

if(argv[1][0] == '-')
{
switch(argv[1][1]) {
case 'h':
usage();
break;

case 'p':
if(cdecrypt(argv[2], passwd)) {
fprintf(stderr, "Error.\n");
exit(1);
}
fprintf(stdout, "password: %s\n",
passwd);
break;

default:
fprintf(stderr, "%s: unknow option.",
pname);
}

return(0);

RE: Winstar says there is no TCP/BGP vulnerability

[Christopher L. Morrow]

On Tue, 20 Apr 2004, Michel Py wrote:

>
> Please forgive me if I'm naive and/or ask a stupid question, but is
> there any reason (besides your platform not supporting it) _not_ to MD5
> your BGP sessions? Geez, on my _home_ router all my v4 BGP sessions are
> MD5ed (v6 not there yet).
>
> Michel.

there is the issue of changing the keys during operations without
impacting the network, eh? Having to bounce every bgp session in your
network can be pretty darned painful... if you change the key(s) of
course. If you don't you might as well not have keys, since adding the
3 lines of C code required to Paul Watsons' program making it do
the hashing certainly won't be a big deal, eh?

RE: Winstar says there is no TCP/BGP vulnerability

[Michel Py]

> Rob Thomas wrote:
> We manage well over 150 peering sessions with MD5 passwords
> in place. This includes bogon peering, route-server peering,
> and production traffic peering.  This has grown over the past
> three years.  The total number of MD5-related outages:  zero.

I have to complain about this: MD5 peering with Team Cymru is boring. I
have has some scheduled (and announced prior-to-happening) maintenance
outages, but if one has (I do) redundant peering with them, it never
goes down and nothing interesting ever happens.

Rob, screw up the config from time to time, would you? If nothing ever
goes down, half of the readers will be out of a job soon.

Michel.

Re: TCP/BGP vulnerability - easier than you think

[Joe Abley]

On 20 Apr 2004, at 23:40, Patrick W.Gilmore wrote:

And how do you track a thousand passwords?  Okay, maybe that is not 
too hard.
Right :-)

But how do you guarantee a thousand peers will never screw up and 
forget, lose, fat-finger, etc. a single one of them?  This one I would 
really like to know, 'cause I sure as hell can't figure it out.
If someone forgets a password, you talk on the phone and agree a new 
one, and apply it to both sides. It's the same kind of procedure that I 
guess we would follow if peers spontaneously forgot our IP addresses or 
AS numbers. Or you could just tell them what their password is, since 
you have all the details in your peering database (see above).

(If the reaction to this is "hey, not everybody has a peering database 
you know" then people should let me know; we can tidy up and publish 
the postgres schema that we use if there is interest).

Joe

Re: TCP/BGP vulnerability - easier than you think

[Rob Thomas]

Hi, Patrick.

] Really?  I certainly hope an attacker tries those three ports on a
] router I know about.  Looking at a random cisco router at a random NAP
] with a significant number of peers, there are a total of zero session
] on those ports.

The ephemeral ports are used for active opens, not passive opens.  In
other words there won't be a listener bound on the ephemeral ports.
Try nmap'ing the source port you use to SSH to TCP 22 on a remote
server, for example - same negative result.  That doesn't mean it
isn't using the "closed" port as a source port.  :)

Or did I misunderstand the post?  I'm low on coffee tonight.  :)

Thanks,
Rob.
-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

Re: Winstar says there is no TCP/BGP vulnerability

[Rob Thomas]

Hi, NANOGers.

] Actual data: Over the past three plus years an organization with on the
] order of a dozen MD5-ized BGP sessions has has multiple down sessions
] due to, for instance, a peer doing standard (for them) password
] rotation and forgetting to inform the organization.

Yep, that's a problem - a PROCESS problem.  The definition of insanity
is repeating the same behavior over and over and expecting a different
result.  ;)

Saying that we've not seen any RST attacks may be correct, but it's
not a predictor of future activity.  No one can do more than model
what may come next.  Prior to February 2001 no one had seen massive
DDoS either.  Anyone still think DDoS isn't a problem?

We manage well over 150 peering sessions with MD5 passwords in place.
This includes bogon peering, route-server peering, and production
traffic peering.  This has grown over the past three years.  The total
number of MD5-related outages:  zero.

In other words, your mileage may vary.  :)

Test any feature.  Think about how to manage that feature, both in the
deployment stage and in steady-state.  I don't advocate the use of any
feature, be it MD5, MPLS, et al. without careful consideration of the
support ramifications of it.

Thanks,
Rob.
-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

Re: TCP/BGP vulnerability - easier than you think

[Patrick W . Gilmore]

On Apr 20, 2004, at 11:09 PM, David Luyer wrote:

You missed the "(assuming the attacker can accurately guess both
ports)" part.
This is BY NO MEANS a given.  In fact, it is pretty much guaranteed to
not be a given on any router which has not recently been rebooted.  
(Or
at least that the attacker doesn't know has been recently rebooted. :)
A significant number of BGP sessions will be with a source
port of 11000, 11001 or 11002; BGP sessions are generally
quite stable and Cisco routers start the source port at
11000.  So attackers could cause enough disruption just
targeting these three source ports.  The other thing the
attacker has to guess is which router established the BGP
session.  As to IPs which sessions exist on, they can guess
from traceroute each inter-provider hop.
Really?  I certainly hope an attacker tries those three ports on a 
router I know about.  Looking at a random cisco router at a random NAP 
with a significant number of peers, there are a total of zero session 
on those ports.

Wow, this attack is even easier to avoid than I thought!

Thanx for proving my point


Answering another poster's concern about DoS risk...
TCP MD5 is not a significant DoS risk as you only MD5 once the
source, destination, sequence, etc are valid - ie. you only MD5
a packet which would already have broken your BGP session! [*]
Interestingly, cisco confirmed to me the sequence number was not 
checked until after the MD5 signature was checked.

Again, thanx for proving my point.  You really must post more often.


Worse than breaking the session, I'm told by people who have
tested in labs that they could typically break BGP sessions
in under half an hour, which then caused flapping and dampening
of the routes if the attack was repeated.  So the risk is not
just the occasional BGP session flap, it's a frequent enough
flap that your routes can be dampened.
I would love to see these results, as I am interested in the 
methodolofy.  For instance, did they turn on a lab router, configure 
some new BGP sessions, then attack it?  Notice that both Richard and I 
repeatedly say "for a router which has not recently been rebooted".  Of 
*course* it will be easy when you set things up like that.

Even granting the results, flapping a BGP session once per half hour is 
far from the worst thing 10 Kpps can do on the Internet.  In fact, it 
is probably the *least* damaging thing I have heard miscreants do with 
10 Kpss.


So, you're best to implement TCP MD5 on your BGP sessions.
Many people also report taking entire routers down in far less than 30 
minutes with 10 Kpps of MD5 signed packets if MD5 is turned on.  So I 
am not sure why this is better - sorry, best - than flapping a session 
every half hour.

Guess we did not agree on this one.  I really think flapping a session 
every 30 minutes (if it really only takes that long) is not better than 
killing a whole router in far less time.


With an up to date IOS, if you both implement the password
within about a second, the BGP session doesn't even flap to
implement the password.  Older IOS (12.1) resets the BGP
session as a password is set.  Other vendors vary.
And how do you track a thousand passwords?  Okay, maybe that is not too 
hard.  But how do you guarantee a thousand peers will never screw up 
and forget, lose, fat-finger, etc. a single one of them?  This one I 
would really like to know, 'cause I sure as hell can't figure it out.


[*] in any reasonable implementation.  it is possible some old
implementation does this wrong, though.
Guess IOS counts as both old and unreasonable.  I buy that.

Again with the agreement!  Well, three out of four ain't bad. :)

--
TTFN
patrick

Re: Winstar says there is no TCP/BGP vulnerability

[Patrick W . Gilmore]

On Apr 20, 2004, at 11:29 PM, Michel Py wrote:

Please forgive me if I'm naive and/or ask a stupid question, but is
there any reason (besides your platform not supporting it) _not_ to MD5
your BGP sessions? Geez, on my _home_ router all my v4 BGP sessions are
MD5ed (v6 not there yet).
There is serious operational overhead in maintaining sync'ed passwords 
between separate organizations.  IOW: Eventually someone will screw up 
and lose the password.  When they do, the session goes down, and 
probably for far longer than if some miscreant tries to RST it via the 
"vulnerability".

Actual data: Over the past three plus years an organization with on the 
order of a dozen MD5-ized BGP sessions has has multiple down sessions 
due to, for instance, a peer doing standard (for them) password 
rotation and forgetting to inform the organization.  Each time incurred 
a minimum of several hours downtime, once stretching into several days 
as the peer could not figure out what was wrong and get the right 
person with the password to give it to the organization.

Over the past three plus years with over 1000 non-MD5-ized BGP 
sessions, the same organization experienced exactly *ZERO* seconds of 
downtime identified as due to RST-style attacks.  And certainly no 
prolonged outages due to it.

Add to that the additional CPU overhead some people have reported, 
making it easier to packet the router to its knees, and MD5 looks like 
a cure worse than the disease.

All that said, it is your router, your peers, your decision.  I would 
never dream of telling anyone who wanted MD5 to not do it.  I just 
don't understand people who want to do it.  Especially when they could 
be doing things like filtering at the leaf nodes and forcing their 
vendors to support the TTL hack.

But that's me.

--
TTFN,
patrick

RE: Backbone IP network Economics - peering and transit

[Michel Py]

> Stephen J. Wilcox wrote:
> I assume Vijay meant the cost of a port for private
> peering, in which case if you private with all your
> peers and you have a lot of small peers thats going
> to be a lot of cost for a few kbps of traffic

I'm having trouble parsing this. You connect your FE or GE port to an
ISL/802.11q trunk to the colo's/IX switch. Then either a)everyone is in
the same broadcast domain (dumb but no config), or there's a VLAN on
that trunk from/to you to your peer(s). Save for the colo's/IX
administrative/xconnect fee, where's the "lot of cost"?

Michel.

RE: Winstar says there is no TCP/BGP vulnerability

[Michel Py]

Please forgive me if I'm naive and/or ask a stupid question, but is
there any reason (besides your platform not supporting it) _not_ to MD5
your BGP sessions? Geez, on my _home_ router all my v4 BGP sessions are
MD5ed (v6 not there yet).

Michel.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Joe Rhett
Sent: Tuesday, April 20, 2004 8:07 PM
To: Rodney Joffe
Cc: NANOG
Subject: Re: Winstar says there is no TCP/BGP vulnerability


I've left your entire message below so that one can see I've removed
nothing.  Winstar has made NONE of the statements you are interpreting
from
their response.  They have simply stated that they don't support it at
this
moment in time.  I'll grant you that they could have answered "when" or
"why" or "what else".  But they certainly didn't say anything you are 
suggesting that they have said.

Should we ever meet, I'll remember to never turn down a beer.
You might think I'm pro-prohibition or something...

On Tue, Apr 20, 2004 at 01:44:44PM -0700, Rodney Joffe wrote:
> 
> Perhaps we are all making too much of this...
> 
> It appears that Winstar feels that there is no need for MD5
> authentication of peering sessions. One of our customers has just had
> the following response from Winstar following a request to implement
MD5
> on their OC3 connection to Winstar. My first suggestion is to locate
> another upstream provider (they have 3 already).
> 
> However, perhaps someone from Winstar would care to help us all
> understand what the alternative solution is to securing the session
via
> MD5? I would *love* an alternative to the 5 days of work we've just
gone
> through.
> 
> > -Original Message-
> > From: Justin Crawford - NMCW Engineer [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, April 20, 2004 11:13 AM
> > To: xx
> > Subject: Re: *SPAM* MD5 implimentation on BGP
> > 
> > x,
> > 
> > Winstar does not currently run MD5 authentication with our peers.
> > 
> > Thanks
> > 
> > Justin
> > 
> > Thank you for your time and business
> > 
> > Justin Crawford
> > Winstar NMCW
> > Ph: 206-xxx.
> 
> Has anyone else run in to this with Winstar?
> 
> -- 
> Rodney Joffe
> CenterGate Research Group, LLC.
> http://www.centergate.com
> "Technology so advanced, even we don't understand it!"(SM)

-- 
Joe Rhett  Chief
Geek
[EMAIL PROTECTED]  Isite Services,
Inc.

TCP/BGP vulnerability - easier than you think

[David Luyer]

> You missed the "(assuming the attacker can accurately guess both
> ports)" part.
> 
> This is BY NO MEANS a given.  In fact, it is pretty much guaranteed to
> not be a given on any router which has not recently been rebooted.  (Or
> at least that the attacker doesn't know has been recently rebooted. :)

A significant number of BGP sessions will be with a source
port of 11000, 11001 or 11002; BGP sessions are generally
quite stable and Cisco routers start the source port at
11000.  So attackers could cause enough disruption just
targeting these three source ports.  The other thing the
attacker has to guess is which router established the BGP
session.  As to IPs which sessions exist on, they can guess
from traceroute each inter-provider hop.

Answering another poster's concern about DoS risk...
TCP MD5 is not a significant DoS risk as you only MD5 once the
source, destination, sequence, etc are valid - ie. you only MD5
a packet which would already have broken your BGP session! [*]

Worse than breaking the session, I'm told by people who have
tested in labs that they could typically break BGP sessions
in under half an hour, which then caused flapping and dampening
of the routes if the attack was repeated.  So the risk is not
just the occasional BGP session flap, it's a frequent enough
flap that your routes can be dampened.

So, you're best to implement TCP MD5 on your BGP sessions.

With an up to date IOS, if you both implement the password
within about a second, the BGP session doesn't even flap to
implement the password.  Older IOS (12.1) resets the BGP
session as a password is set.  Other vendors vary.

David.

[*] in any reasonable implementation.  it is possible some old
implementation does this wrong, though.

Re: Winstar says there is no TCP/BGP vulnerability

[Joe Rhett]

I've left your entire message below so that one can see I've removed
nothing.  Winstar has made NONE of the statements you are interpreting from
their response.  They have simply stated that they don't support it at this
moment in time.  I'll grant you that they could have answered "when" or
"why" or "what else".  But they certainly didn't say anything you are 
suggesting that they have said.

Should we ever meet, I'll remember to never turn down a beer.
You might think I'm pro-prohibition or something...

On Tue, Apr 20, 2004 at 01:44:44PM -0700, Rodney Joffe wrote:
> 
> Perhaps we are all making too much of this...
> 
> It appears that Winstar feels that there is no need for MD5
> authentication of peering sessions. One of our customers has just had
> the following response from Winstar following a request to implement MD5
> on their OC3 connection to Winstar. My first suggestion is to locate
> another upstream provider (they have 3 already).
> 
> However, perhaps someone from Winstar would care to help us all
> understand what the alternative solution is to securing the session via
> MD5? I would *love* an alternative to the 5 days of work we've just gone
> through.
> 
> > -Original Message-
> > From: Justin Crawford - NMCW Engineer [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, April 20, 2004 11:13 AM
> > To: xx
> > Subject: Re: *SPAM* MD5 implimentation on BGP
> > 
> > x,
> > 
> > Winstar does not currently run MD5 authentication with our peers.
> > 
> > Thanks
> > 
> > Justin
> > 
> > Thank you for your time and business
> > 
> > Justin Crawford
> > Winstar NMCW
> > Ph: 206-xxx.
> 
> Has anyone else run in to this with Winstar?
> 
> -- 
> Rodney Joffe
> CenterGate Research Group, LLC.
> http://www.centergate.com
> "Technology so advanced, even we don't understand it!"(SM)

-- 
Joe Rhett  Chief Geek
[EMAIL PROTECTED]  Isite Services, Inc.

Re: Massive stupidity (Was: Re: TCP vulnerability)

[Patrick W . Gilmore]

On Apr 20, 2004, at 9:23 PM, Mike Tancsa wrote:

At 05:09 PM 20/04/2004, Richard A Steenbergen wrote:

party to know which side won the collision handling. Therefore you 
need
262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, 
again
worst case) * 2 (to figure out who was the connecter and who was the
accepter) = 2084569088 packets to exhaustively search all space on 
this
one single Juniper to Juniper session. Now, lets just for the sake of
argument say that the router is capable of actively processing 10,000
packets/sec of rst (a fairly exagerated number) and still have this be
considered a tcp attack instead of a straight DoS against the routing
engine. This will still take 208456 seconds, or 57.9 hours.

I dont understand why the large differences in claims
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt

says
   Modern operating
   systems normally default the RCV.WND to about 32,768 bytes. This
   means that a blind attacker need only guess 65,535 RST segments
   (2^^32/(RCV.WND*2)) in order to reset a connection. At DSL speeds
   this means that most connections (assuming the attacker can
   accurately guess both ports) can be reset in under 200 seconds
   (usually far less). With the rise of broadband availability and
   increasing available bandwidth, many Operating Systems have raised
   their default RCV.WND to as much as 64k, thus making these attacks
   even easier.
You missed the "(assuming the attacker can accurately guess both 
ports)" part.

This is BY NO MEANS a given.  In fact, it is pretty much guaranteed to 
not be a given on any router which has not recently been rebooted.  (Or 
at least that the attacker doesn't know has been recently rebooted. :)


Also, with the various 'bots' at peoples disposal, why the assumption 
the attack would not be distributed.
Who made that assumption?  I do not see it above.

Also, if you have a 'bot army at your disposal, it is trivial to packet 
a router off the 'Net - orders of magnitude easier than guessing 
sequence / port number - and faster too.  In fact, you can probably do 
it in far less than 200 seconds, more or less 59 hours.  And then you 
take down *all* BGP sessions, not just the one in question.

Since miscreants are at least as lazy as you and I, would someone 
explain to me why they would bother trying to guess the sequence & port 
numbers, even with this new "vulnerability", rather just just packet 
the router off the 'Net?  Especially now that we have made it easier by 
forcing the router to calculate MD5 signatures on each packet

Honestly, once the hysteria dies down, I think we will be going to all 
our peers and asking to take the MD5 stuff off.  I honestly believe we 
will suffer more downtime - and longer downtime - from MD5 keys going 
out of sync than any RST style attack.

If people are really worried about this, then they should ingress 
filter at the leaf nodes.  If they did, no one could spoof the source 
IP of your neighbor router and life would be good.  Add on things like 
the TTL hack and you have at least as good a protection as the MD5 
gives you without any issues of higher CPU, 1000s upon 1000s of keys to 
manage, and all the other associated risks.

But we all know people will not bother source filtering leaf nodes.  
Everyone will clamor about MD5 keys and how you should be protecting 
BGP sessions.  Kinda like guarding the windows while the doors are open 
and unattended.

--
TTFN,
patrick

Re: Massive stupidity (Was: Re: TCP vulnerability)

[Mike Tancsa]

At 05:09 PM 20/04/2004, Richard A Steenbergen wrote:

party to know which side won the collision handling. Therefore you need
262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, again
worst case) * 2 (to figure out who was the connecter and who was the
accepter) = 2084569088 packets to exhaustively search all space on this
one single Juniper to Juniper session. Now, lets just for the sake of
argument say that the router is capable of actively processing 10,000
packets/sec of rst (a fairly exagerated number) and still have this be
considered a tcp attack instead of a straight DoS against the routing
engine. This will still take 208456 seconds, or 57.9 hours.

I dont understand why the large differences in claims
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt

says
   Modern operating
   systems normally default the RCV.WND to about 32,768 bytes. This
   means that a blind attacker need only guess 65,535 RST segments
   (2^^32/(RCV.WND*2)) in order to reset a connection. At DSL speeds
   this means that most connections (assuming the attacker can
   accurately guess both ports) can be reset in under 200 seconds
   (usually far less). With the rise of broadband availability and
   increasing available bandwidth, many Operating Systems have raised
   their default RCV.WND to as much as 64k, thus making these attacks
   even easier.
Also, with the various 'bots' at peoples disposal, why the assumption the 
attack would not be distributed.

---Mike 

Nmap to print out the MAC addresses of scanned hosts

[Cemil Degirmenci]

Hello There,

maybe Offtopic, but i thought this could be interesting for some of you.

Nmap 3.51-TEST3 is released with some nice new features for local networks.

Nmap now uses the system interface table (as shown by ifconfig) to
determine whether a system is on the same network.  A database derived
from the one distributed by the IEEE is then consulted to report the
manufacturer.  Here are examples from normal and XML output:
MAC Address: 08:00:20:8F:6B:2F (SUN Microsystems Inc.)

This will maybe helpful for network administrators to track down
problem machines (worm-infected, spammers, etc.)  This also helps
track changes on DHCP networks where the IP addresses can change
frequently.
its still in development but seems to work well.

--
Mit freundlichen Gruessen / kind regards,
Cemil Degirmenci
wavecon.de

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Patrick W . Gilmore]

On Apr 20, 2004, at 4:49 PM, [EMAIL PROTECTED] wrote:

On Tue, 20 Apr 2004 15:40:38 EDT, "Patrick W.Gilmore" said:

Assuming a well randomized starting sequence number (just give me this
one for the moment),
Nope.  I won't give you that one, because that's a big chunk of the
problem:
http://lcamtuf.coredump.cx/newtcp/ (one year later)
http://razor.bindview.com/publish/papers/tcpseq.html  (original paper)
It seems that Cisco has its act mostly together, but a *LOT* of other
vendors don't, even a year after...
Well, we are talking about router vendors here, so let's limit it to 
cisco + Juniper.

Even assuming the 4K range (1024 -> 5000), the numbers are essentially 
"random" for a non-recently-rebooted router.  There is no way for you 
to know when the session started, or what number the router was at when 
it did start.

Besides, in my original post, I said that the best way to defend 
against this is good randomization, and commented that we might not 
have that now. :)

Speaking of good randomization, does anyone have a good algorithm to 
randomize ephemeral ports?  Obviously "pick random number, see if port 
is open, if it is, repeat" is not a good idea, especially on a busy 
host with lots of connections.  I was thinking something like "pick 65K 
random numbers on boot, store in file/array, cycle through".  Perhaps 
just pick a random number on boot, start at that high port number, then 
sequentially cycle?  The last one would not be good for hosts which 
accept connections (gives you a good idea of current port number), but 
would work for routers with BGP sessions which were weeks or months 
long.

Does anyone know if / how modern OSes randomize ephemeral ports?

--
TTFN,
patrick

Re: TCP vulnerability

[Tom (UnitedLayer)]

On Tue, 20 Apr 2004, Joe Abley wrote:
> I suggest an extensive late-night BOF in San Francisco in the bar to
> discuss the mechanics of adding MD5 keys to all your sessions in 48
> hours.

Zeitgeist at 7pm or the Toronado at 9pm?

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Iljitsch van Beijnum]

On 20-apr-04, at 23:45, vijay gill wrote:

the correct workaround is the
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
draft. MD5 is also the correct workaround. However, neither of the
two protect against what is the most vulnerable thing in the internet
infrastructure today - a large amount of PPS at the _router_ (with or
without md5 or tcpsecure) will blow it out of the water.
So all we have to do is apply strong crypto a bit smarter, such that we 
only burn CPU cycles for good packets rather than for all packets.

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Paul Vixie]

> A huge round of applause for everyone not doing RPF and egress filtering 
> where it is trivial to do so. You make everyones job that little bit 
> harder.
> 
> You know who you are.

well, no, actually, they mostly don't (know).
-- 
Paul Vixie

Re: TCP vulnerability

[Stephen Stuart]

> > I suggest an extensive late-night BOF in San Francisco in the bar to 
> > discuss the mechanics of adding MD5 keys to all your sessions in 48 
> > hours. Evidence of RSI and eyesight failure will be mandatory
> 
> for those who prefer to be keyboard monkeys all their lives instead
> of building tools to configure and manage networks

Tools were used, some built specifically to minimize the RSI and
eyestrain impact of this last round of config changes. Not the tools
that one gets to build and use when one has the resources of a tier-1
provider at one's disposal (one set in particular I hear it quite
excellent, and I wish it would be made available to the community),
but it was by no means a tools-free effort on Joe's part.

Stephen

Re: Ordering Windows Security Update CD (was Re: Microsoft XP SP2)

[Dan Hollis]

On Tue, 20 Apr 2004, Sean Donelan wrote:
> I do not know if Microsoft plans to refresh the CD, or make it available
> through other channels.

Bittorrent? :-)

Does anyone have a BT iso of these CDs btw? I cant imagine microsoft 
objecting to its distribution...

-Dan

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Crist Clark]

Dan Hollis wrote:

On Tue, 20 Apr 2004, Crist Clark wrote:

But it has limited effectiveness for multi-hop sessions. There is the
appeal of a solution that does not depend of the physical layout of the
BGP peers.


Does MD5 open the door to cpu DOS attacks on routers though? Eg can 
someone craft a DOS attack to take out the CPU on a router by forcing it 
to MD5 authenticate torrents of junk packets, using less bandwidth than 
it would take to DOS the links themselves?
A reasonable implementation of RFC2385 would only do the cryptographic
MD5 check after matching the TCP 4-tuple and the sequence number. So,
with respect to the attack under discussion, only the packets that would
have succeded in reseting the session make it to MD5 processing where
they then would be dropped.
Still, hitting the TCP stack even without doing the MD5 checks can
kill a router. That's what the TTL hack was suggested for in the first
place.
As has been pointed out, blind attacker needs to guess the source port as 
well, which would seem to multiply the search space blind attackers need 
to hit (the tcpsecure paper states as much - "assuming the attacker can
accurately guess both ports")

Are such attacks still practical in that light?
Yes. Most OSs do not randomize port numbers, but start at a fixed value
at reboot. On top of that, many do not use much of the 16-bit space
before wrapping. Now add that most BGP speakers don't initiate much TCP
and fire up their long lived BGP sessions at boot time. The search space
is not that big.
Then there's always going to a looking glass and just looking one up.
--
Crist J. Clark   [EMAIL PROTECTED]
Globalstar Communications(408) 933-4387

Re: TCP vulnerability

[Joe Abley]

On 20 Apr 2004, at 17:37, Randy Bush wrote:

I suggest an extensive late-night BOF in San Francisco in the bar to
discuss the mechanics of adding MD5 keys to all your sessions in 48
hours. Evidence of RSI and eyesight failure will be mandatory
for those who prefer to be keyboard monkeys all their lives instead
of building tools to configure and manage networks
I considered that, but I figured it would take longer to make a tool 
which could deal with the ten thousand ways that people want to 
coordinate this change (*and* speak to them over the phone) than it 
would to just get on and do it.

The passwords were generated, the databases were populated and the rt2 
tickets were opened using a magnificent lump of awk though, if I do say 
so myself.

Joe

Re: Xspedius / E.Spire as wellRe: Winstar says there is no TCP/BGP vulnerability

[Richard A Steenbergen]

On Tue, Apr 20, 2004 at 03:30:30PM -0600,  John Brown (CV) wrote:
> 
> Seems Xspedius aka E.SPire aka ACSI   doesn't feel that MD5 is
> important on their BGP sessions either.
> 
> Based on the ticket we filed last week, Managment does not
> feel its warranted to make these changes.
> 
> On the other hand, SPRINT  was willing and able to take MD5
> session info right away.  WAY TO GO SPRINT.

While somehow I doubt that the likes of E.Spire and Winstar are doing it
because they know it is the correct thing to do, in actual fact they are
right. All the whining about how we all should have deployed MD5 years ago
proves one very important point, it hasn't been deployed widely because it
is a ROYAL PAIN IN THE [EMAIL PROTECTED]&*. I haven't actually run the tests myself,
but people who have are telling me that the implementations of TCP-MD5 on
the major vendors do not take steps to check the sequence numbers (in the
case of a rst) or wait for a syn|ack in the syn cookie/cache/whatever
implementation (in the case of a syn) before doing the cpu burning MD5
hash. So congratulations, we all just made our routers trivially easy to
bring down with even a minor SYN/RST flood and an MD5 key included in the 
packet, even an invalid one. Knee jerk security reactions don't always 
work out in your favor. :)

BTW if someone wanted to actually implement this in a way which made 
sense, besides taking the opportunity to implement the checks I mentioned 
above before doing MD5 processing... I think the best way to go here is a 
public key authentication mechanism. Peers could post their public key on 
their peering websites or easily exchange the information in clear text 
offline, the other side could then install it on their devices when they 
turn up the peers, and it would then be used to automatically exchange MD5 
keying information. Obviously you don't want this happening every time, 
but it would be easy enough to cache this data after an initial key 
exchange and authentication check, and only fall back to the public key 
exchange following a reboot (if you dont store keys in something other 
than ram) or following an MD5 key mismatch for whatever reason.

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Cisco Security Advisory: Vulnerabilities in SNMP Message Processing

[Cisco Systems Product Security Incident Response Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Cisco Security Advisory: Vulnerabilities in SNMP Message Processing

Revision 1.0 INTERIM

For Public Release 2004 April 20 UTC 2100

- ---

Contents


Summary
Affected Products
Details
Impact
Software Versions and Fixes
Obtaining Fixed Software
Workarounds
Exploitation and Public Announcements
Status of This Notice: INTERIM
Distribution
Revision History
Cisco Security Procedures

- ---

Summary
===

Cisco Internetwork Operating System (IOS) Software releases trains
12.0S, 12.1E, 12.2, 12.2S, 12.3, 12.3B and 12.3T may contain a
vulnerability in processing SNMP requests which, if exploited, could
cause the device to reload.

The vulnerability is only present in certain IOS releases on Cisco
routers and switches. This behavior was introduced via a code change
and is resolved with CSCed68575.

This vulnerability can be remotely triggered. A successful exploitation
of this vulnerability may cause a reload of the device and could be
exploited repeatedly to produce a Denial of Service (DoS).

This advisory is available at:

http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml

Affected Products
= 

This vulnerability was introduced by a code change for CSCeb22276. This
change was committed to the following releases, causing these releases
to be vulnerable.

Note:  The list below is not comprehensive; it is provided to help
quickly identify some commonly used releases. Please see the Software
Versions and Fixes section of this advisory for the complete IOS
upgrade table.

  * 12.0(23)S4, 12.0(23)S5
  * 12.0(24)S4, 12.0(24)S5
  * 12.0(26)S1
  * 12.0(27)S
  * 12.0(27)SV, 12.0(27)SV1
  * 12.1(20)E, 12.1(20)E1, 12.1(20)E2
  * 12.1(20)EA1
  * 12.1(20)EW, 12.1(20)EW1
  * 12.1(20)EC, 12.1(20)EC1
  * 12.2(12g), 12.2(12h)
  * 12.2(20)S, 12.2(20)S1
  * 12.2(21), 12.2(21a)
  * 12.2(23)
  * 12.3(2)XC1, 12.3(2)XC2
  * 12.3(5), 12.3(5a), 12.3(5b)
  * 12.3(6)
  * 12.3(4)T, 12.3(4)T1, 12.3(4)T2, 12.3(4)T3
  * 12.3(5a)B
  * 12.3(4)XD, 12.3(4)XD1

To determine the software running on a Cisco product, log in to the
device and issue the show version command to display the system banner.
Cisco IOS software will identify itself as "Internetwork Operating
System Software" or simply "IOS". On the next line of output, the
image name will be displayed between parentheses, followed by "Version"
and the IOS release name. Other Cisco devices will not have the show
version command or will give different output.

The following example identifies a Cisco product running IOS release
12.0(3) with an installed image name of C2500-IS-L:

Cisco Internetwork Operating System Software IOS (TM)

2500 Software (C2500-IS-L), Version 12.0(3), RELEASE SOFTWARE

The release train label is "12.0".

The next example shows a product running IOS release 12.0(2a)T1 with an
image name of C2600-JS-MZ:

Cisco Internetwork Operating System Software IOS (tm)

C2600 Software (C2600-JS-MZ), Version 12.0(2a)T1, RELEASE SOFTWARE (fc1)

Additional information about Cisco IOS release naming can be found at 
http://www.cisco.com/warp/public/620/1.html.

Details
===

The Simple Network Management Protocol (SNMP) defines a standard
mechanism for remote management and monitoring of devices in an
Internet Protocol (IP) network. A device or host that supports SNMP is
an SNMP entity. There are two classes of SNMP entities: SNMP managers
that request information and receive unsolicited messages and SNMP
agents that respond to requests and send unsolicited messages. SNMP
entities that support SNMP proxy functions combine the functions of
both SNMP manager and SNMP agent.

There are two classes of SNMP operations: solicited operations such as
'get' or 'set', with which the SNMP manager requests or changes the
value of a managed object on an SNMP agent; and unsolicited operations
such as 'trap' or 'inform' messages with which the SNMP agent provides
an unsolicited notification or alarm message to the SNMP manager. The
'inform' operation is essentially an acknowledged 'trap'.

All SNMP operations are transported over the User Datagram Protocol
(UDP). Solicited operations are sent by the SNMP manager to the UDP
destination port 161 on the agent. Unsolicited operations are sent by
the SNMP agent to the UDP destination port 162. In IOS, The
acknowledgement sent by the SNMP manager to an SNMP agent in reply to
an 'inform' operation is sent to a randomly chosen high port that is
chosen when the SNMP process is started.

As IOS implements both an SNMP agent and SNMP proxy functionality, the
SNMP process in IOS starts listening for SNMP operations on UDP ports
161, 162 and the rand

Re: TCP RST attack (the cause of all that MD5-o-rama)

[vijay gill]

On Tue, Apr 20, 2004 at 09:45:01PM +, vijay gill wrote:

> infrastructure today - a large amount of PPS at the _router_ (with or
> without md5 or tcpsecure) will blow it out of the water. A 10mbits/s
> of packets at the juniper without md5 will also destroy it.

To be clear, I was just using jnx as an example. There are very few
currently shipping boxes that will survive a large PPS attack.

(also to be fair, been a while since I verified the above numbers)

/vijay

Re: Xspedius / E.Spire as wellRe: Winstar says there is no TCP/BGP vulnerability

[Andy Dills]

On Tue, 20 Apr 2004,  John Brown (CV) wrote:

>
> Seems Xspedius aka E.SPire aka ACSI   doesn't feel that MD5 is
> important on their BGP sessions either.
>
> Based on the ticket we filed last week, Managment does not
> feel its warranted to make these changes.

I dunno...to me, this falls on the side of "wait until I see my BGP
sessions reset randomly before I get concerned". So I see where they're
coming from.

As far as I can tell, from the well reasoned responses from Richard and
Patrick, it just won't get exploited quickly enough to cause a route to
get dampened. And since no privileged access is gained, the chances of
somebody actually bothering to write an effective exploit is minimal. As
others have pointed out, you may as well just flood the router and kick it
over that way, and they already have tools for that.

I think MD5 violates the KISS principle for something as important as BGP.
Not that it's difficult to implement on a small scale, just that it
creates an additional knob for other people to break, and something else
for the CPU to chew on (making it easier to take down, likely).

Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---

Re: Massive stupidity (Was: Re: TCP vulnerability)

[Sean Donelan]

On Tue, 20 Apr 2004, Richard A Steenbergen wrote:
> Anyone who seriously wanted to protect against this attack could easily
> deploy RST rate limits against their management interfaces, rather than
> run around trying to set up MD5 with every peer. As a long term
> improvement, a random ephemeral port selection process could be used.

Insufficient to completely protect against the identified vulnerabilities.
Please continue reading.

Re: TCP RST attack (the cause of all that MD5-o-rama)

[vijay gill]

On Tue, Apr 20, 2004 at 02:42:07PM -0700, Rodney Joffe wrote:
> 
> 
> vijay gill wrote:
> > 
> > 
> > Yes it does. About 5 mbit of md5 should peg a juniper at 100% according
> > to my friend alex.  I have not verified this in the lab.  I suggest
> > you try it out.
> > 
> > Also, this is why the GTSM (ttl hack) was written up ;)
> 
> So then you're suggesting that the GTSM is the correct work-around?
> 

No, the correct workaround is the
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
draft. MD5 is also the correct workaround. However, neither of the
two protect against what is the most vulnerable thing in the internet
infrastructure today - a large amount of PPS at the _router_ (with or
without md5 or tcpsecure) will blow it out of the water. A 10mbits/s
of packets at the juniper without md5 will also destroy it.

GTSM protects against that, the fact that it also works against this
is just an unexpected side benefit.

/vijay

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Rodney Joffe]

vijay gill wrote:
> 
> 
> Yes it does. About 5 mbit of md5 should peg a juniper at 100% according
> to my friend alex.  I have not verified this in the lab.  I suggest
> you try it out.
> 
> Also, this is why the GTSM (ttl hack) was written up ;)

So then you're suggesting that the GTSM is the correct work-around?

-- 
Rodney Joffe
CenterGate Research Group, LLC.
http://www.centergate.com
"Technology so advanced, even we don't understand it!"(SM)

Re: TCP vulnerability

[Randy Bush]

> I suggest an extensive late-night BOF in San Francisco in the bar to 
> discuss the mechanics of adding MD5 keys to all your sessions in 48 
> hours. Evidence of RSI and eyesight failure will be mandatory

for those who prefer to be keyboard monkeys all their lives instead
of building tools to configure and manage networks

randy

Re: TCP RST attack (the cause of all that MD5-o-rama)

[vijay gill]

On Tue, Apr 20, 2004 at 02:11:02PM -0700, Dan Hollis wrote:
> 
> On Tue, 20 Apr 2004, Crist Clark wrote:
> > But it has limited effectiveness for multi-hop sessions. There is the
> > appeal of a solution that does not depend of the physical layout of the
> > BGP peers.
> 
> Does MD5 open the door to cpu DOS attacks on routers though? Eg can 
> someone craft a DOS attack to take out the CPU on a router by forcing it 
> to MD5 authenticate torrents of junk packets, using less bandwidth than 
> it would take to DOS the links themselves?

Yes it does. About 5 mbit of md5 should peg a juniper at 100% according
to my friend alex.  I have not verified this in the lab.  I suggest
you try it out.

Also, this is why the GTSM (ttl hack) was written up ;)

/vijay

Xspedius / E.Spire as wellRe: Winstar says there is no TCP/BGP vulnerability

[John Brown (CV)]

Seems Xspedius aka E.SPire aka ACSI   doesn't feel that MD5 is
important on their BGP sessions either.

Based on the ticket we filed last week, Managment does not
feel its warranted to make these changes.


On the other hand, SPRINT  was willing and able to take MD5
session info right away.  WAY TO GO SPRINT.


On Tue, Apr 20, 2004 at 01:44:44PM -0700, Rodney Joffe wrote:
> 
> Perhaps we are all making too much of this...
> 
> It appears that Winstar feels that there is no need for MD5
> authentication of peering sessions. One of our customers has just had
> the following response from Winstar following a request to implement MD5
> on their OC3 connection to Winstar. My first suggestion is to locate
> another upstream provider (they have 3 already).
> 
> However, perhaps someone from Winstar would care to help us all
> understand what the alternative solution is to securing the session via
> MD5? I would *love* an alternative to the 5 days of work we've just gone
> through.
> 
> > -Original Message-
> > From: Justin Crawford - NMCW Engineer [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, April 20, 2004 11:13 AM
> > To: xx
> > Subject: Re: *SPAM* MD5 implimentation on BGP
> > 
> > x,
> > 
> > Winstar does not currently run MD5 authentication with our peers.
> > 
> > Thanks
> > 
> > Justin
> > 
> > Thank you for your time and business
> > 
> > Justin Crawford
> > Winstar NMCW
> > Ph: 206-xxx.
> 
> Has anyone else run in to this with Winstar?
> 
> -- 
> Rodney Joffe
> CenterGate Research Group, LLC.
> http://www.centergate.com
> "Technology so advanced, even we don't understand it!"(SM)

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Iljitsch van Beijnum]

On 20-apr-04, at 21:40, Patrick W.Gilmore wrote:

What is a typical receive window on a router?  I have been told (have 
not confirmed) it was about 14 bits.
Cisco routers have a command that will show you this number. It's 
generally just under 16k. Unfortunately, some looking glasses allow 
anyone to execute this command...

(Someone check my math. :)
I think your math computes. I was worried for a moment that TCP might 
be tricked into emitting a packet when you hit the right port combo but 
the wrong sequence number. It does, and even helps out by sending back 
the right sequence number. But of course this packet goes to the real 
correspondent so this shouldn't help the attacker.

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Dan Hollis]

On Tue, 20 Apr 2004, Crist Clark wrote:
> But it has limited effectiveness for multi-hop sessions. There is the
> appeal of a solution that does not depend of the physical layout of the
> BGP peers.

Does MD5 open the door to cpu DOS attacks on routers though? Eg can 
someone craft a DOS attack to take out the CPU on a router by forcing it 
to MD5 authenticate torrents of junk packets, using less bandwidth than 
it would take to DOS the links themselves?

As has been pointed out, blind attacker needs to guess the source port as 
well, which would seem to multiply the search space blind attackers need 
to hit (the tcpsecure paper states as much - "assuming the attacker can
accurately guess both ports")

Are such attacks still practical in that light?

-Dan

Massive stupidity (Was: Re: TCP vulnerability)

[Richard A Steenbergen]

On Tue, Apr 20, 2004 at 10:36:48AM -0700, Grant A. Kirkwood wrote:
> 
> Since no one's mentioned it yet, apparently there was a change in plans.
> It was just released a day early.
> 
> http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on_hi_te/internet_threat
> 
> And the official one:
> 
> http://www.uniras.gov.uk/vuls/2004/236929/index.htm

Allow me to quote some of my favorite parts for a second:

> Although denial of service using crafted TCP packets is a well known 
> weakness of TCP, until recently it was believed that a successful denial 
> of service attack was not achievable in practice. The reason for this is 
> that the receiving TCP implementation checks the sequence number of the 
> RST or SYN packet, which is a 32 bit number, giving a probability of 
> 1/232 of guessing the sequence number correctly (assuming a random 
> distribution).
> 
> The discoverer of the practicability of the RST attack was Paul A. 
> Watson, who describes his research in his paper “Slipping In The Windo: 
> TCP Reset Attacks, presented at the CanSecWest 2004 conference. He 
> noticed that the probability of guessing an acceptable sequence number 
> is much higher than 1/232 because the receiving TCP implementation will
> accept any sequence number in a certain range (or “window”) of the
> expected sequence number.  The window makes TCP reset attacks 
> practicable.

Sooo... This begs the question...

Exactly how much research DID it take to read RFC793 page 37, which
clearly states:

Reset Processing

  In all states except SYN-SENT, all reset (RST) segments are validated
  by checking their SEQ-fields.  A reset is valid if its sequence number
  is in the window.  In the SYN-SENT state (a RST received in response
  to an initial SYN), the RST is acceptable if the ACK field
  acknowledges the SYN.

  The receiver of a RST first validates it, then changes state.  If the
  receiver was in the LISTEN state, it ignores it.  If the receiver was
  in SYN-RECEIVED state and had previously been in the LISTEN state,
  then the receiver returns to the LISTEN state, otherwise the receiver
  aborts the connection and goes to the CLOSED state.  If the receiver
  was in any other state, it aborts the connection and advises the user
  and goes to the CLOSED state.

This is not rocket science, every TCP stack in existance implements this
exactly this way. The fact that ANYONE ever thought it was 2^32 packets to
hit upon the sequence number for a forged reset shows pure ignorance and
an inability to read on their part, but the massive amount of confusion,
rumor, and worry which the major router vendors (Cisco and Juniper)
created by essentially rediscovering the god damn spec and then telling
only their major customers about so that only rumors could filter down to
the rest of the industry is absolutely pathetic. If you have a support
contract and were not told about this "attack" (if you could call it that)
or were blatantly misinformed as many people seem to have been, you should
demand to know why you didn't receive better treatment.

Bottom line, this attack is no more practical now than it was yesterday.  
Let's run some numbers for a second shall we. First off, as I'm sure
everyone knows, BGP sessions are formed when one side establishes a tcp
connection from a high numbered ephemeral port to port 179. Both sides
actively attempt to connect to each other on and off through an
alternating series of Connect and Active states, but eventually one side
will connect to the other and only one session will survive the collision
handling process.

Now, let us just use Juniper as a worst case example, since they seem to
have a very very restricted set of ephemeral ports for some reason or
another (low 1024 high 5000, 3976 possible ports). Given the default
settings of a recvsockbuf size 16384, the maximum advertised receive
window will be 16384. This cuts the total sequence space to be scanned
down from 2^32 to 2^32 / 2^14 = 262144 packets. Now, even though the
outbound port is a simple incrementation, an outside party has no way to
know what the current number is (and in the case of long lived connections
it may not do them any good at all, though theoretically routers just
rebooted could be more vulnerable). It is also impossible for an outside
party to know which side won the collision handling. Therefore you need 
262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, again 
worst case) * 2 (to figure out who was the connecter and who was the 
accepter) = 2084569088 packets to exhaustively search all space on this 
one single Juniper to Juniper session. Now, lets just for the sake of 
argument say that the router is capable of actively processing 10,000 
packets/sec of rst (a fairly exagerated number) and still have this be 
considered a tcp atta

RE: Winstar says there is no TCP/BGP vulnerability

[McBurnett, Jim]

Well,
CERT thought it was

Jim

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

   Technical Cyber Security Alert TA04-111A archive 

Vulnerabilities in TCP

   Original release date: April 20, 2004
   Last revised: --
   Source: US-CERT

Systems Affected

 * Systems that rely on persistent TCP connections, for example
   routers supporting BGP

Overview

   Most implementations of the Border Gateway Protocol (BGP) rely on the
   Transmission Control Protocol (TCP) to maintain persistent
   unauthenticated network sessions. There is a vulnerability in TCP
   which allows remote attackers to terminate network sessions. Sustained
   exploitation of this vulnerability could lead to a denial of service
   condition; in the case of BGP systems, portions of the Internet
   community may be affected. Routing operations would recover quickly
   after such attacks ended.

I. Description

   In 2001, the CERT Coordination Center released CA-2001-09, describing
   statistical weaknesses in various TCP/IP Initial Sequence generators.
   In that document (),
   it was noted by Tim Newsham:

 [I]f a sequence number within the receive window is known, an
 attacker can inject data into the session stream or terminate the
 connection. If the ISN value is known and the number of bytes sent
 already sent is known, an attacker can send a simple packet to
 inject data or kill the session. If these values are not known
 exactly, but an attacker can guess a suitable range of values, he
 can send out a number of packets with different sequence numbers in
 the range until one is accepted. The attacker need not send a
 packet for every sequence number, but can send packets with
 sequence numbers a window-size apart. If the appropriate range of
 sequence numbers is covered, one of these packets will be accepted.
 The total number of packets that needs to be sent is then given by
 the range to be covered divided by the fraction of the window size
 that is used as an increment.

   Paul Watson has performed the statistical analysis of this attack
   when the ISN is not known and has pointed out that such an attack
   could be viable when specifically taking into account the TCP
   Window size. He has also created a proof-of-concept tool
   demonstrating the practicality of the attack. The National
   Infrastructure Security Co-Ordination Centre (NISCC) has published
   an advisory summarizing Paul Watson's analysis in "NISCC
   Vulnerability Advisory 236929," available at
   .

   Since TCP is an insecure protocol, it is possible to inject
   transport-layer packets into sessions between hosts given the right
   preconditions. The TCP/IP Initial Sequence Number vulnerability
   (http://www.kb.cert.org/vuls/id/498440) referenced in CA-2001-09 is
   one example of how an attacker could inject TCP packets into a
   session. If an attacker were to send a Reset (RST) packet for
   example, they would cause the TCP session between two endpoints to
   terminate without any further communication.

   The Border Gateway Protocol (BGP) is used to exchange routing
   information for the Internet and is primarily used by Internet
   Service Providers (ISPs). For detailed information about BGP and
   some tips for securing it, please see Cisco System's documentation
   (
   or Team Cymru (). A vulnerable situation
   arises due to the fact that BGP relies on long-lived persistent TCP
   sessions with larger window sizes to function. When a BGP session
   is disrupted, the BGP application restarts and attempts to
   re-establish a connection to its peers. This may result in a brief
   loss of service until the fresh routing tables are created.

   In a TCP session, the endpoints can negotiate a TCP Window size. When
   this is taken into account, instead of attempting to send a spoofed
   packet with all potential sequence numbers, the attacker would only
   need to calculate an valid sequence number that falls within the next
   expected ISN plus or minus half the window size. Therefore, the larger
   the TCP Window size, the the larger the range of sequence numbers that
   will be accepted in the TCP stream. According to Paul Watson's report,
   with a typical xDSL data connection (80 Kbps, upstream) capable of
   sending of 250 packets per second (pps) to a session with a TCP Window
   size of 65,535 bytes, it would be possible to inject a TCP packet
   approximately every 5 minutes. It would take approximately 15 seconds
   with a T-1 (1.544 Mbps) connection. These numbers are significant when
   large numbers of compromised machines (often called "botnets" or
   "zombies") can be used to generate large amounts of packets that can
   be directed at a particular host.

   To protect against such 

RE: Backbone IP network Economics - peering and transit

[Gary Hale]

I disagree ... but sure do appreciate your tone ... :)

Regards,

Gary

-Original Message-
From: Daniel Golding [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 20, 2004 4:32 PM
To: Gary Hale; Michel Py; Gordon Cook; [EMAIL PROTECTED]
Subject: Re: Backbone IP network Economics - peering and transit


Cynical? Gee, I hope so. Anyone who reads that sort of fluff needs to be
cynical. Lack of appropriate cynicism led, in part, to the "recent
unpleasantness" in the telecommunications industry.

Words like "enabling", "leveraging", "mindshare", "b2b", "e-*", "i-*",
et
al, are considered harmful to fruitful operational discussion :)

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group



On 4/20/04 2:17 PM, "Gary Hale" <[EMAIL PROTECTED]> wrote:

> Daniel,
> 
> That is way too cynical ... and does not address the question of
whether
> building your own transport ever runs counter to the Internet as a
> consortium. 
> 
> There are business justifications that underpin peering relationships
> ... and they are based on understanding (or ... "philosophy") 
> 
> Gary
> 
> -Original Message-
> From: Daniel Golding [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 20, 2004 10:36 AM
> To: Gary Hale; Michel Py; Gordon Cook; [EMAIL PROTECTED]
> Subject: Re: Backbone IP network Economics - peering and transit
> 
> On 4/20/04 8:45 AM, "Gary Hale" <[EMAIL PROTECTED]>
wrote:
> 
>> 
>> The question is too simplistic ... It is not (simply) a matter of
> small
>> vs. big or being on your own network from source-to-destination.
> Peering
>> is an enabler ... and gives all an opportunity to share content
> globally
>> ... kinda' fundamental to the Internet consortium.
>> 
>> Is your question, 'Since fiber is so cheap, why doesn't everyone
build
>> an autonomous, facilities-based, global "Internet" network that
> competes
>> for narrowband/broadband "pullers" of data and hosting/data
> centers/etc.
>> for content providers ("pulled-fromers" or "pushers" of data)?
>> 
>> Gary
>> 
>> -Original Message-
>> From: Michel Py [mailto:[EMAIL PROTECTED]
>> Sent: Monday, April 19, 2004 10:46 PM
>> To: Gordon Cook; [EMAIL PROTECTED]
>> Subject: RE: Backbone IP network Economics - peering and transit
>> 
>> 
>>> Peering?  Who needs peering if transit can be
>>> had for $20 per megabit per second?
>> 
>> The smaller guys that don't buy transit buy the gigabit.
>> 
>> Michel.
>> 
>> 
>> 
> Gary,
> 
> "Peering is an enabler"
> "gives all an opportunity to share content globally"
> "fundamental to the Internet consortium"
> 
> This is like the "greatest hits" compendium collected from various
> failed
> 1990's service provider business plans :)
> 
> People should be careful. Peering is a business/networking arrangement
> that
> can save them money (or not). Those who try to imbue it with
> philosophical
> significance must be viewed with skepticism.
> 
> 
> Daniel Golding
> Network and Telecommunications Strategies
> Burton Group
> 
> 
> 
> 

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Valdis . Kletnieks]

On Tue, 20 Apr 2004 15:40:38 EDT, "Patrick W.Gilmore" said:

> Assuming a well randomized starting sequence number (just give me this 
> one for the moment),

Nope.  I won't give you that one, because that's a big chunk of the
problem:

http://lcamtuf.coredump.cx/newtcp/ (one year later)
http://razor.bindview.com/publish/papers/tcpseq.html  (original paper)

It seems that Cisco has its act mostly together, but a *LOT* of other
vendors don't, even a year after...


pgp0.pgp
Description: PGP signature

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Crist Clark]

Patrick W.Gilmore wrote:

On Apr 20, 2004, at 3:24 PM, Stephen J. Wilcox wrote:

On Tue, 20 Apr 2004, James wrote:

i can see this 'attack' operational against a multihop bgp session 
that's
not md5'd.

now the question is... would this also affect single-hop bgp sessions?
my understanding would be no, as single-hops require ttl set to 1.


you can engineer packets to make sure they have the right ttl when 
they arrive,
ie if your 10 hops away, set ttl to 10 and it will be 1 on arrival :)


Not if you use the TTL hack.

Seems like that would be much more useful, and less CPU intensive, and 
less prone to user error, etc., etc. than MD5
But it has limited effectiveness for multi-hop sessions. There is the
appeal of a solution that does not depend of the physical layout of the
BGP peers.
--
Crist J. Clark   [EMAIL PROTECTED]
Globalstar Communications(408) 933-4387

Winstar says there is no TCP/BGP vulnerability

[Rodney Joffe]

Perhaps we are all making too much of this...

It appears that Winstar feels that there is no need for MD5
authentication of peering sessions. One of our customers has just had
the following response from Winstar following a request to implement MD5
on their OC3 connection to Winstar. My first suggestion is to locate
another upstream provider (they have 3 already).

However, perhaps someone from Winstar would care to help us all
understand what the alternative solution is to securing the session via
MD5? I would *love* an alternative to the 5 days of work we've just gone
through.

> -Original Message-
> From: Justin Crawford - NMCW Engineer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 20, 2004 11:13 AM
> To: xx
> Subject: Re: *SPAM* MD5 implimentation on BGP
> 
> x,
> 
> Winstar does not currently run MD5 authentication with our peers.
> 
> Thanks
> 
> Justin
> 
> Thank you for your time and business
> 
> Justin Crawford
> Winstar NMCW
> Ph: 206-xxx.

Has anyone else run in to this with Winstar?

-- 
Rodney Joffe
CenterGate Research Group, LLC.
http://www.centergate.com
"Technology so advanced, even we don't understand it!"(SM)

tcp bgp vulnerability looking glass and route server issues.

[Smith, Donald]

John Fraizer author of MRLG one of the looking glass implementations
has updated his code to fix a flaw that provided too much information.
 
MRLG-4.3.0 is available at:
Available here:
ftp://ftp.enterzone.net/looking-glass/CURRENT/

Some route servers also provide too much info.
This audit was performed yesterday so if you have already fixed this issue please 
ignore:-)
Part of this issue is the fact that some router servers provide too much information.
Without knowing the source/destination ports and IP's this is still a difficult 
vulnerability to exploit. 

>From this URL I did a quick audit.
http://www.traceroute.org/#Route%20Servers
I did NOT look at the looking glass URLs just the route servers.

This is the list of open route servers I did a quick audit on.
No connection means I was unable to connect to it.
Not misconfigured meant sho ip bgp nei did NOT work.
Sho ip bgp nei gives full ports/ips means what you think it means.
You have may want to see if any of them are yours of 
if you peer / are the upstream for any of them.

"Route Servers"

"telnet://ner-routes.bbnplanet.net"; BBN Planet NER route monitor 
No connection

"telnet://route-server.belwue.de"; BelWue (AS553)
Sho ip bgp nei gives full ports/ips.

"telnet://route-views.on.bb.telus.com";>Telus - East Coast (AS852)
Sho ip bgp nei gives full ports/ips.

telnet://route-views.ab.bb.telus.com"; Telus - West Coast (AS852)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.cerf.net";>CerfNet Route Server (AS1838)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.ip.tiscali.net";>Tiscali (AS3257)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.gblx.net";>Global Crossing (AS3549)
Not misconfigured:-)

"telnet://route-server.savvis.net/";>SAVVIS Communications (AS3561)
Sho ip bgp nei gives full ports/ips.

"telnet://public-route-server.is.co.za"; TARGET=NEW>Internet Solutions (AS3741)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server-ap.exodus.net";>Exodus Communications Asia (AS4197)
No connection

"telnet://route-server.as5388.net";>Planet Online (AS5388)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.opentransit.net";>Opentransit (AS5511)
Not misconfigured:-)

"telnet://tpr-route-server.saix.net";>South African Internet eXchange SAIX 
(AS5713)
Not misconfigure:-)

"telnet://route-server.gt.ca";>GT Group Telecom (AS6539)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.as6667.net";>EUNet Finland (AS6667)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.he.net";>Hurricane Electric (AS6939)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.ip.att.net";>AT&T (AS7018)
No connection

"telnet://route-views.optus.net.au";>Optus Route Server Australia (AS7474)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.wcg.net";>Wiltel (AS7911)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.colt.net";>Colt Internet (AS8220)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server-eu.exodus.net";>Exodus Communications Europe (AS8709)
No connection

"telnet://route-views.bmcag.net";>Broadnet mediascape communications AG 
(AS9132)
Not misconfigured:-)

"telnet://route-server-au.exodus.net";>Exodus Communications Australia (AS9328)
No connection

"telnet://route-server.manilaix.net.ph";>Manila Internet Exchange, Philippines 
(AS9670)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.east.attcanada.com";>ATT Canada - East (AS15290)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.west.attcanada.com";>ATT Canada - West (AS15290)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.ip.ndsoftware.net";>NDSoftware (AS25358)
Sho ip bgp nei gives full ports/ips.

"telnet://route-server.loudpacket.net";>Loud Packet (AS27276)
No connection.

"telnet://route-server.as28747.net/";>RealROOT (AS28747)
No connection

"telnet://route-views.oregon-ix.net";>Oregon-ix.net Route Server
Sho ip bgp nei appears it WOULD provide full ports/ips if they had any? The command 
executed but came back empty!!?? This one  can be used as a proxy bounce (connect ip 
port) too:-(

"telnet://route-server.utah.rep.net";>Utah Regional Exchange Point Route Server
Sho ip bgp nei gives full ports/ips.

"telnet://www.netlantis.org";>The NetLantis Project Route Server
Not misconfigured.


http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC
pgpFingerPrint:9CE4 227B B9B3 601F B500  D076 43F1 0767 AF00 EDCC
Increased trust is received by not violating the trust you have received.

Re: Backbone IP network Economics - peering and transit

[Daniel Golding]

Cynical? Gee, I hope so. Anyone who reads that sort of fluff needs to be
cynical. Lack of appropriate cynicism led, in part, to the "recent
unpleasantness" in the telecommunications industry.

Words like "enabling", "leveraging", "mindshare", "b2b", "e-*", "i-*", et
al, are considered harmful to fruitful operational discussion :)

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group



On 4/20/04 2:17 PM, "Gary Hale" <[EMAIL PROTECTED]> wrote:

> Daniel,
> 
> That is way too cynical ... and does not address the question of whether
> building your own transport ever runs counter to the Internet as a
> consortium. 
> 
> There are business justifications that underpin peering relationships
> ... and they are based on understanding (or ... "philosophy") 
> 
> Gary
> 
> -Original Message-
> From: Daniel Golding [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 20, 2004 10:36 AM
> To: Gary Hale; Michel Py; Gordon Cook; [EMAIL PROTECTED]
> Subject: Re: Backbone IP network Economics - peering and transit
> 
> On 4/20/04 8:45 AM, "Gary Hale" <[EMAIL PROTECTED]> wrote:
> 
>> 
>> The question is too simplistic ... It is not (simply) a matter of
> small
>> vs. big or being on your own network from source-to-destination.
> Peering
>> is an enabler ... and gives all an opportunity to share content
> globally
>> ... kinda' fundamental to the Internet consortium.
>> 
>> Is your question, 'Since fiber is so cheap, why doesn't everyone build
>> an autonomous, facilities-based, global "Internet" network that
> competes
>> for narrowband/broadband "pullers" of data and hosting/data
> centers/etc.
>> for content providers ("pulled-fromers" or "pushers" of data)?
>> 
>> Gary
>> 
>> -Original Message-
>> From: Michel Py [mailto:[EMAIL PROTECTED]
>> Sent: Monday, April 19, 2004 10:46 PM
>> To: Gordon Cook; [EMAIL PROTECTED]
>> Subject: RE: Backbone IP network Economics - peering and transit
>> 
>> 
>>> Peering?  Who needs peering if transit can be
>>> had for $20 per megabit per second?
>> 
>> The smaller guys that don't buy transit buy the gigabit.
>> 
>> Michel.
>> 
>> 
>> 
> Gary,
> 
> "Peering is an enabler"
> "gives all an opportunity to share content globally"
> "fundamental to the Internet consortium"
> 
> This is like the "greatest hits" compendium collected from various
> failed
> 1990's service provider business plans :)
> 
> People should be careful. Peering is a business/networking arrangement
> that
> can save them money (or not). Those who try to imbue it with
> philosophical
> significance must be viewed with skepticism.
> 
> 
> Daniel Golding
> Network and Telecommunications Strategies
> Burton Group
> 
> 
> 
> 

Re: hotmail issues

[J.D. Falk]

On 04/20/04, Mark Jeftovic <[EMAIL PROTECTED]> wrote: 

> We're having a lot of deferrals with connection timeouts for mail destined
> to hotmail.com, some of the IP's in question are accessable breifly from
> other locations before they start timing out as well.

Known issue.  It should be resolved now, but everyone else is
unspooling too, so the load is still high.

In general, though, if you think your mail is being blocked by
MSN Hotmail, the following links should help:

http://privacy.msn.com/anti-spam/
http://www.advertising.msn.com/adproducts/Email_TechStd.asp
http://www.advertising.msn.com/adproducts/Email_BulkDupe.asp

(Disclaimer: I work for Hotmail.  This is my personal account, 
from which I've been reading NANOG for some years, except for the 
occasional hiatus.  While I try to be helpful, it appears that I
often have to remind people that I don't speak for Microsoft and 
am rarely the escalation path they're looking for.)

-- 
J.D. Falk "be crazy dumbsaint of the mind"
<[EMAIL PROTECTED]>   -- Jack Kerouac

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Patrick W . Gilmore]

On Apr 20, 2004, at 1:36 PM, Mike Tancsa wrote:

http://www.uniras.gov.uk/vuls/2004/236929/index.htm
What is a typical receive window on a router?  I have been told (have 
not confirmed) it was about 14 bits.

Assuming a well randomized starting sequence number (just give me this 
one for the moment), and a source port range of ~4K (one of the router 
vendor's defaults), at 10K pps it would still take ~29 hours on average 
to guess the proper values for everything necessary to RST a BGP 
session.  (You can see my math at the end.  Feel free to correct me if 
I missed something.)

Hitting a router for a full day at 10K pps is likely to be noticed by 
most networks.  If you would not notice this, perhaps you should change 
your monitoring? :)

And, if you twiddle the defaults on the router vendor mentioned above, 
or you use a different router vendor, substituting "2^16" for "4000" in 
the paragraph above leads you to ... 19 days?  (Someone check my math. 
:)

Of course, some of the reports say that ephemeral ports are not well 
randomized for some router vendors. :(

So, while this is an interesting application of technology (if you are 
a h4x0r k1dd13 :), I think if the router vendors used well randomized 
ephemeral ports and sequence numbers, and used the full range of ports 
available to them, most routers will fall over long before someone 
could guess the proper values and reset a single BGP session.  Or at 
least the owners would notice before the reset succeeded.  It would be 
even better if the receive window was tuned downward for BGP - not like 
you need a huge window for data transfer when the hosts are directly 
connected.

Then we could all stop frantically trying to synchronize thousands of 
keys between thousands of networks, an exercise which is destined to 
lose some data, and therefore some connectivity.

--
TTFN,
patrick
Sequence numbers are 32 bits.  Since the miscreant only needs to guess 
once every 14 bits, you get:

  2^32 / 2^14 == 262144

There is a router vendor out there which defaults to source ports 
between 1024 and 5000, or so I have been told.  (This router vendor 
does many things very well and should not be considered a Bad Vendor 
for this one minor error, which I hope they will fix ASAP.)

We now have:

  (5000 - 1024) * 262144 == 1042284544

Let's assume a typical router can take 10K pps to the main CPU without 
falling over.  I know some can take slightly more, and many cannot take 
anywhere near that, but it is a nice round number.  Taking 10K pps, we 
get:

  1042284544 / 1 == 104228.4544

This means it will take about 29 hours to guess each possibility.

Of course, you will not have to guess each possibility to find the 
answer, so you should divide by two to get the average time to guess 
correctly.  But then you don't know which side is on port 179, so you 
have to multiply by two, which kinda cancels that out.

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Patrick W . Gilmore]

On Apr 20, 2004, at 3:24 PM, Stephen J. Wilcox wrote:

On Tue, 20 Apr 2004, James wrote:

i can see this 'attack' operational against a multihop bgp session 
that's
not md5'd.

now the question is... would this also affect single-hop bgp sessions?
my understanding would be no, as single-hops require ttl set to 1.
you can engineer packets to make sure they have the right ttl when 
they arrive,
ie if your 10 hops away, set ttl to 10 and it will be 1 on arrival :)
Not if you use the TTL hack.

Seems like that would be much more useful, and less CPU intensive, and 
less prone to user error, etc., etc. than MD5

--
TTFN,
patrick

IP economics morphed into (TCP/RST)

[Blaine Christian]

> The other is our new hot topic of security, not sure if 
> anyone has thought of this yet (or how interesting it is) but 
> the nature of the bgp attack means that if you can view a BGP 
> session you can figure things about a peer that would 
> otherwise be hidden from you in particular the port numbers 
> in use.. and I'm not 
> entirely clear on the details but it sounds like when you hit 
> the first session, 
> you can take the rest out very easily.
> 
> We cant take BGP out of band (yet!), perhaps we can keep it 
> better hidden from 
> view tho..

There are more protection methods available than just MD5 (as you allude to
Steve).  One mitigator is to use "non-routed" space for BGP peer
connections.  If you have the ability to filter on TTL 255 you are in even
better shape (arguably perfectly secure against all but
configuration/hardware failures).  You have some vulnerability with
non-routed space if you do default routing or have folks who default towards
the device doing the BGP peering though.  Source routing is also a potential
hazard for the non-routed solution (does anyone have this enabled anymore?).

Apologies for the morph but this raised a great point.   

Regards,

Blaine

Re: TCP RST attack (the cause of all that MD5-o-rama)

[James]

ah yes.. forgot about that :)

Thanks,
-J

On Tue, Apr 20, 2004 at 08:24:02PM +0100, Stephen J. Wilcox wrote:
> On Tue, 20 Apr 2004, James wrote:
> 
> > i can see this 'attack' operational against a multihop bgp session that's
> > not md5'd.
> > 
> > now the question is... would this also affect single-hop bgp sessions?
> > my understanding would be no, as single-hops require ttl set to 1.
> 
> you can engineer packets to make sure they have the right ttl when they arrive, 
> ie if your 10 hops away, set ttl to 10 and it will be 1 on arrival :)
> 
> Steve
> 
> > 
> > -J
> > 
> > 
> > On Tue, Apr 20, 2004 at 01:36:09PM -0400, Mike Tancsa wrote:
> > > 
> > > 
> > > 
> > > http://www.uniras.gov.uk/vuls/2004/236929/index.htm
> > > 
> > > 
> > > Mike Tancsa,tel +1 519 651 3400
> > > Sentex Communications,  [EMAIL PROTECTED]
> > > Providing Internet since 1994www.sentex.net
> > > Cambridge, Ontario Canada   www.sentex.net/mike
> > 
> > 

-- 
James JunTowardEX Technologies, Inc.
Technical LeadNetwork Design, Consulting, IT Outsourcing
[EMAIL PROTECTED]  Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867   web: http://www.towardex.com , noc: www.twdx.net

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Stephen J. Wilcox]

On Tue, 20 Apr 2004, James wrote:

> i can see this 'attack' operational against a multihop bgp session that's
> not md5'd.
> 
> now the question is... would this also affect single-hop bgp sessions?
> my understanding would be no, as single-hops require ttl set to 1.

you can engineer packets to make sure they have the right ttl when they arrive, 
ie if your 10 hops away, set ttl to 10 and it will be 1 on arrival :)

Steve

> 
> -J
> 
> 
> On Tue, Apr 20, 2004 at 01:36:09PM -0400, Mike Tancsa wrote:
> > 
> > 
> > 
> > http://www.uniras.gov.uk/vuls/2004/236929/index.htm
> > 
> > 
> > Mike Tancsa,  tel +1 519 651 3400
> > Sentex Communications,[EMAIL PROTECTED]
> > Providing Internet since 1994www.sentex.net
> > Cambridge, Ontario Canada www.sentex.net/mike
> 
> 

Re: Backbone IP network Economics - peering and transit

[Patrick W . Gilmore]

On Apr 20, 2004, at 2:15 PM, Stephen J. Wilcox wrote:

On Tue, 20 Apr 2004, Patrick W.Gilmore wrote:

In many, many cases, especially for smaller providers, this is a 
spare FE on a
switch which already exists.
I assume Vijay meant the cost of a port for private peering, in which 
case if
you private with all your peers and you have a lot of small peers 
thats going to
be a lot of cost for a few kbps of traffic
It was Dan, not Vijay.

And clearly we are not talking about running a pair of fiber to 
everyone who has a modem's worth of traffic.  He mentioned the cost of 
the port.  I said many people have spare FEs / GEs on existing 
switches.  And if they do not, a few hundred dollars will get them one.


- Operational costs such as legal review for BLPAs, NOC monitoring,
troubleshooting when it flaps, putting MD5 on, etc
These costs are frequently quoted as reasons not to peer by the larger
providers.
BLPAs are only required by people who think they mean something.
Well theyre a good excuse thats for certain :) But I would say they do 
mean
something.. if you're BigISP-A and you are peering with BigISP-B you 
want to
make sure that continues reliably and that means a formal arrangement. 
Even if
your a small ISP its worthwhile considering a formal arrangement 
particularly
with the larger peers to make sure they dont ditch you without some 
good notice
or that they will upgrade without cost if your traffic increases
I specifically left out BigISP-*.  The complexities of peering on a 
Tier 1 network are not really describable in a single e-mail.

As for the smaller ISPs, read every peering agreement you've signed.  
They all say they can cancel with at most 30 days notice, for no 
reason, with no recourse, and nothing you can do about it.  
Furthermore, many include the ability to shut down peering if they even 
*think* you are doing something funny, and again you have no recourse.

Peering agreements are not worth anything to keep peering up.  They are 
only worth something if you are worried about the peer doing something 
like pointing default.


In general, Peering is a Good Thing [tm].  It increases performance, 
can lower
costs, and might even increase your network reliability.
Hmm, we're fairly open on peering and have a bunch of small peers, in 
fact most
of our new peerings are with small peers (small is something like 
announcing a
single /24 and doing almost no traffic).
The second number there is important, the first is not.  There are 
peers which announce a /24 or few and have gigabits of traffic.


We occasionally see performance problems with these small peers, where 
they
maybe drop the session without warning raising an alarm here or do 
something
screwy with their config and leak or whatever.
Nowhere was I saying it is a good idea to peer with someone who hurts 
your network.  But most of the peers, even the small ones, can keep 
their network stable.


They also tend to only have one connection, this forces how we route 
traffic to
them, as we're in the process of expanding I really want to have 
multiple equal
paths so that we can be sure the traffic is taking the best way to 
them.
Perfectly valid concern.  Which is why I specifically told people to 
find out who would peer with them before paying to go to a peering 
point.  Don't count your chickens until they're hatched and all that. 
:)


My summary of these points is that I'm seriously considering what our 
policy
will be in the future and for good reason (altho it will undoubtedly 
continue to
be fairly relaxed).
And I see nothing you mentioned which in any way goes against what I 
was saying.  Your particular situation is very different than the next 
networks, as the next networks is unique to that network, etc.  But 
that doesn't make peering bad.


If your monthly costs are lower with peering than transit alone, it is
probably a good idea to peer and ignore the NOC costs.
In some instances I'm willing to pay more for a connection (eg paid 
peering or
costs of backbone circuits) to ensure I'm receiving quality.
It is nice to ensure quality.  But if quality is your primary goal, 
then directly peering with a network will give you better "quality" 
from an end user (read "paying customer") PoV than transit in most 
cases.  Extra latency is usually not viewed as better quality.

If you are worried about the connection being flaky, well, like I said, 
don't peer with flaky networks.

Besides, most small to medium guys have enough headroom on their 
transit connections to take down many of their peers and push it over 
transit without congestion.


There are a couple other issues not raised...

One is the cost on the router in terms of memory and cpu of 
maintaining such a
large number of sessions (usually less of an issue with your big 
multiprocessor
routers)
Agreed.  But since we are not talking to the one-T1-ISP (which I also 
said would not fit the model), people probably have enough CPU to 
handle a few extra BGP sessions.

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Dan Hollis]

On Tue, 20 Apr 2004, Mike Tancsa wrote:
> http://www.uniras.gov.uk/vuls/2004/236929/index.htm

A huge round of applause for everyone not doing RPF and egress filtering 
where it is trivial to do so. You make everyones job that little bit 
harder.

You know who you are.

-Dan

re: TCP vulnerability

[Allison Mankin]

Hi,

For those not helped too much the MD5 Signature Option, this
i-d addresses the attacks in the Watson paper (it was meant to
come out just when the advisory came out, but they jumped the gun).

There are implementations in *xes and router OSes - more info
from those sources.

Allison 

 Forwarded Message


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of 
the IETF.

Title   : Transmission Control Protocol security considerations
Author(s)   : R. Stewart
Filename: draft-ietf-tcpm-tcpsecure-00.txt
Pages   : 10
Date: 2004-4-20

TCP (RFC793 [1]) is widely deployed and one of the most often used
   reliable end to end protocols for data communication. Yet when it was
   defined over 20 years ago the internet, as we know it, was a
   different place lacking many of the threats that are now common.
   Recently several rather serious threats have been detailed that can
   pose new methods for both denial of service and possibly data
   injection by blind attackers. This document details those threats and
   also proposes some small changes to the way TCP handles inbound
   segments that either eliminate the threats or at least minimize them
   to a more acceptable level.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt




- --4737358894.1082487684/segue.merit.edu--

--- End of Forwarded Message

Re: TCP RST attack (the cause of all that MD5-o-rama)

[Owen DeLong]

How do you tell an adjacent TTL set to 1 from a TTL set to 5 four hops away?

Owen

--On Tuesday, April 20, 2004 14:54 -0400 James <[EMAIL PROTECTED]> wrote:

now let me take a bite at this :P

i can see this 'attack' operational against a multihop bgp session that's
not md5'd.
now the question is... would this also affect single-hop bgp sessions?
my understanding would be no, as single-hops require ttl set to 1.
-J

On Tue, Apr 20, 2004 at 01:36:09PM -0400, Mike Tancsa wrote:


http://www.uniras.gov.uk/vuls/2004/236929/index.htm


Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike


--
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.


pgp0.pgp
Description: PGP signature

Re: TCP RST attack (the cause of all that MD5-o-rama)

[James]

now let me take a bite at this :P

i can see this 'attack' operational against a multihop bgp session that's
not md5'd.

now the question is... would this also affect single-hop bgp sessions?
my understanding would be no, as single-hops require ttl set to 1.

-J


On Tue, Apr 20, 2004 at 01:36:09PM -0400, Mike Tancsa wrote:
> 
> 
> 
> http://www.uniras.gov.uk/vuls/2004/236929/index.htm
> 
> 
> Mike Tancsa,tel +1 519 651 3400
> Sentex Communications,  [EMAIL PROTECTED]
> Providing Internet since 1994www.sentex.net
> Cambridge, Ontario Canada   www.sentex.net/mike

-- 
James JunTowardEX Technologies, Inc.
Technical LeadNetwork Design, Consulting, IT Outsourcing
[EMAIL PROTECTED]  Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867   web: http://www.towardex.com , noc: www.twdx.net

RE: Backbone IP network Economics - peering and transit

[Gary Hale]

Daniel,

That is way too cynical ... and does not address the question of whether
building your own transport ever runs counter to the Internet as a
consortium. 

There are business justifications that underpin peering relationships
... and they are based on understanding (or ... "philosophy") 

Gary

-Original Message-
From: Daniel Golding [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 20, 2004 10:36 AM
To: Gary Hale; Michel Py; Gordon Cook; [EMAIL PROTECTED]
Subject: Re: Backbone IP network Economics - peering and transit

On 4/20/04 8:45 AM, "Gary Hale" <[EMAIL PROTECTED]> wrote:

> 
> The question is too simplistic ... It is not (simply) a matter of
small
> vs. big or being on your own network from source-to-destination.
Peering
> is an enabler ... and gives all an opportunity to share content
globally
> ... kinda' fundamental to the Internet consortium.
> 
> Is your question, 'Since fiber is so cheap, why doesn't everyone build
> an autonomous, facilities-based, global "Internet" network that
competes
> for narrowband/broadband "pullers" of data and hosting/data
centers/etc.
> for content providers ("pulled-fromers" or "pushers" of data)?
> 
> Gary
> 
> -Original Message-
> From: Michel Py [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 19, 2004 10:46 PM
> To: Gordon Cook; [EMAIL PROTECTED]
> Subject: RE: Backbone IP network Economics - peering and transit
> 
> 
>> Peering?  Who needs peering if transit can be
>> had for $20 per megabit per second?
> 
> The smaller guys that don't buy transit buy the gigabit.
> 
> Michel.
> 
> 
> 
Gary,

"Peering is an enabler"
"gives all an opportunity to share content globally"
"fundamental to the Internet consortium"

This is like the "greatest hits" compendium collected from various
failed
1990's service provider business plans :)

People should be careful. Peering is a business/networking arrangement
that
can save them money (or not). Those who try to imbue it with
philosophical
significance must be viewed with skepticism.
 

Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: Lazy network operators - NOT

[Steven Champeon]

on Sun, Apr 18, 2004 at 04:33:18PM +, Paul Vixie wrote:
> 
> > Maybe a stupid question... But if broadband providers aren't going to do
> > this, and considering there are way less legitimate SMTP senders than
> > broadband users, wouldn't it make more sense to whitelist known real SMTP
> > sources rather than blacklist all addresses that potentially have a fake
> > one?
> 
> that's not a stupid question, and you're right that statistically it's better
> engineering to make a small list of good things than large lists of bad ones.
> IETF MARID, my own MAIL-FROM, somebody's SPF, yahoo's "domainkeys", and lots
> of other people are working on what amounts to "a whitelisting solution", and
> in a few more years you might actually see some results along those lines.

We've had to do that here, simply to keep our own local antispam efforts
from inadvertently blacklisting "legit" mail servers. So far, with
relatively meager traffic over a year, I have a list of ~1300 legit mail
servers I want to block but can't, due to their assumed legit-to-spam
mail ratios, and another list of ~13,000 from whom I no longer accept
null sender mail because they accept-then-bounce to forged senders.

I haven't tried to assemble a list of all legit mail servers, though, as
I've yet to see a definition of "legit" I can sit comfortably with. Some
days, the line is drawn here, and others, it's drawn there. So, instead,
I just keep track of those I'd like to block but can't, for whatever
reason; those I block selectively; I whitelist a few more, and suffer.

Steve

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
Buy "Cascading Style Sheets: Separating Content from Presentation, 2/e" today!
http://www.amazon.com/exec/obidos/ASIN/159059231X/heskecominc-20/ref=nosim/

Re: Backbone IP network Economics - peering and transit

[Stephen J. Wilcox]

On Tue, 20 Apr 2004, Patrick W.Gilmore wrote:

> In many, many cases, especially for smaller providers, this is a spare FE on a
> switch which already exists.

I assume Vijay meant the cost of a port for private peering, in which case if 
you private with all your peers and you have a lot of small peers thats going to 
be a lot of cost for a few kbps of traffic

> > - Operational costs such as legal review for BLPAs, NOC monitoring,
> > troubleshooting when it flaps, putting MD5 on, etc
> 
> These costs are frequently quoted as reasons not to peer by the larger 
> providers.  
>
> BLPAs are only required by people who think they mean something.  

Well theyre a good excuse thats for certain :) But I would say they do mean 
something.. if you're BigISP-A and you are peering with BigISP-B you want to 
make sure that continues reliably and that means a formal arrangement. Even if 
your a small ISP its worthwhile considering a formal arrangement particularly 
with the larger peers to make sure they dont ditch you without some good notice 
or that they will upgrade without cost if your traffic increases

> In general, Peering is a Good Thing [tm].  It increases performance, can lower
> costs, and might even increase your network reliability.

Hmm, we're fairly open on peering and have a bunch of small peers, in fact most 
of our new peerings are with small peers (small is something like announcing a 
single /24 and doing almost no traffic).

We occasionally see performance problems with these small peers, where they 
maybe drop the session without warning raising an alarm here or do something 
screwy with their config and leak or whatever.

They also tend to only have one connection, this forces how we route traffic to 
them, as we're in the process of expanding I really want to have multiple equal 
paths so that we can be sure the traffic is taking the best way to them.

My summary of these points is that I'm seriously considering what our policy 
will be in the future and for good reason (altho it will undoubtedly continue to 
be fairly relaxed).

> If your monthly costs are lower with peering than transit alone, it is
> probably a good idea to peer and ignore the NOC costs.

In some instances I'm willing to pay more for a connection (eg paid peering or
costs of backbone circuits) to ensure I'm receiving quality.

There are a couple other issues not raised... 

One is the cost on the router in terms of memory and cpu of maintaining such a
large number of sessions (usually less of an issue with your big multiprocessor
routers)

The other is our new hot topic of security, not sure if anyone has thought of
this yet (or how interesting it is) but the nature of the bgp attack means that
if you can view a BGP session you can figure things about a peer that would
otherwise be hidden from you in particular the port numbers in use.. and I'm not 
entirely clear on the details but it sounds like when you hit the first session, 
you can take the rest out very easily.

We cant take BGP out of band (yet!), perhaps we can keep it better hidden from 
view tho..

Steve

Re: TCP vulnerability

[Joe Abley]

On 20 Apr 2004, at 13:59, Aviva Garrett wrote:

In message <[EMAIL PROTECTED]>you 
write:
Since no one's mentioned it yet, apparently there was a change in 
plans.
It was just released a day early.
This is because of the story at http://www.washingtonpost.com/, in the
Technology section.
I suggest an extensive late-night BOF in San Francisco in the bar to 
discuss the mechanics of adding MD5 keys to all your sessions in 48 
hours. Evidence of RSI and eyesight failure will be mandatory, along 
with battle stories about rt2 mail-loops and rancid-scraping awk 
scripts gone mad.

Joe

Re: TCP Vulnerability makes case for authenticated BGP

[Pekka Savola]

On Tue, 20 Apr 2004, tad pedley wrote:
> Although denial of service using crafted TCP packets is a well known
> weakness of TCP, until recently it was believed that a successful
> denial of service attack was not achievable in practice. The reason
> for this is that the receiving TCP implementation checks the
> sequence number of the RST or SYN packet, which is a 32 bit number,
> giving a probability of 1/232 of guessing the sequence number
> correctly (assuming a random distribution).
>
> The discoverer of the practicability of the RST attack was Paul A.
> Watson, who describes his research in his paper “Slipping In The
> Window: TCP Reset Attacks”, presented at the CanSecWest 2004
> conference. He noticed that the probability of guessing an
> acceptable sequence number is much higher than 1/232 because the
> receiving TCP implementation will accept any sequence number in a
> certain range (or “window”) of the expected sequence number. The
> window makes TCP reset attacks practicable.

Believed by whom, is the question.

It has been clearly documented for a long time now that such larger 
windows exist.  They have even been documented specifically about BGP 
(draft-ietf-idr-bgp-vuln-00.txt).

-- 
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: TCP vulnerability

[Aviva Garrett]

In message <[EMAIL PROTECTED]>you write:
> 
> Since no one's mentioned it yet, apparently there was a change in plans.
> It was just released a day early.

This is because of the story at http://www.washingtonpost.com/, in the
Technology section.

Thanks,
..Aviva

> 
> http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on_
  > hi_te/internet_threat
> 
> And the official one:
> 
> http://www.uniras.gov.uk/vuls/2004/236929/index.htm
> 
> Grant
> 
> -- 
> Grant A. Kirkwood - grant(at)tnarg.org
> Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED

TCP Vulnerability makes case for authenticated BGP

[tad pedley]

NISCC Vulnerability Advisory 236929Vulnerability Issues in TCPVersion Information Advisory Reference 236929 Release Date 20 April 2004 Last Revision 20 April 2004 Version Number 1.0 What is Affected?The vulnerability described in this advisory affects implementations of the Transmission Control Protocol (TCP) that comply with the Internet Engineering Task Force’s (IETF’s) Requests For Comments (RFCs) for TCP, including RFC 793, the original specification, and RFC 1323, TCP Extensions for High Performance.TCP is a core network protocol used in the majority of networked computer systems today. Many vendors include support for this protocol in their products and may be impacted to varying degrees. Furthermore any network service or application that relies on a TCP connection will also be impacted, the severity depending
 primarily on the duration of the TCP session. SeverityThe impact of this vulnerability varies by vendor and application, but in some deployment scenarios it is rated critical. Please see the vendor section below for further information. Alternatively contact your vendor for product specific information.If exploited, the vulnerability could allow an attacker to create a Denial of Service condition against existing TCP connections, resulting in premature session termination. The resulting session termination will affect the application layer, the nature and severity of the effects being dependent on the application layer protocol. The primary dependency is on the duration of the TCP connection, with a further dependency on knowledge of the network (IP) addresses of the end points of the TCP connection.The Border Gateway Protocol (BGP) is judged to be potentially most affected by this vulnerability.BGP relies on a persistent TCP session
 between BGP peers. Resetting the connection can result in medium term unavailability due to the need to rebuild routing tables and route flapping. Route flapping may result in route dampening (suppression) if the route flaps occur frequently within a short time interval. The overall impact on BGP is likely to be moderate based on the likelihood of successful attack. If the TCP MD5 Signature Option and anti-spoofing measures are used then the impact will be low as these measures will successfully mitigate the vulnerability.There is a potential impact on other application protocols such as DNS (Domain Name System) and SSL (Secure Sockets Layer) in the case of zone transfers and ecommerce transactions respectively, but the duration of the sessions is relatively short and the sessions can be restarted without medium term unavailability problems. In the case of SSL it may be difficult to guess the source IP address.Data injection may be possible. However, this has not
 been demonstrated and appears to be problematic. SummaryThe issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise) flags set.The packets need to have source and destination IP addresses that match the established connection as well as the same source and destination TCP ports.The fact that TCP sessions can be reset by sending suitable RST and SYN packets is a design feature of TCP according to RFC 793, but a reset attack is only possible at all because the source IP address and TCP port can be forged or “spoofed”.Although denial of service using crafted TCP packets is a well known weakness of TCP, until recently it was believed that a successful denial of service attack was not achievable in practice. The reason for this is that the receiving TCP implementation checks the sequence number of the RST or SYN packet, which is a
 32 bit number, giving a probability of 1/232 of guessing the sequence number correctly (assuming a random distribution).The discoverer of the practicability of the RST attack was Paul A. Watson, who describes his research in his paper “Slipping In The Window: TCP Reset Attacks”, presented at the CanSecWest 2004 conference. He noticed that the probability of guessing an acceptable sequence number is much higher than 1/232 because the receiving TCP implementation will accept any sequence number in a certain range (or “window”) of the expected sequence number. The window makes TCP reset attacks practicable.Any application protocol which relies on long term TCP connections and for which the source and destination IP addresses and TCP ports are known or can be easily guessed will be vulnerable to at least denial of service attacks. DetailsTCP is the transport layer protocol designed to provide connection-oriented reliable delivery of IP packets. To do
 this TCP uses a mixture of flags, to indicate state, and sequence numbers, to identify the order in which the packets are to be reassembled.TCP also provides a number, called an acknowledgement number, that is used to indicate the sequence number of the next packet expected. The packets are reassembled by the receiving TCP

TCP vulnerability

[Grant A. Kirkwood]

Since no one's mentioned it yet, apparently there was a change in plans.
It was just released a day early.

http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on_hi_te/internet_threat

And the official one:

http://www.uniras.gov.uk/vuls/2004/236929/index.htm

Grant

-- 
Grant A. Kirkwood - grant(at)tnarg.org
Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED

TCP RST attack (the cause of all that MD5-o-rama)

[Mike Tancsa]

http://www.uniras.gov.uk/vuls/2004/236929/index.htm


Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

hotmail issues

[Mark Jeftovic]

We're having a lot of deferrals with connection timeouts for mail destined
to hotmail.com, some of the IP's in question are accessable breifly from
other locations before they start timing out as well.

This is resulting in a lot of hotmail.com bound email backfilling in
our queues.

Is this some new tarpitting or throttling mechanism, anyone else
experiencing it?

Can a hotmail admin contact me off-list?

-mark

-- 
Mark Jeftovic <[EMAIL PROTECTED]>
Co-founder, easyDNS Technologies Inc.
ph. +1-(416)-535-8672 ext 225
fx. +1-(416)-535-0237

Re: The Uneducated Enduser (Re: Microsoft XP SP2 (was Re: Lazy network operators - NOT))

[Scott McGrath]

Operating systems bundled with a retail computer _should_ be reasonably
secure out of the box.

OS X can be placed on a unprotected internet connection in a unpatched
state and it's default configuration allows it to be patched to current
levels without it being compromised.

On the other hand Win2k & XP will be compromised in under 5 minutes if
connected to the same unfiltered connection (The record here is 35 seconds
for time to compromise)

I am not saying that OS X is the paragon of all things good.  But it's
basic settings take into account the average user's skill level and
ability to secure the OS if you want less security the user needs to
_specifically_ configure the machine to allow the reduced level of
protection.

Whereas the desire for chrome on Win has made a platform which is
virtually impossible for the average user to secure.

I use both on a daily basis as well as Solaris and Linux so I consider
myself somewhat agnostic on OS choices as each does something better than
the others and I use it for that function.


Scott C. McGrath

Re: The Uneducated Enduser (Re: Microsoft XP SP2 (was Re: Lazy network operators - NOT))

[Doug White]

[snip]
:
: My argument is that a computer needs to be in a safe state by default. I
: firmly believe that if I buy a brand new box from any reputable vendor
: with a premium operating system of choice I should be able to connect this
: device to a local broadband connection indefinitely. It needs to be safe
: without user training or user intervention.
:


It would be nearly impossible for computer software makers to provide against
any type of attack by those so inclined.  The result is that they are reactive
rather than pro-active.

Understand that the software maker wants his product to have all the features
and gee-gaws that make it attractive and simple to use, and most work well in
this area, but  over-compensating for any potential type of attack before
delivery is, in my opinion an impossible task.

One may wish that there were no vulnerabilities in any operating system, but
this is not the case.  There are vulnerabilities in all the operating systems
in place today.   Ther are many admins, (even if the admin is an uneducated
end-user) who do not bother to update their sofware or operating systems.

This practice is why Linux/Unix systems get chrooted, Windows machines get
compromised, even OSX.

Some of the vulnerabilities are in the chipset on the motherboard, be it Intel,
AMD, or Motorola.
The software maker must try to compensate for those failings as well.

As long as there arre otherwise bored miscreants who will continue to try to
exploit the vulnerabilities they will continue to happen, no matter what the
patch position is, no matter the OS or chipset used.

Thre are many security capabilities built into many OS distributions, and
relatively few are ever implemented.  Why?  Your guess is as good as mine, but
my guess is that it is time consuming of time that is not budgeted.

just my 0.02

Re: The Uneducated Enduser (Re: Microsoft XP SP2 (was Re: Lazy network operators - NOT))

[Adi Linden]

> As for the specifics of your comments, I could not disagree more, but it
> is a philosophy of life that distinguishes our views, not the analysis of
> the problem.   I believe (like a lot of other New Englanders and even
> some from California) that people must assume responsibility for their
> actions.  If responsibility is not enforced, society collapses (into e.g.
> the kind of chaos we see on the internet.)

I like the term responsibility but how is it applied? If I own a vehicle, 
what are my responsibilities? I have to obtain a drivers license which 
gives me the privilege of driving a motor vehicle. Driving a motor vehicle 
is an active choice, I am behind the wheel putting the vehicle in motion. 
I am responsible for all the consequences of my actions while driving. 
Where is my responsibility in vehicle ownership? Is is responsible to 
leave the vehicle locked at the curb, unlocked, keys in the ignition? What 
are my responsibilities when an unauthorized person uses my vehicle?
Driving a motor vehicle is a complex task. There is enforcement in place 
and it is common knowledge that training and license is required to use a 
motor vehicle.

What about a baseball bat? Where is my responsibility in owning a baseball 
bat? If I store my baseball bat leaning against my backdoor, am I 
responsible if my neighbour uses it without my permission to crack his 
wifes skull?

> In 2004 no one is "tricked" into using rubbish software; there are 
> plenty of alternatives, and the rubbishy nature of the leading OS is
> in almost every day's newspaper.  It's a choice people make, like overeating
> and gaining weight.  No one is there with a gun forcing people to gain 
> weight.

My argument is that a computer needs to be in a safe state by default. I 
firmly believe that if I buy a brand new box from any reputable vendor 
with a premium operating system of choice I should be able to connect this 
device to a local broadband connection indefinitely. It needs to be safe 
without user training or user intervention.

> As for "uneducated", the solution is the same as for bad drivers:
> training.  If you are a threat to the rest of the internet because of
> your ignorance (or irresponsibility) then you do not qualify for
> connectivity, just as bad drivers don't get licenses, bad credit
> risks don't get credit, and drunk airline pilots stop flying.  

I can walk, I can take a bicycle. Owning a computer today is like owning a 
performance car. There is no learning curve, it's all or nothing.

If this is the way it has to be, then service providers need to take 
responsibility and provide a safe environment for the uneducated users. 
This includes filtering ports, filtering emails, etc. A last resort is 
terminating service if a user is unwilling to learn at all.

Adi

Re: Backbone IP network Economics - peering and transit

[Patrick W . Gilmore]

On Apr 20, 2004, at 10:32 AM, Daniel Golding wrote:

On 4/20/04 1:34 AM, "Michel Py" <[EMAIL PROTECTED]> 
wrote:

Patrick W.Gilmore wrote:
Unless they have cheap access to a free NAP (TorIX, SIX, etc.),
transit, even at higher prices, is probably be the best /
cheapest way to reach the Internet.
This is true, but there are plenty of other opportunities for peering,
such as: both parties buy DS-3 class transit from the same tier-2 or
even maybe tier-3 provider in a colo (which will likely be a BFM, 
other
problem) not a formal IX. In other words, peering in an IX does cost
money, but peering at a colo might not, as these messy colos are 
mostly
unmanaged and nobody cares about that 25ft cross-over cable :-)

Michel.


This is a classical mistake. Peering always costs money and its never 
free.
Maybe "Free" is the wrong word.  Perhaps "No additional cost over 
".

Or, for those of us who think that the time it takes to plug a patch 
cable into an unused switch port and do some configuration changes are 
irrelevant, maybe "free" is the right word.

Either way, it is not NEARLY as bad as you or many other people make it 
out to be.  Allow me to explain


The question is, how much, and is it cheaper than transit?

Costs incurred in peering:

- Port Costs (capex)
Pth.  In many, many cases, especially for smaller providers, 
this is a spare FE on a switch which already exists.

For mid-sized providers, it is frequently a spare GE port on an 
existing switch, which means perhaps $500 for GBIC or something.

For large providers, there is a cost here.  But large providers are a 
different beast, and there is no way a simple e-mail could possibly 
capture the complexities implicit in peering between Very Large 
Providers.  So we'll let them figure out their own costs.


- A share of a router's backplane capacity corresponding to the port
Irrelevant.  The traffic has to go somewhere, if it does not go out the 
peering port, it will go out transit, but it is definitely going across 
the router's backplane.

A better thing to put here would be possible use of a router which 
would not be used.  Specifically, if I get a bit in a POP which has 
transit, I do not have to use the router out at the Peering Point.  But 
how many people have router backpanes which are saturated?  At worst 
you are running out of slots for ports in most cases.  (Remember, we 
left the really big providers to their own devices.)


- Cross connect costs (one time or recurring)
Largely irrelevant - if you are really going to go out-of-biz for a 
$150/Month x-conn, you have bigger problems.


- Operational costs such as legal review for BLPAs, NOC monitoring,
troubleshooting when it flaps, putting MD5 on, etc
These costs are frequently quoted as reasons not to peer by the larger 
providers.  Strangely enough, if you are not a Tier 1 (or hoping to be 
a Tier 1), peering sessions are usually "set up and forget".  Networks 
who have 10s of gigabits of traffic but are not looking for reasons to 
deny peering requests see nearly no cost in these (especially compared 
to the overall cost of running the network).

BLPAs are only required by people who think they mean something.  
Putting on MD5 is a bug/unique situation, which affect peering perhaps 
once every half-decade or so.  Most small and mid-sized providers can 
handle the "NOC monitoring, trouble shooting, etc." with 
single-digit-hours a month, max.  And sometimes that time is handled by 
people who are sitting on their ass waiting for something to break 
anyway.  (Read "sunk cost".)

So, unless you are looking for reasons to *not* peer, these are mostly 
BS.


- Administration
Think we covered this one.


- Public Switch costs
This is a cost and should be considered.  Unless, of course, you are at 
TorIX, SIX, or any of the other very fine free NAPs available.  Or if 
you can x-conn between your rack and someone else's rack in the same 
colo facility without going to a public switch.  Or if you are in a FR 
or ATM cloud with other providers and can get uber-cheap PVCs between 
your routers with no additional hardware and a simple configuration 
change.  Or

I think you get the point. :)


It is difficult to defend peering strategies today unless your network 
is of
a fairly significant size (gigabits of traffic) and you are collocated 
in an
advantageous location(s). Otherwise, low cost transit is hard to beat.
I think you mean "or you are colocated in an advantageous location", 
not "and".  If I am in 151 Front street, for a small one-time fee, I 
can connect to TorIX.  The amount of the fee and the time it takes to 
set up peering is probably in the noise, even for a relatively small 
provider.

Obviously if my entire traffic fits on a T1, things might be different, 
but I do not need anywhere near a gigabit of traffic to justify 
peering.  You are probably at least an order of magnitude off.

In general, Peering is a Good Thing [tm].  It increases performance, 
can lower cost

Re: The Uneducated Enduser (Re: Microsoft XP SP2 (was Re: Lazy network operators - NOT))

[Dr. Jeffrey Race]

On Tue, 20 Apr 2004 09:21:02 -0500 (CDT), Adi Linden wrote:
>> Since many gateway service providers will not prevent insufficiently
>> skilled users from connecting to the internet and injuring others, the 
>> only remaining solution, as far as I can see, is cutting connectivity
>> with those enablers.  That is the proposal I advanced in
>> .
>And once again the you're punishing the victim. Let's not forget that the 
>uneducated end user is tricked into doing things that are not good for 
>them or the rest of the internet connected world.
>Unfortunately the only feasible and readily available computer solution 
>for the uneducated end user is a single available operating system. 
>Everyone is at the mercy of this product with all its flaws and downfalls. 
>Instead of continually blaming the uneducated end user how about providing 
>tools to the uneducated end user that can be used to connect to the 
>internet without becoming a liability. A toaster with keyboard an monitor...

I beg to clarify that I am not "blaming" anyone; I am describing a system
with known input-output properties and internal structures.  We know how
this system behaves in terms of technology and human behavior, and we 
know what to do to the inputs to change the outputs.   If you choose
to smoke, you get cancer.   Same with spam.   If you don't want to have
spam, you have to change some behaviors.   Some people will be inconvenienced.
Life is full of such choices.

As for the specifics of your comments, I could not disagree more, but it
is a philosophy of life that distinguishes our views, not the analysis of
the problem.   I believe (like a lot of other New Englanders and even
some from California) that people must assume responsibility for their
actions.  If responsibility is not enforced, society collapses (into e.g.
the kind of chaos we see on the internet.)

In 2004 no one is "tricked" into using rubbish software; there are 
plenty of alternatives, and the rubbishy nature of the leading OS is
in almost every day's newspaper.  It's a choice people make, like overeating
and gaining weight.  No one is there with a gun forcing people to gain 
weight.

As for "uneducated", the solution is the same as for bad drivers:
training.  If you are a threat to the rest of the internet because of
your ignorance (or irresponsibility) then you do not qualify for
connectivity, just as bad drivers don't get licenses, bad credit
risks don't get credit, and drunk airline pilots stop flying.  

To repeat: the solution to spam is to apply rigorously the same rules
to the internet as are used everywhere else in society.   It is simple,
it pays for itself, it works, and it works immediately.  Some people
will be upset, like the smokers who have to go outside for a puff or
even give up their habit.  However the result is better for EVERYONE
including "the uneducated".

Jeffrey Race

Re: Backbone IP network Economics - peering and transit

[vijay gill]

On Tue, Apr 20, 2004 at 05:15:48AM +, Paul Vixie wrote:
> 
> > > Peering?  Who needs peering if transit can be
> > > had for $20 per megabit per second?
> 
> anyone whose applications are too important to risk dependency on OPNs
> (other people's networks).


OPNs also carry some of the consumers of your bits and you consume
some of theirs.  Unless you're peering with every laptop directly,
somewhere, somehow, you'll be traveling on OPNs, wether it is dark
fiber, a circuit, or a wavelength.

Time to bust out the cardinal vs ordinal optimization argument again.


  option a) getting the best decision for certain (cost $1 million)
  option b) Getting a decision within the top 5% With probability
 = 0.99 (cost $1 million/x), In real life, we often settle
 for such a tradeoff with x=100 to 10,000

Under independent sampling, variance decreases as 1/sqrt(n). Each order
of magnitude increase in certainty requires 2 orders of magnitude
increase in sampling cost. To go from p=0.99 to certainty (p=0.9)
implies a 1,000,000 fold increase in sampling cost.  

So, instead of creating very nice soundbites like OPNs (which I will
be shamelessly appropriating for my own use thank you very much),
I suggest we spend a bit more time actually _analysing_ using
techniques from operations research as to _what_ gives us the
most bang for the buck.

Dan golding has it right re: peering not being a philosophy, but
rather an _engineering_ decision.  I touched upon this at the 
Great Peering Debate at the NANOG Miami, which was hosted by
Bill Norton.

/vijay

Re: Backbone IP network Economics - peering and transit

[Daniel Golding]

On 4/20/04 8:45 AM, "Gary Hale" <[EMAIL PROTECTED]> wrote:

> 
> The question is too simplistic ... It is not (simply) a matter of small
> vs. big or being on your own network from source-to-destination. Peering
> is an enabler ... and gives all an opportunity to share content globally
> ... kinda' fundamental to the Internet consortium.
> 
> Is your question, 'Since fiber is so cheap, why doesn't everyone build
> an autonomous, facilities-based, global "Internet" network that competes
> for narrowband/broadband "pullers" of data and hosting/data centers/etc.
> for content providers ("pulled-fromers" or "pushers" of data)?
> 
> Gary
> 
> -Original Message-
> From: Michel Py [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 19, 2004 10:46 PM
> To: Gordon Cook; [EMAIL PROTECTED]
> Subject: RE: Backbone IP network Economics - peering and transit
> 
> 
>> Peering?  Who needs peering if transit can be
>> had for $20 per megabit per second?
> 
> The smaller guys that don't buy transit buy the gigabit.
> 
> Michel.
> 
> 
> 
Gary,

"Peering is an enabler"
"gives all an opportunity to share content globally"
"fundamental to the Internet consortium"

This is like the "greatest hits" compendium collected from various failed
1990's service provider business plans :)

People should be careful. Peering is a business/networking arrangement that
can save them money (or not). Those who try to imbue it with philosophical
significance must be viewed with skepticism.
 

Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: Backbone IP network Economics - peering and transit

[Daniel Golding]

On 4/20/04 1:34 AM, "Michel Py" <[EMAIL PROTECTED]> wrote:

> 
>> Patrick W.Gilmore wrote:
>> Unless they have cheap access to a free NAP (TorIX, SIX, etc.),
>> transit, even at higher prices, is probably be the best /
>> cheapest way to reach the Internet.
> 
> This is true, but there are plenty of other opportunities for peering,
> such as: both parties buy DS-3 class transit from the same tier-2 or
> even maybe tier-3 provider in a colo (which will likely be a BFM, other
> problem) not a formal IX. In other words, peering in an IX does cost
> money, but peering at a colo might not, as these messy colos are mostly
> unmanaged and nobody cares about that 25ft cross-over cable :-)
> 
> Michel.
> 
> 

This is a classical mistake. Peering always costs money and its never free.
The question is, how much, and is it cheaper than transit?

Costs incurred in peering:

- Port Costs (capex)
- A share of a router's backplane capacity corresponding to the port
- Cross connect costs (one time or recurring)
- Operational costs such as legal review for BLPAs, NOC monitoring,
troubleshooting when it flaps, putting MD5 on, etc
- Administration
- Public Switch costs

It is difficult to defend peering strategies today unless your network is of
a fairly significant size (gigabits of traffic) and you are collocated in an
advantageous location(s). Otherwise, low cost transit is hard to beat.

Some of the low cost transit providers will not last, and there WILL be a
second round of bankruptcies and consolidations - Googin's words should be
heeded. However, if you are multihomed and have sufficient transit diversity
(and you don't assume any local loop liabilities), the low cost transit
should be exploited while it lasts.

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

The Uneducated Enduser (Re: Microsoft XP SP2 (was Re: Lazy network operators - NOT))

[Adi Linden]

> >Think globally.  Even though this forum has NA as its heading, we need to
> >think globally when suggesting solutions.  You'll never get any sort of
> >licensing globally nor will you EVER get end users (globally) educated
> >enough to stop doing the things that they do which allow these events to
> >continually occur.
> 
> Since many gateway service providers will not prevent insufficiently
> skilled users from connecting to the internet and injuring others, the 
> only remaining solution, as far as I can see, is cutting connectivity
> with those enablers.  That is the proposal I advanced in
> .

And once again the you're punishing the victim. Let's not forget that the 
uneducated end user is tricked into doing things that are not good for 
them or the rest of the internet connected world.

Unfortunately the only feasible and readily available computer solution 
for the uneducated end user is a single available operating system. 
Everyone is at the mercy of this product with all its flaws and downfalls. 

Instead of continually blaming the uneducated end user how about providing 
tools to the uneducated end user that can be used to connect to the 
internet without becoming a liability. A toaster with keyboard an 
monitor...

Adi

RE: remote reboot power strips

[Cheung, Rick]

Title: RE: remote reboot power strips





    We use Baytechs with much success. Not only does it allow remote reboots via the modem, it supports connectivity to the console ports via serial cables; ideal for troubleshooting or Xmodem-ing new code if necessary.

http://www.baytechdcd.com/



Rick Cheung




-Original Message-
From: Alexei Roudnev [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 20, 2004 1:50 AM
To: Roy; 'Nanog List'
Subject: Re: remote reboot power strips




The same.


- Original Message - 
From: "Roy" <[EMAIL PROTECTED]>
To: "'Nanog List'" <[EMAIL PROTECTED]>
Sent: Monday, April 19, 2004 10:10 AM
Subject: RE: remote reboot power strips



>
>
> We use a number of both the APC Masterswitch and the WTS NPS-115 with good
> results.  I don't think either of them have had a failure.
>
> Roy
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Christopher J. Wolff
> Sent: Monday, April 19, 2004 8:24 AM
> To: 'nanog list'
> Subject: remote reboot power strips
>
>
>
> Hello,
>
> Last time I researched remote reboot power strips it seemed like most of
the
> power strips were garbage.  Any recommendations for a solid performer
would
> be appreciated.  Thank you.
>
> Regards,
> Christopher J. Wolff, VP CIO
> Broadband Laboratories, Inc.
> http://www.bblabs.com
>
>
>




This message, including any attachments, contains confidential information intended for a specific
individual and purpose and is protected by law. If you are not the intended recipient, please contact
sender immediately by reply e-mail and destroy all copies.
You are hereby notified that any disclosure, copying, or distribution of this message, or the taking
of any action based on it, is strictly prohibited.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email
and any attachments for the presence of viruses. The sender accepts no liability for any damage
caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed
to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors
or omissions in the contents of this message, which arise as a result of e-mail transmission.

RE: Backbone IP network Economics - peering and transit

[Gary Hale]

The question is too simplistic ... It is not (simply) a matter of small
vs. big or being on your own network from source-to-destination. Peering
is an enabler ... and gives all an opportunity to share content globally
... kinda' fundamental to the Internet consortium. 

Is your question, 'Since fiber is so cheap, why doesn't everyone build
an autonomous, facilities-based, global "Internet" network that competes
for narrowband/broadband "pullers" of data and hosting/data centers/etc.
for content providers ("pulled-fromers" or "pushers" of data)?

Gary

-Original Message-
From: Michel Py [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 19, 2004 10:46 PM
To: Gordon Cook; [EMAIL PROTECTED]
Subject: RE: Backbone IP network Economics - peering and transit


> Peering?  Who needs peering if transit can be
> had for $20 per megabit per second?

The smaller guys that don't buy transit buy the gigabit.

Michel.

Re: Ordering Windows Security Update CD (was Re: Microsoft XP SP2)

[Sean Donelan]

On Mon, 19 Apr 2004, Alexei Roudnev wrote:
> Hmnm, if you:
> -- are in Russia or other East Europe country
> - got Windows with a computer (so it is 90% pirated one)
> - have not credit card
> how can you order this CD (of course, pirates will help -:))?

The US/English Windows Security Update CD is free.  There is also a
Russian version. I don't speak/read Russian, so I don't know if Microsoft
asks for a credit card number before shipping the CD on the Russian web
page.  For the other languages/countries web pages I can understand, the
CD is free.

That goal was having an off-line version of the same patches you get from
WindowsUpdate.Microsoft.com


> This explains the number of infected systems (in addition to other reasons).
> My friends in Moscow have 3 - 4 Windows Me and Windows 98 (those, who are
> far from computer business) - no one updated. It is impossible by Internet,
> and you never know, is it Microsoft (CD) or is it Hacker (CD) when you
> purchase a CD (and you have not any reason to spend a time and money,
> purchasing CD).

In the US, the Security Update CD is shipped directly from the Microsoft
contractor to the end-user.  Of course, if the postal service, delivery
service or contractor is corrupt; what you receive could be intercepted
and replaced enroute.


> Updates are not so easy, as it seems, having 1 Mbit DSL at home, good $20K
> firewall and 10 Mbit at work (or been ISP itself).

Fixing insecure computers in black market economies is a difficult
problem. The more common reason I hear is people know (or suspect) they
are using pirate copies of Windows, and are afraid the Microsoft patches
will also disable illegal copies.  People concerned about that won't use
any updates, regardless of how easy or quick.

Although Microsoft has several web pages how to check the so-called
Certificate of Authenticity, I haven't found a Microsoft supported way to
verify the actual software installed on a computer.  Other operating
system vendors such as Sun have Solaris MD5 fingerprints for their
operating systems.

Re: Ordering Windows Security Update CD (was Re: Microsoft XP SP2)

[James Edwards]

On Tue, 2004-04-20 at 00:21, Alexei Roudnev wrote:
> Hmnm, if you:
> -- are in Russia or other East Europe country
> - got Windows with a computer (so it is 90% pirated one)
> - have not credit card


geez, they are giving the CD away for free !

james


signature.asc
Description: This is a digitally signed message part