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:
> http://www.ietf
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 wo
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
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:
http://www.ietf.org/internet-drafts/d
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 pro
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 jus
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
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
] a
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'
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 th
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.
s/12.0(22)S/
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 IPse
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 ca
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 filt
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
> > Seriously, if you do turn RPF on on peering interfaces,
> > please let your peers know (plea f
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. Ope
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 consump
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 wo
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 ri
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:
> 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,
--
Pau
> 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
> 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 to
, 21 Apr 2004, Todd Vierling wrote:
> Date: Wed, 21 Apr 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: T
> 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
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, 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 sourc
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
> 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 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 importa
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.
>
>
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 autho
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
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
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 lo
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
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 th
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 alread
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 about:
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
> > 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 th
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 k
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 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
43 matches
Mail list logo
