Priscilla,
Questions arose while trying to explain proposed TCP fixes to my
students. Can y'all help me with these?
We were going over the Transmission Control Protocol security
considerations draft-ietf-tcpm-tcpsecure-00.txt document here when
the questions arose:
On 27-apr-04, at 5:03, Priscilla Oppenheimer wrote:
C) If the RST bit is set and the sequence number does not exactly
match the next expected sequence value, yet is within the
acceptable window (RCV.NXT SEG.SEQ = RCV.NXT+RCV.WND) send an
acknowledgment.
So, per item C, does
I didn't have it quite right though because I said the host that sends the
ACK could keep sending and then that would trigger a RST. But the ACK
triggers an immediate RST from the host that sent the original RST. This
time the RST has the right sequence number (derived from the ACK).
Maybe I
Questions arose while trying to explain proposed TCP fixes to my students.
Can y'all help me with these?
We were going over the Transmission Control Protocol security
considerations draft-ietf-tcpm-tcpsecure-00.txt document here when the
questions arose:
On 23-apr-04, at 8:35, Florian Weimer wrote:
So I believe filtering out all BGP RSTs on all
edges is probably a good idea.
(Edges and borders.)
The problem is that even if you filter the RST, the state transition
occurs at the side which receives the SYN and generates the RST. This
means that
On 23-apr-04, at 12:03, Florian Weimer wrote:
BTW, anyone seen anything supporting Paul Watson's claim that all it
takes to break a session is four packets?
Where does he claim that?
In several news stories, such as
http://www.wired.com/news/technology/0,1282,63143,00.html?
tw=wn_tophead_2
I point out NetBSD released this:
ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2004-006.txt.asc
Of interest is this paragraph:
] Additionally, the 4.4BSD stack from which NetBSD's stack is derived, did
] not even check that a RST's sequence number was inside the window. RSTs
]
Leo Bicknell wrote:
I point out NetBSD released this:
ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2004-006.txt.asc
Of interest is this paragraph:
] Additionally, the 4.4BSD stack from which NetBSD's stack is derived, did
] not even check that a RST's sequence number was inside
On Thu, 22 Apr 2004, Iljitsch van Beijnum wrote:
Unless I was really sleep-typing I didn't say anything about IPsec,
just about crypto, which as far as I'm concerned includes MD5,
which we were talking about.
Ah, ok. I thought you were referring specifically to MD5.
As Crist Clark just
On Fri, 23 Apr 2004, Leo Bicknell wrote:
: I point out NetBSD released this:
:
: ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2004-006.txt.asc
Yes. I made reference to this in the Vendor TCP oops-es thread where I
explained the conveniently forgotten magnitude scale of the
From: Pekka Savola [mailto:[EMAIL PROTECTED]
When discussing RPF towards peers or w/ asymmetric
paths, I'd recommend to read RFC 3704
I have, this is a very good document.
If your prefix filter stops a neighbor from
advertising a prefix, maybe you would have to
revise your prefix
David Luyer wrote:
[snip]
With ipsec, you have crypto overhead before you have any opportunity
to do the basic sanity check.
Minor point, but with IPsec, the 32-bit SPI and the 32-bit replay counter
are very low cost ways to drop the majority of traffic from a flood of
random junk with no crypto
On 21-apr-04, at 22:00, Paul Jakma wrote:
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 up IPsec?
The paragraph is quoted is your advice against using IPSec,
Unless I was really sleep-typing I didn't say anything about
EBD Date: Wed, 21 Apr 2004 10:56:26 + (GMT)
EBD From: E.B. Dreger
EBD This is more appropriate for cisco-nsp, where it's already
EBD been covered, but the TTL 255 hack was introduced in
EBD 12.0(22)S and 12.3(7)T if memory serves me. Pretty sparse
Memory did not serve me.
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
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, 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
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
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 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
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
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
2004 11:37:04 -0400 (EDT)
From: Todd Vierling [EMAIL PROTECTED]
To: David Luyer [EMAIL PROTECTED]
Cc: 'Patrick W.Gilmore' [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: TCP/BGP vulnerability - easier than you think
On Wed, 21 Apr 2004, David Luyer wrote:
: You missed the (assuming
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
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 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
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
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, 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
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. :)
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
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
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
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
44 matches
Mail list logo
