On 26-jun-2006, at 2:06, Niels Bakker wrote:
The reason IPsec helps against a DoS against the CPU is that it
has an anti replay counter. IPsec implementations are supposed to
maintain a window, not unlike a TCP window, that allows them to
reject packets with an anti replay counter that's
On Tue, 20 Jun 2006 17:06:27 -0400, Ross Callon [EMAIL PROTECTED]
wrote:
At 12:12 PM 6/20/2006 -0700, Bora Akyol wrote:
The draft allows you to have a set of keys in your keychain and
the implementation tries all of them before declaring the segment
as invalid.
DoS against routers is
On Wed, 21 Jun 2006, Richard A Steenbergen wrote:
There is a fine line between being dilligent about security, and wasting
your time trying to solve problems that don't exist, which I think has
been crossed in the discussion.
While TCP-MD5 could be useful in some cases (mainly in Internet
* [EMAIL PROTECTED] (Iljitsch van Beijnum) [Wed 21 Jun 2006, 19:05 CEST]:
The reason IPsec helps against a DoS against the CPU is that it has
an anti replay counter. IPsec implementations are supposed to
maintain a window, not unlike a TCP window, that allows them to
reject packets with an
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Iljitsch van Beijnum
Sent: Friday, June 23, 2006 4:18 PM
To: Owen DeLong
Cc: NANOG list
Subject: Re: key change for TCP-MD5
On 24-jun-2006, at 0:43, Owen DeLong wrote:
Why couldn't the network device do an AH check in hardware
terminates vs worrying over the order of the multitude of
checks which take up processing the TCP packet.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Todd Underwood
Sent: Friday, June 23, 2006 1:43 PM
To: nanog@merit.edu
Subject: Re: key change
@merit.edu
Subject: Re: key change for TCP-MD5
On Fri, 23 Jun 2006 13:35:20 PDT, Bora Akyol said:
The validity of your statement depends tremendously on
how IPSEC is
implemented.
If 113 million packets all show up at once, you're going to get
DoS'ed, whether or not you have
Why couldn't the network device do an AH check in hardware
before passing the packet to the receive path? If you can
get to a point where all connections or traffic TO the router
should be AH, then, that will help with DOS.
There is no push from the operators to look at AH check or the
On 24-jun-2006, at 1:34, Patrick W. Gilmore wrote:
If you care that much, why don't you just add an extra loopback
address, give it an RFC 1918 address, have your peer talk BGP
towards that address and filter all packets towards the actual
interface address of the router?
The chance of
On Sat, Jun 24, 2006 at 02:51:57AM -0700, Barry Greene (bgreene) wrote:
At the same time, you are not going to find the SP core swapping out
their equipment for hardware with crypto chips. SPs do not seem to want
to pay for this sort of addition. So even new equipment is not getting
If DOS is such a large concern, IPSEC to an extent can be
used to mitigate against it. And IKEv1/v2 with IPSEC is not
the horribly inefficient mechanism it is made out to be. In
practice, it is quite easy to use.
IPSEC does nothing to protect a network device from a DOS attack. You
-Original Message-
From: Barry Greene (bgreene) [mailto:[EMAIL PROTECTED]
Sent: Friday, June 23, 2006 11:50 AM
To: Bora Akyol; Ross Callon; nanog@merit.edu
Subject: RE: key change for TCP-MD5
If DOS is such a large concern, IPSEC to an extent can be used to
mitigate
On Fri, Jun 23, 2006 at 11:49:33AM -0700, Barry Greene (bgreene) wrote:
Yes Jared - our software does the TTL after the MD5, but the hardware
implementations does the check in hardware before the packet gets punted
to the receive path. That is exactly where you need to do the
On Fri, 23 Jun 2006 13:35:20 PDT, Bora Akyol said:
The validity of your statement depends tremendously on how IPSEC is
implemented.
If 113 million packets all show up at once, you're going to get DoS'ed,
whether or not you have IPSEC enabled.
pgpRRK8AbWIKX.pgp
Description: PGP signature
On Fri, Jun 23, 2006 at 04:43:29PM -0400, Todd Underwood wrote:
On Fri, Jun 23, 2006 at 11:49:33AM -0700, Barry Greene (bgreene) wrote:
Yes Jared - our software does the TTL after the MD5, but the hardware
implementations does the check in hardware before the packet gets punted
to the
. And for
this application, I don't see why cert's can't be used either.
Regards
Bora
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, June 23, 2006 1:46 PM
To: Bora Akyol
Cc: Barry Greene (bgreene); Ross Callon; nanog@merit.edu
Subject: Re: key change for TCP
On Fri, Jun 23, 2006 at 05:01:00PM -0400, Richard A Steenbergen wrote:
Obviously in a perfect world, you don't want to do the expensive MD5 check
anywhere sooner than the last possible moment before you declare the data
valid and add it to the socket buffer. I assume that the reason they
On Jun 23, 2006, at 2:02 PM, Bora Akyol wrote:
If your IPSEC is being done in hardware and you have appropriate QoS
mechanisms in your network, you will probably not be able to pass
your best effort
traffic but the rest should be OK.
Unless the DoS is within the IPSEC tunnel and crowds
On 24-jun-2006, at 0:43, Owen DeLong wrote:
Why couldn't the network device do an AH check in hardware before
passing
the
packet to the receive path? If you can get to a point where all
connections
or traffic TO the router should be AH, then, that will help with DOS.
If you care that
On Jun 23, 2006, at 7:17 PM, Iljitsch van Beijnum wrote:
On 24-jun-2006, at 0:43, Owen DeLong wrote:
Why couldn't the network device do an AH check in hardware before
passing
the
packet to the receive path? If you can get to a point where all
connections
or traffic TO the router should
On Thu, 22 Jun 2006 13:18:35 -0400, Ron Bonica [EMAIL PROTECTED] wrote:
Steve,
In Section 1 of your draft, you say:
The proper solution involves some sort of key management protocol.
Apart from the complexity of such things, RFC 2385 was not written
with key changes in mind.
On 22-jun-2006, at 23:17, Steven M. Bellovin wrote:
Why not correct the protocol deficiency by introducing a new
option that
includes a KeyID? Wouldn't that approach provide a more comprehensive
solution to the problem?
That's a much better long-term strategy, though the exact mechanism
How often do you think keys should change?
Arguably, any time someone who had access to the key is no longer
supposed
to have such access.
I've never had anyone ask
to change keys for about 50 session-years.
I guess the question the question is whether that's because they
On Tue, Jun 20, 2006 at 05:18:20PM -0700, Randy Bush wrote:
The added cost for CPU-bound systems is that they have to try
(potentially) multiple keys before getting the **right** key
but in real life this can be easily mitigated by having a rating
system on the key based on the
The added cost for CPU-bound systems is that they have to try
(potentially) multiple keys before getting the **right** key
but in real life this can be easily mitigated by having a rating
system on the key based on the frequency of success.
This mitigates the effect of authenticating valid
At 04:23 PM 6/20/2006 -0700, Bora Akyol wrote:
...The DOS is a concern whether you have a valid key or not, correct?
Yes, People who do NOT have a valid key can certainly launch
DOS attacks.
I can DOS the router with fake packets that it needs to verify as long
as I want.
Yes, but the
At 07:29 PM 6/20/2006 -0400, Richard A Steenbergen wrote:
On Tue, Jun 20, 2006 at 05:06:27PM -0400, Ross Callon wrote:
...I'd still like someone to explain why we're wasting man hours, CPU time,
filling up our router logs, and potentially making DoS easier, for an
attack that doesn't exist
All the multiple keys do is to decrease the cost of the DOS.
Yes
let's try to remember that, in reality, this is all about allowing
two bgp peers to move to a new key without having the operators on
the phone to keep the bgp session from resetting. i.e.,
o it will be uncommon that there is
--- Ross Callon [EMAIL PROTECTED] wrote:
Another potential attack is an attempt to insert
information
into a BGP session, such as to introduce bogus
routes, or
to even become a man in the middle of a BGP
session. One
issue that worries me about this is that if this
allows routing to
Another potential attack is an attempt to insert information
into a BGP session, such as to introduce bogus routes, or to
even become a man in the middle of a BGP session. One issue
that worries me about this is that if this allows routing to
be compromised, then I can figure out how
This one is hard to pull off. I think the general conclusion
a couple years ago in the study that Sean Convery and Matt Franz
did was that it was less work to try to own the router or buy your
own AS ;)
this is the you don't have to run faster than the lion, you
just have to run faster than
On Wed, Jun 21, 2006 at 05:55:21PM -0700, Randy Bush wrote:
when low-hanging fruit is unavailable, or when they see a
really cool way to exploit the higher fruit, it would be
prudent to have done something about it. who cares about
openly recursive dns servers? there are easier ways to
19, 2006 10:22 AM
To: Randy Bush
Cc: NANOG list
Subject: Re: key change for TCP-MD5
On 19-jun-2006, at 19:10, Randy Bush wrote:
try reading more carefully
Didn't help...
how sad, as the whole document is about how to usefully be able to
introduce and roll to new keys without
On 20-jun-2006, at 21:12, Bora Akyol wrote:
The draft allows you to have a set of keys in your keychain and
the implementation tries all of them before declaring the segment
as invalid.
No time synchronization required. No BGP message required.
What if we agree to change the key on our
The added cost for CPU-bound systems is that they have to try
(potentially) multiple keys before getting the **right** key
once
What if we agree to change the key on our BGP session, I add the new
key on my side and start sending packets using the new key, while you
don't have the new key in your configuration yet?
again: try reading the draft
On 20-jun-2006, at 21:23, Randy Bush wrote:
What if we agree to change the key on our BGP session, I add the new
key on my side and start sending packets using the new key, while you
don't have the new key in your configuration yet?
again: try reading the draft
I've read the draft and it
On Tue, 20 Jun 2006 21:16:05 +0200, Iljitsch van Beijnum said:
What if we agree to change the key on our BGP session, I add the new
key on my side and start sending packets using the new key, while you
don't have the new key in your configuration yet?
How is that *any* different than you
On 6/20/2006 at 12:33 PM, Iljitsch van Beijnum [EMAIL PROTECTED] wrote:
On 20-jun-2006, at 21:23, Randy Bush wrote:
What if we agree to change the key on our BGP session, I add the new
key on my side and start sending packets using the new key, while you
don't have the new key in your
the keys the intended
damage of the attack).
Ross
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Iljitsch van Beijnum
Sent: Monday, June 19, 2006 10:22 AM
To: Randy Bush
Cc: NANOG list
Subject: Re: key change for TCP-MD5
On 19-jun-2006, at 19:10
Good comments, please see inline:
-Original Message-
From: Ross Callon [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 20, 2006 2:06 PM
To: Bora Akyol; nanog@merit.edu
Subject: RE: key change for TCP-MD5
At 12:12 PM 6/20/2006 -0700, Bora Akyol wrote:
The draft allows you
On Tue, Jun 20, 2006 at 05:06:27PM -0400, Ross Callon wrote:
DoS against routers is of course a major concern. Using
encryption has the potential of making DoS worse, in the
sense that the amount of processing that a bogus packet
can cause is increased by the amount of processing
needed to
The added cost for CPU-bound systems is that they have to try
(potentially) multiple keys before getting the **right** key
but in real life this can be easily mitigated by having a rating
system on the key based on the frequency of success.
This mitigates the effect of authenticating valid
On Jun 20, 2006, at 4:29 PM, Richard A Steenbergen wrote:
We already collectively wasted our time deploying MD5 passwords
over a big
scare that turned out to be nothing more than someone cracking open
the
manual and rediscovering how stuff worked all along
Bwahahahhahaha.
I work with
I'd still like someone to explain why we're wasting man hours, CPU time,
filling up our router logs, and potentially making DoS easier, for an
attack that doesn't exist.
because the non-existent attack(s) have occurred. and keys have
been compomised.
randy
I just submitted an I-D on TCP-MD5 key change. Until it shows up in the
official repository, see
http://www.cs.columbia.edu/~smb/papers/draft-bellovin-keyroll2385-00.txt
Here's the abstract:
The TCP-MD5 option is most commonly used to secure
BGP sessions between
Steven M. Bellovin wrote:
I just submitted an I-D on TCP-MD5 key change. Until it shows up in the
official repository, see
http://www.cs.columbia.edu/~smb/papers/draft-bellovin-keyroll2385-00.txt
Here's the abstract:
The TCP-MD5 option is most commonly used to secure
On 19-jun-2006, at 14:32, Steven M. Bellovin wrote:
I just submitted an I-D on TCP-MD5 key change. Until it shows up
in the
official repository, see
http://www.cs.columbia.edu/~smb/papers/draft-bellovin-
keyroll2385-00.txt
Here's the abstract:
The TCP-MD5 option is most
On Mon, 19 Jun 2006 08:59:45 -0400, Joe Maimon [EMAIL PROTECTED] wrote:
Steven M. Bellovin wrote:
I just submitted an I-D on TCP-MD5 key change. Until it shows up in the
official repository, see
http://www.cs.columbia.edu/~smb/papers/draft-bellovin-keyroll2385-00.txt
Here's
On Mon, Jun 19, 2006 at 03:40:50PM +0200, Iljitsch van Beijnum wrote:
On 19-jun-2006, at 14:32, Steven M. Bellovin wrote:
I just submitted an I-D on TCP-MD5 key change. Until it shows up
in the
official repository, see
http://www.cs.columbia.edu/~smb/papers/draft-bellovin
On Mon, 19 Jun 2006 15:40:50 +0200, Iljitsch van Beijnum
[EMAIL PROTECTED] wrote:
On 19-jun-2006, at 14:32, Steven M. Bellovin wrote:
I just submitted an I-D on TCP-MD5 key change. Until it shows up
in the
official repository, see
http://www.cs.columbia.edu/~smb/papers/draft
There doesn't really seem to be a way to introduce a new key other
than to just to agree on a time. I'm not sure this is good enough.
try reading more carefully
On 19-jun-2006, at 16:18, Steven M. Bellovin wrote:
Comments welcome.
I wonder how long that policy will hold. (-:
I'm not certain what you mean by that, but since it sounds
insulting to
someone I'll ignore it.
I see that my attempts at levity (this one by referring to the
On 19-jun-2006, at 16:54, Randy Bush wrote:
There doesn't really seem to be a way to introduce a new key other
than to just to agree on a time. I'm not sure this is good enough.
try reading more carefully
Didn't help...
There doesn't really seem to be a way to introduce a new key other
than to just to agree on a time. I'm not sure this is good enough.
try reading more carefully
Didn't help...
how sad, as the whole document is about how to usefully be able
to introduce and roll to new keys without agreeing
On 19-jun-2006, at 19:10, Randy Bush wrote:
try reading more carefully
Didn't help...
how sad, as the whole document is about how to usefully be able
to introduce and roll to new keys without agreeing on a narrow
time.
Well, as you can tell from my message just now, I don't think going
IvB Date: Mon, 19 Jun 2006 15:40:50 +0200
IvB From: Iljitsch van Beijnum
IvB And is NANOG now officially an IETF working group...?
More interaction between IETF and NANOG is good. Kudos to SMB for
trying to inspire more of it.
Eddy
--
Everquick Internet - http://www.everquick.net/
A division
57 matches
Mail list logo
