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
-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
-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
-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
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
-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
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
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
Michael 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
PG Date: Wed, 21 Apr 2004 07:45:36 +0100
PG From: Peter Galbavy
PG E.B. Dreger wrote:
PG I don't think we're even that far along. If I'm reading FreeBSD
PG 4.9 and NetBSD 1.6.2 source correctly,
PG
PG /usr/src/sys/netinet/in_pcb.c
PG
PG Should have stretched as far as OpenBSD then. Same
Christopher / David,
Christopher L. Morrow wrote:
if you mean resetting sessions to change keys I believe
it's more code dependent than anythingn else.
That was my point: I thought that changing keys without resetting the
session was tied to a specific version of the S train that I have
Michael,
David Luyer wrote:
Have done around 100 of these in the past 24 hours. It's
not related to platform AFAIK - we've successfully done
the changes on a lowly 2651 and 3620 without outages, but
a 7200 with older IOS did have an outage.
Given the context, I assume that you have
On 21-apr-04, at 9:56, Michel Py wrote:
For pure: Don't blow me up with prefixes just limit the
maximum-prefix to some # over your expected peer's list.
Please allow me to try to make my point again: you store the expected
peer maximum-prefix somewhere in your management system. I do
understand
It's not the general case, however...
Some looking glass CGIs (in some cases, into production routers)
permit sh ip bgp nei x -- try typing sum and then nei x.x.x.x
into the show ip bgp box on a looking glass CGI, or using the
command on a route server with CLI access.
This gives you:
Local
On Tue, 20 Apr 2004, Rodney Joffe wrote:
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
http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml
This one seems much worse than the TCP RST problem.
--
Mikael Abrahamssonemail: [EMAIL PROTECTED]
Wouldnt anti-spoofing filters largely eliminate the need for all this
panic about MD5?
egress filtering, yes...
but not everyone does this and thats what poses the panic i guess :(
ingress filtering... largely yes, but no? consider the scenario:
someone runs traceroute to you (Joe ISP)
On 2004-04-20-23:09:31, David Luyer [EMAIL PROTECTED] wrote:
[...]
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
On 21-apr-04, at 12:44, Adam Rothschild wrote:
All things considered, I think MD5 authentication will lower the bar
for attackers, not raise it. I'm sure code optimizations could fix
things to some degree, but that's just not the case today.
Which begs the question, what is one to do,
How
On Wed, Apr 21, 2004 at 01:00:07PM +0200, Iljitsch van Beijnum wrote:
All things considered, I think MD5 authentication will lower the bar
for attackers, not raise it. I'm sure code optimizations could fix
things to some degree, but that's just not the case today.
Which begs the
On Wed, 21 Apr 2004, Daniel Roesen wrote:
access-list 123 deny tcp any any eq bgp rst log-input
access-list 123 deny tcp any eq bgp any rst log-input
Unfortunately, not all vendors are able to look at the RST bit when
filtering...
The general ignorance to the fact that SYN works
DH Date: Wed, 21 Apr 2004 02:01:56 -0700 (PDT)
DH From: Dan Hollis
DH Wouldnt anti-spoofing filters largely eliminate the need for
DH all this panic about MD5?
But that doesn't push the short-term cost onto other networks.
Eddy
--
EverQuick Internet - http://www.everquick.net/
A division of
ASR Date: Wed, 21 Apr 2004 06:44:14 -0400
ASR From: Adam Rothschild
ASR [T]he TTL hack sounds great on paper, but isn't exactly easy
ASR to implement when you consider that vendor J and others
ASR can't filter based upon TTL... yet.
This is more appropriate for cisco-nsp, where it's already
On Wed, 21 Apr 2004, E.B. Dreger wrote:
DH Date: Wed, 21 Apr 2004 02:01:56 -0700 (PDT)
DH From: Dan Hollis
DH Wouldnt anti-spoofing filters largely eliminate the need for
DH all this panic about MD5?
But that doesn't push the short-term cost onto other networks.
Not sure what you're
On Wed, Apr 21, 2004 at 01:23:54PM +0200, Iljitsch van Beijnum wrote:
On Wed, 21 Apr 2004, Daniel Roesen wrote:
access-list 123 deny tcp any any eq bgp rst log-input
access-list 123 deny tcp any eq bgp any rst log-input
Unfortunately, not all vendors are able to look at the
PS Date: Wed, 21 Apr 2004 14:23:38 +0300 (EEST)
PS From: Pekka Savola
PS But that doesn't push the short-term cost onto other networks.
PS
PS Not sure what you're saying. You don't need to deploy
PS anti-spoofing filters everywhere. It needs to be done by
I was being sarcastic wrt networks
On Wed, 21 Apr 2004, Daniel Roesen wrote:
The general ignorance to the fact that SYN works as well is
astonishing. :-)
What are you talking about?
http://www.uniras.gov.uk/vuls/2004/236929/index.htm
First paragraph of the summary:
The issue described in this advisory is the
On Wed, Apr 21, 2004 at 02:10:05PM +0200, Iljitsch van Beijnum wrote:
The 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.
And:
It is also possible to
On 21-apr-04, at 14:38, Daniel Roesen wrote:
So the attacker sends a spoofed SYN to router A, and router A sends an
RST to router B and router B terminates the BGP session.
Correct.
The good part here is that filtering RSTs should still work.
It doesn't. The RST are then being sent by the
On Wed, Apr 21, 2004 at 03:09:15PM +0200, Iljitsch van Beijnum wrote:
The good part here is that filtering RSTs should still work.
It doesn't. The RST are then being sent by the authorized sender and
your edge anti-spoof filtering for RST doesn't help a single
millimeter.
Now it's
On 21-apr-04, at 15:21, Daniel Roesen wrote:
As you didn't specify where to apply these filters, I guessed on the
edges. I would have never thought that someone would really suggest
to deliberately break RST for valid BGP sessions.
Try me. :-) But don't forget the borders, those are more
On Apr 21, 2004, at 3:56 AM, Michel Py wrote:
Christopher L. Morrow wrote:
For pure: Don't blow me up with prefixes just limit the
maximum-prefix to some # over your expected peer's list.
Please allow me to try to make my point again: you store the expected
peer maximum-prefix somewhere in your
Adam Rothschild wrote:
Which begs the question, what is one to do, shy of
moving (private) peering/transit/customer /31's and
/30's into non-routable IP space, which opens up an
entirely new can of worms?
Insist that the peer uses ip verify unicast reverse-path on all
interfaces, or similar
On Wed, Apr 21, 2004 at 10:19:10AM -0400, Patrick W.Gilmore wrote:
On Apr 21, 2004, at 3:56 AM, Michel Py wrote:
Christopher L. Morrow wrote:
For pure: Don't blow me up with prefixes just limit the
maximum-prefix to some # over your expected peer's list.
Please allow me to try to make
Patrick W.Gilmore wrote:
And when that process involves customers calling to ask
why they can't get to XXX web site (no pun intended -
I'm sure no one would filter a pr0n site :), it is much
more than a bitch, it is a CLM/CEM.
But you're missing something fundamental here: for non-tier-1s,
On Apr 21, 2004, at 10:38 AM, Jared Mauch wrote:
On Wed, Apr 21, 2004 at 10:19:10AM -0400, Patrick W.Gilmore wrote:
Yes, it generates more work to update the database,
but OTOH it provides the LIII engineer with a lot more to
troubleshoot
issues. Is it simply not worth the work at your scale?
On 2004-04-21-10:35:27, Michel Py [EMAIL PROTECTED]
quoted me out of order as saying:
Which begs the question, what is one to do, shy of
moving (private) peering/transit/customer /31's and
/30's into non-routable IP space, which opens up an
entirely new can of worms?
Insist that the
All,
Xspedius (formerly e.spire/ACSI) is in the process of converting BGP
connections to MD5. We have already done so with both of our transit
providers and we're working on contacting customers that we do BGP with.
If anyone is a customer of Xspedius and wants to convert to MD5, please
email
We do prefix-filter all our peers, both customer and transit. We also
use as-path filters. It does seem to help us avoid insertion of invalid
routes and other issues (especially since some people we peer with don't
do the same on their side).
As far as stability and process problems, we're too
On Wed, Apr 21, 2004 at 11:11:57AM -0400, Patrick W.Gilmore wrote:
On Apr 21, 2004, at 10:38 AM, Jared Mauch wrote:
On Wed, Apr 21, 2004 at 10:19:10AM -0400, Patrick W.Gilmore wrote:
Yes, it generates more work to update the database,
but OTOH it provides the LIII engineer with a lot
Christopher L. Morrow [EMAIL PROTECTED] writes:
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
On Wed, 21 Apr 2004, David Luyer wrote:
: You missed the (assuming the attacker can accurately guess both
: ports) part.
: 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
On Mon, Apr 19, 2004 at 04:33:49PM -0400, Paul Khavkine wrote:
Anyone doing ad blocking with Squid cache engine out there ?
This is what I've been using with Squid:
http://adzapper.sourceforge.net/
--
Edward S. Marshall [EMAIL PROTECTED]
http://esm.logic.net/
Felix qui potuit rerum
David Luyer wrote:
98 of the first 100 did not reset. Today,
I did another 12 and only one failed.
Thanks for the feedback.
If you have a fully redundant internal BGP, and are running
all 12.2S/12.3/12.2T, then you can rather safely do the
internal BGP passwords without a customer notice,
If you have a fully redundant internal BGP, and are running all
12.2S/12.3/12.2T, then you can rather safely do the internal BGP
passwords without a customer notice, expecting no session drop but
knowing if one did you'd have routes via a second BGP reflector
anyway.
Just an FYI, when
IvB Date: Wed, 21 Apr 2004 15:09:15 +0200
IvB From: Iljitsch van Beijnum
IvB [T]he filters I listed in my earlier message simply filter
IvB RSTs to/from the BGP port without looking at the address
IvB fields [...] the BGP hold timer takes care of business here
IvB anyway [...]
Interesting
On Wed, 21 Apr 2004 07:35:27 -0700, Michel Py [EMAIL PROTECTED] said:
Insist that the peer uses ip verify unicast reverse-path on all
interfaces, or similar command for other vendors.
I sure hope there are no asymmetric paths on the Internet that will
bite you when you turn on strict RPF on
On Wed, 21 Apr 2004, Robert E. Seastrom wrote:
Christopher L. Morrow [EMAIL PROTECTED] writes:
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
Interesting that Cisco uses random port selection with
SNMP (http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml,
see the Detail selection) but not with TCP.
Too bad that TCP ports aren't randomized even with the
fixed IOS versions. Would seem that as long as you're
implementing
Doug White writes:
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.
That's not the point. The difference in degree of security between
Windows and Mac OS X is
E.B. Dreger wrote:
PG Date: Wed, 21 Apr 2004 07:45:36 +0100
PG From: Peter Galbavy
PG E.B. Dreger wrote:
PG I don't think we're even that far along. If I'm reading FreeBSD
PG 4.9 and NetBSD 1.6.2 source correctly,
PG
PG /usr/src/sys/netinet/in_pcb.c
PG
PG Should have stretched as far as
On Tue Apr 20, 2004 at 02:54:16PM -0400, James wrote:
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.
All it requires is for the TTL to be 1 (or 0, I can't remember which)
when it's received. Just launch
Aditya wrote
I sure hope there are no asymmetric paths on the Internet
that will bite you when you turn on strict RPF on your
peering interfaces /sarcasm
Seriously, if you do turn RPF on on peering interfaces,
please let your peers know (plea from circa 1999)
Ah, I was waiting for someone
James wrote:
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.
Simon Lockhart wrote:
All it requires is for the TTL to be 1 (or 0, I can't
remember which) when it's received. Just launch your
packets
On Wed, 21 Apr 2004 [EMAIL PROTECTED] wrote:
On Mon, Apr 19, 2004 at 04:33:49PM -0400, Paul Khavkine wrote:
Anyone doing ad blocking with Squid cache engine out there ?
This is what I've been using with Squid:
http://adzapper.sourceforge.net/
Adzapper works very well, and is highly
On Tue, 20 Apr 2004, Patrick W.Gilmore wrote:
(Someone check my math. :)
try not to include text after your sig. some people set their mailers
to strip sigs from replies.
Sequence numbers are 32 bits. Since the miscreant only needs to
guess once every 14 bits, you get:
2^32 / 2^14 ==
On Wed, 21 Apr 2004, Iljitsch van Beijnum wrote:
I'm not recommending this for small peers as the crypto DoS risk
is worse than what happens when the attack is executed
successfully.
Why would MD5 be more of a crypto DoS risk with IPSec AH headers than
with bgp tcp-md5?
regards,
--
Paul
On Apr 21, 2004, at 3:14 PM, Paul Jakma wrote:
On Tue, 20 Apr 2004, Patrick W.Gilmore wrote:
try not to include text after your sig. some people set their mailers
to strip sigs from replies.
Wasn't that important.
[...]
Which is only 28 hours at 10kpps:
1042284544/(10*1000)/3600 = 28.95234
On 21-apr-04, at 21:17, Paul Jakma wrote:
I'm not recommending this for small peers as the crypto DoS risk
is worse than what happens when the attack is executed
successfully.
Why would MD5 be more of a crypto DoS risk with IPSec AH headers than
with bgp tcp-md5?
Beats me. But why do you bring
On Wed, 21 Apr 2004, Iljitsch van Beijnum wrote:
On 21-apr-04, at 21:17, Paul Jakma wrote:
I'm not recommending this for small peers as the crypto DoS risk
is worse than what happens when the attack is executed
successfully.
Why would MD5 be more of a crypto DoS risk with IPSec
http://www.internetnews.com/infra/article.php/3343561
For people still in a panic
-Henry
On 21-apr-04, at 21:18, Todd Vierling wrote:
[*] I must admit one thing, for instance: This Advisory was a
problem
for NetBSD, but not because its port allocation scheme was crappy. It
so
happened that NetBSD wasn't properly validating the sequence number to
be
within the window. Oops.
You
On Tue, 20 Apr 2004, John Brown (CV) wrote:
On the other hand, SPRINT was willing and able to take MD5
session info right away. WAY TO GO SPRINT.
Just to add my $0.02, I had very quick responses from HE.net; they called
me about 5 minutes after I emailed noc@ and we both recorded then
While I agree that publicly open route-views routers should not allow display of sho
ip bgp nei information, this is only giving away 4-tuple info regarding
non-production BGP sessions, right? So folks could potentially flap the route-views
sessions, but this will not affect any production
Although show ip bgp nei command is by far the easiest way to
get the BGP peer information and should not be enabled on any production
BGP peering routers that allow non-trusted or public connectivity it is
not the only way to get the information; anyone who does not do inbound
SNMP
Paul Jakma wrote:
On Wed, 21 Apr 2004, Iljitsch van Beijnum wrote:
On 21-apr-04, at 21:17, Paul Jakma wrote:
I'm not recommending this for small peers as the crypto DoS risk
is worse than what happens when the attack is executed
successfully.
Why would MD5 be more of a
Lane Patterson wrote:
While I agree that publicly open route-views routers should not allow
display of sho ip bgp nei information, this is only giving away 4-tuple
info regarding non-production BGP sessions, right? So folks could
potentially flap the route-views sessions, but this will not
--On Wednesday, April 21, 2004 3:55 PM -0700 Henry Linneweh
[EMAIL PROTECTED] wrote:
http://www.internetnews.com/infra/article.php/3343561
For people still in a panic
Does anybody have a tinfoil hat I can borrow so that I may join in the
festivities?
-J
--
Jeff Workman | [EMAIL PROTECTED]
ARIN and NANOG are very pleased to announce our third joint meeting, to be
held this fall in Reston, VA. NANOG meets Mon.-Wed., Oct. 17-19, and ARIN
Wed.-Fri., Oct. 20-22. Plan to join us - it's a great opportunity to
help determine IP allocation policy for U.S. networks. ARIN is truly a
On Wed, 21 Apr 2004 21:00:55 +0100 (IST)
Paul Jakma [EMAIL PROTECTED] wrote:
risk of crypto DoS than compared to the simple BGP TCP MD5 hack. The
risk is due to MD5, not IPSec :).
I would say the risk is due to implementation. If the vendor's gear
vomits quicker due to a resource
JK Date: Wed, 21 Apr 2004 20:51:23 -0500
JK From: John Kristoff
JK I would say the risk is due to implementation. If the
JK vendor's gear vomits quicker due to a resource consumption
JK issue in handling MD5, is this really a problem with MD5?
Theoretically MD5 and IPSec sound great.
On Wed, Apr 21, 2004 at 04:21:51PM -0700, Lane Patterson [EMAIL PROTECTED] wrote:
While I agree that publicly open route-views routers should not allow
display of sho ip bgp nei information, this is only giving away 4-tuple
info regarding non-production BGP sessions, right? So folks could
On Wed, 21 Apr 2004, Michel Py wrote:
Aditya wrote
I sure hope there are no asymmetric paths on the Internet
that will bite you when you turn on strict RPF on your
peering interfaces /sarcasm
Seriously, if you do turn RPF on on peering interfaces,
please let your peers know (plea from
73 matches
Mail list logo
