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
Exc
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
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 t
* [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 ant
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
> ha
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 a
> 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 t
essage-
> > 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-MD5
> >
> > On Fri, 23 Jun 2006 13:35:
; To: nanog@merit.edu
> Subject: Re: key change for TCP-MD5
>
>
>
>
> 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
nal Message-
> From: [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:
>
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 b
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 mu
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 can limit what devices _SHOULD_ talk to the router and at least
de
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 ou
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 the
d 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@
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
>
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 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
> classific
> -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, IPS
> 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
> 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 the
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
s
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
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 t
> 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 t
>
> 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 o
On 21-jun-2006, at 16:24, Ross Callon wrote:
If DOS is such a large concern, IPSEC to an extent can be used
to mitigate against it.
Well, this one comment is the one that I don't understand. I
don't see how IPSEC mitigates against DOS attacks. In fact, it
seems to make things worse, since it
--- 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 ro
>> 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
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
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 atta
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 auth
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
> 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
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 t
>> 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 authenticat
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
> need
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:
&
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 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
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 yo
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 "
> 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
> The added cost for CPU-bound systems is that they have to try
> (potentially) multiple keys before getting the **right** key
once
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 BGP
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, Randy Bush wrote:
>
> >>> try reading more carefully
>
> >> Didn't help...
>
> > how sad, as th
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 divisi
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
>>> 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 ag
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...
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
infamous
> 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 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/d
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 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
> >
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
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
58 matches
Mail list logo
