Mailing List Archive

[nsp] bgp vulnerability?
Anyone have any details on this?
http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on
_hi_te/internet_threat

from the wording it sounds like it is BGP they are talking
about, and faking a reset by guessing the sequence number
to be in window.

I know cisco has a MD5 option (RFC2385,
Protection of BGP Sessions via the TCP MD5 Signature Option)
Re: [nsp] bgp vulnerability? [ In reply to ]
Don Bowman wrote:

>Anyone have any details on this?
>
>
http://www.uniras.gov.uk/vuls/2004/236929/index.htm

>http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on
>_hi_te/internet_threat
>
>from the wording it sounds like it is BGP they are talking
>about, and faking a reset by guessing the sequence number
>to be in window.
>
>I know cisco has a MD5 option (RFC2385,
>Protection of BGP Sessions via the TCP MD5 Signature Option)
>
>_______________________________________________
>cisco-nsp mailing list cisco-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
RE: [nsp] bgp vulnerability? [ In reply to ]
I'm just wondering - because it's valid RFC 793 behavior,
how it can be avoided ?
by not complaining with RFC ?
If sequence number has to match exactly (but not in the window) - then there
may be
quite often situations when valid Reesets will not work

Am I wrong here ?

Reset Processing

In all states except SYN-SENT, all reset (RST) segments are validated
by checking their SEQ-fields. A reset is valid if its sequence number
is in the window.

> -----Original Message-----
> From: cisco-nsp-bounces@puck.nether.net
> [mailto:cisco-nsp-bounces@puck.nether.net]On Behalf Of Steve Francis
> Sent: Tuesday, April 20, 2004 3:54 PM
> To: Don Bowman
> Cc: 'cisco-nsp@puck.nether.net'
> Subject: Re: [nsp] bgp vulnerability?
>
>
> Don Bowman wrote:
>
> >Anyone have any details on this?
> >
> >
> http://www.uniras.gov.uk/vuls/2004/236929/index.htm
>
> >http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap
/20040420/ap_on
>_hi_te/internet_threat
>
>from the wording it sounds like it is BGP they are talking
>about, and faking a reset by guessing the sequence number
>to be in window.
>
>I know cisco has a MD5 option (RFC2385,
>Protection of BGP Sessions via the TCP MD5 Signature Option)
>
>_______________________________________________
>cisco-nsp mailing list cisco-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [nsp] bgp vulnerability? [ In reply to ]
----- Original Message -----
From: "Dmitry Volkov" <dmitry.volkov@rogers.com>
To: "'Steve Francis'" <steve@expertcity.com>; "'Don Bowman'"
<don@sandvine.com>
Cc: <cisco-nsp@puck.nether.net>
Sent: Tuesday, April 20, 2004 10:34 PM
Subject: RE: [nsp] bgp vulnerability?


> I'm just wondering - because it's valid RFC 793 behavior,
> how it can be avoided ?
> by not complaining with RFC ?
> If sequence number has to match exactly (but not in the window) - then
there
> may be
> quite often situations when valid Reesets will not work
>
> Am I wrong here ?
>
>

Proposed changes are in
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt ,
especially :
A) If the RST bit is set and the sequence number is outside the
expected window, silently drop the segment.
B) If the RST bit is exactly the next expected sequence number, reset
the connection.
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.


Moreover , let's don't forget that from [(src,port) and (dst,port)] at
least one value also has to be also quessed ( port ) which
expand space a little bit more.

regards

Piotr Marecki
Re: [nsp] bgp vulnerability? [ In reply to ]
Hi,

On Tue, Apr 20, 2004 at 04:34:15PM -0400, Dmitry Volkov wrote:
> I'm just wondering - because it's valid RFC 793 behavior,
> how it can be avoided ?
> by not complaining with RFC ?
> If sequence number has to match exactly (but not in the window) - then there
> may be
> quite often situations when valid Reesets will not work

Ignore all RSTs that do not carry a valid MD5 hash.

Make sure that no packets with spoofed source addresses can enter or leave
your network.

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de
RE: [nsp] bgp vulnerability? [ In reply to ]
From: Dmitry Volkov [mailto:dmitry.volkov@rogers.com]
> I'm just wondering - because it's valid RFC 793 behavior,
> how it can be avoided ?
> by not complaining with RFC ?
> If sequence number has to match exactly (but not in the
> window) - then there
> may be
> quite often situations when valid Reesets will not work
>
> Am I wrong here ?
>
> Reset Processing
>
> In all states except SYN-SENT, all reset (RST) segments are
> validated
> by checking their SEQ-fields. A reset is valid if its
> sequence number
> is in the window.
>

http://www.us-cert.gov/cas/techalerts/TA04-111A.html

is the attack mentioned. This isn't exactly new news, this
has been a known issue with TCP (and BGP) for a long time.

TCP must reset if the RST is in window. The md5 option
[RFC2385] means that the attacker must do more than just
guess the sequence number, so if that's enabled, you won't
be vulnerable to this attack.

The yahoo article made it sound a lot more interesting :)

--don
RE: [nsp] bgp vulnerability? [ In reply to ]
Well I was not asking about operational workarounds - like MD5 And RFC 2827,
etc but rather about vendor's fixes like Checkpoint, IIJ, I'm sure cisco
will come up soon...

> -----Original Message-----
> From: Gert Doering [mailto:gert@greenie.muc.de]
> Sent: Tuesday, April 20, 2004 4:42 PM
> To: Dmitry Volkov
> Cc: 'Steve Francis'; 'Don Bowman'; cisco-nsp@puck.nether.net
> Subject: Re: [nsp] bgp vulnerability?
>
>
> Hi,
>
> On Tue, Apr 20, 2004 at 04:34:15PM -0400, Dmitry Volkov wrote:
> > I'm just wondering - because it's valid RFC 793 behavior,
> > how it can be avoided ?
> > by not complaining with RFC ?
> > If sequence number has to match exactly (but not in the
> window) - then there
> > may be
> > quite often situations when valid Reesets will not work
>
> Ignore all RSTs that do not carry a valid MD5 hash.
>
> Make sure that no packets with spoofed source addresses can
> enter or leave
> your network.
>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>
> //www.muc.de/~gert/
> Gert Doering - Munich, Germany
> gert@greenie.muc.de
> fax: +49-89-35655025
> gert@net.informatik.tu-muenchen.de
Re: [nsp] bgp vulnerability? [ In reply to ]
Hi,

On Tue, Apr 20, 2004 at 04:55:57PM -0400, Dmitry Volkov wrote:
> Well I was not asking about operational workarounds - like MD5 And RFC 2827,
> etc but rather about vendor's fixes like Checkpoint, IIJ, I'm sure cisco
> will come up soon...

A *real* vendor fix would be to completely decouple the control plane
from the forwarding plane.

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de
RE: [nsp] bgp vulnerability? [ In reply to ]
On Tue, 20 Apr 2004, Dmitry Volkov wrote:
> Well I was not asking about operational workarounds - like MD5 And RFC 2827,
> etc but rather about vendor's fixes like Checkpoint, IIJ, I'm sure cisco
> will come up soon...

Is there any good technique to guessing the source port, other than brute
force? It would seem that multiplies the search area an attacker must
guess. Is such an attack practical in that light?

-Dan
Re: [nsp] bgp vulnerability? [ In reply to ]
On Tue, Apr 20, 2004 at 11:00:30PM +0200, Gert Doering wrote:
> Hi,
>
> On Tue, Apr 20, 2004 at 04:55:57PM -0400, Dmitry Volkov wrote:
> > Well I was not asking about operational workarounds - like MD5 And RFC 2827,
> > etc but rather about vendor's fixes like Checkpoint, IIJ, I'm sure cisco
> > will come up soon...
>
> A *real* vendor fix would be to completely decouple the control plane
> from the forwarding plane.

You can run your iBGP in a vrf already, I assume you've
at least taken this level of securing your devices based on your
above statement :)

- jared

--
Jared Mauch | pgp key available via finger from jared@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: [nsp] bgp vulnerability? [ In reply to ]
On Tue, Apr 20, 2004 at 11:00:30PM +0200, Gert Doering wrote:
> Hi,
>
> On Tue, Apr 20, 2004 at 04:55:57PM -0400, Dmitry Volkov wrote:
> > Well I was not asking about operational workarounds - like MD5 And RFC 2827,
> > etc but rather about vendor's fixes like Checkpoint, IIJ, I'm sure cisco
> > will come up soon...
>
> A *real* vendor fix would be to completely decouple the control plane
> from the forwarding plane.

Lets hear some suggestions as to how to accomplish this!

(things like ipsec tunnels have been discussed prior, see
the last portland, oregon NANOG)

/vijay
Re: [nsp] bgp vulnerability? [ In reply to ]
* Dmitry Volkov (dmitry.volkov@rogers.com) wrote:
> [snipped and rearranged]

> Am I wrong here ?

Yes and no :-)

> I'm just wondering - because it's valid RFC 793 behavior,
> how it can be avoided ?

You are right in that it is valid behavior, so as such you can't avoid
it with plain tcp. You can do things however to either prevent the
packet getting to the router or prevent the spoofing from being considered
a valid packet (ie you increase the domain of the problem to such an
extent that brute forcing it is not feasable [1])

The options avaliable are:

1) Use a TCP `extension' called the MD5 Signature option.
This works by using a shared secret [password] by both parties
to compute an md5 hash of bits of the header and the secret.
The sending party sends the hash it computes in the packet
and the receiving party recalculates the hash and compares it.
If it doesn't match the packet is discarded.

This solution is increasing the domain of the values which
have to be right. It isn't a perfect solution, but probably
increases the domain sufficiently to make an attack unlikley
to succeed. [.This method has been hotley debated in some
quarters as to it breaking the TCP standard itself by making
reset too complicated, but that isn't an argument for here]

2) IPSec, Run the TCP session between the two BGP speakers over
IPSec, it is encrypted. This is probably the better technical
solution, but we don't all run and have no wish to run IPSec
versions of IOS on our routers.

3) Filter your core network. Only certain routers should be able
to speak with the BGP speaker, other traffic which `looks'
like BGP but is in the wrong place shuold be dropped. (eg
bits trying to enter the core at the wrong router)

4) Filter your access networks, While this isn't a solution to
the problem at all, people probably should be filtering access
networks to stop spoofed packets from ever entering your network
and even worse getting onto the internet at large. (okay some
times it is necessary, but they are the exception to the rule)
this would also help get DoS attacks onto grounds that we can
deal with, trace, etc., (again for another time)

5) Break TCP. Yes, while possible and even possibly excusable
you may deliberately missimplement the specification. Possibly
not the most prudent move in the world though.


These are most of your options, Because of licenses and people not wanting
to/cant use IPSec, md5 is the simplest and easiest solution for the time
being. However, 3 & 4 are certainally a very good idea and should be done
anyway.

Enjoy,

..david


[1] The exact analogy is key space in a cypher, you can pick out the key
from a 2^8 bit keyspace relatively easily by testing each combination,
where as with 2^128 bit keyspace you're starting to hit the heat death
of the universe before exhausting it.
RE: [nsp] bgp vulnerability? [ In reply to ]
hello,

looking glasses, with option to display the 'sh ip bgp ne' output are harmful


Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: x.x.x.x, Local port: 179
Foreign host: y.y.y.y, Foreign port: zzzzz

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x215F4C638):
Timer Starts Wakeups Next
Retrans 456927 1567 0x0
TimeWait 0 0 0x0
AckHold 421434 291415 0x0
SendWnd 1 0 0x0
KeepAlive 51 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0

iss: aaa snduna: bbb sndnxt: ccc sndwnd: ddd
irs: eee rcvnxt: fff rcvwnd: ggg delrcvwnd: hhh


rgds,
-zoltan



-----Original Message-----
From: Dan Hollis [mailto:goemon@anime.net]
Sent: Tuesday, April 20, 2004 11:05 PM
To: Dmitry Volkov
Cc: 'Gert Doering'; 'Steve Francis'; 'Don Bowman';
cisco-nsp@puck.nether.net
Subject: RE: [nsp] bgp vulnerability?


On Tue, 20 Apr 2004, Dmitry Volkov wrote:
> Well I was not asking about operational workarounds - like MD5 And RFC 2827,
> etc but rather about vendor's fixes like Checkpoint, IIJ, I'm sure cisco
> will come up soon...

Is there any good technique to guessing the source port, other than brute
force? It would seem that multiplies the search area an attacker must
guess. Is such an attack practical in that light?

-Dan

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Ez az üzenet és a hozzá kapcsolódó fájlok, tervezetek kizárólag a
Címzettnek szólnak, a bennük foglalt információk bizalmasak, melyek
titokban maradásához a Synergon Informatika Rt.-nek jogilag méltányolható
érdeke fuzodik. Amennyiben valamely hiba folytán Ön nem a címzettje ennek a
levélnek, kérjük, semmisítse meg, és értesítse az üzenet küldojét. Az
üzenet az elküldés elott vírusellenorzésen esett át, de a vírusmentességére
nincs semmilyen garancia, ezért kérjük, ellenorizze azt!

DISCLAIMER

This e-mail and any attached files are confidential and may be legally
privileged. The content of this e-mail is subject of efforts by Synergon to
maintain its confidentiality. Also this e-mail is intended for the sole use
of the individual or entity to whom it is addressed. If you are not the
addressee, and received this transmission in error please delete this
e-mail and notify its sender immediately. This e-mail message has been
checked for computer viruses but it could still be infected. Please test it
for viruses before use.
RE: [nsp] bgp vulnerability? [ In reply to ]
On Tue, 20 Apr 2004, Kinczli Zoltán wrote:
> looking glasses, with option to display the 'sh ip bgp ne' output are harmful

Attacking a looking glass connection is cute, but what does it accomplish?

Or is anyone actually routing important traffic *through* looking glass
routers?

-Dan
Re: [nsp] bgp vulnerability? [ In reply to ]
Hi,

On Tue, Apr 20, 2004 at 05:07:37PM -0400, Jared Mauch wrote:
> > A *real* vendor fix would be to completely decouple the control plane
> > from the forwarding plane.
>
> You can run your iBGP in a vrf already, I assume you've
> at least taken this level of securing your devices based on your
> above statement :)

Actually I haven't, as not all our boxes have the necessary feature set.

We have made sure, though, that packets with a source address that would
match one of the iBGP sessions can not enter our network (long ago
already). Plus MD5.

gert

--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de
RE: [nsp] bgp vulnerability? [ In reply to ]
Jared,

Sorry, maybe silly question:
What do You mean by "You can run your iBGP in a vrf already" ? -
to put all Internet RT in VRF ?? Is anyone actually doing this ?

Thanks,
Dmitry

> -----Original Message-----
> From: Jared Mauch [mailto:jared@puck.nether.net]
> Sent: Tuesday, April 20, 2004 5:08 PM
> To: Gert Doering
> Cc: Dmitry Volkov; 'Steve Francis'; cisco-nsp@puck.nether.net; 'Don
> Bowman'
> Subject: Re: [nsp] bgp vulnerability?
>
>
> On Tue, Apr 20, 2004 at 11:00:30PM +0200, Gert Doering wrote:
> > Hi,
> >
> > On Tue, Apr 20, 2004 at 04:55:57PM -0400, Dmitry Volkov wrote:
> > > Well I was not asking about operational workarounds -
> like MD5 And RFC 2827,
> > > etc but rather about vendor's fixes like Checkpoint, IIJ,
> I'm sure cisco
> > > will come up soon...
> >
> > A *real* vendor fix would be to completely decouple the
> control plane
> > from the forwarding plane.
>
> You can run your iBGP in a vrf already, I assume you've
> at least taken this level of securing your devices based on your
> above statement :)
>
> - jared
>
> --
> Jared Mauch | pgp key available via finger from jared@puck.nether.net
> clue++; | http://puck.nether.net/~jared/ My statements
> are only mine.
Re: [nsp] bgp vulnerability? [ In reply to ]
Hi,

On Wed, Apr 21, 2004 at 10:10:49AM +0300, Ilker YILMAZ wrote:
> How can i block RSTs that do not carry valid MD5 hash using
> access-lists, or is there a way to do that otherwise?

To be effective, the RSTs need to have a spoofed source address. While
you cannot filter on RST-without-MD5 explicitely, you don't have to -
switch on MD5 on your BGP sessions (so the router will automatically
ignore RST-without-MD5), and install proper anti-spoofing filters.

> Let's say that i
> provide customers internet access via my backbone and i'm talking bgp to
> my providers and want to secure this bgp updates?

Switch on MD5 towards your upstream providers.

Install an access-list on your upstream links that will reject packets
coming in with a source address belonging to your network. This way,
spoofed RSTs targeting your BGP links to your customers won't be able
to enter your network.

Install ACLs on your customer links, preventing packets with source
addresses not belonging to the customer from entering your network. This
way you protect everybody else. On single-homed customers and Cisco
gear, the easiest way is to enable "ip verify unicast reverse-path" on
all customer interfaces.

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de
[nsp] bgp vulnerability? [ In reply to ]
Hello,

Would someone explain where is the bug/issue? In the RFC itself or in
the implementation?
Before examining the cited cisco bugs, i had the feeling that the RST
handling algorithm itself is weak.

From the bug IDs, now i feel that IOS won't check the SEQ number, so
that not only valid (i.e. in-window) SEQ numbered RSTs can disrupt the
session. Moreover, not only RSTs are harmful, but SYNs as well.

If only the algorithm in RFC was weak, how could a vendor fix it?
According to Cisco Psirst postings there are fixed IOS versions, meaning
the implemntation differs from that of proposed in the RFC.

Thanks,
Attila
RE: [nsp] bgp vulnerability? [ In reply to ]
> -----Original Message-----
> From: BALLA Attila [mailto:atis@eik.bme.hu]
> Sent: Wednesday, April 21, 2004 9:06 AM
> To: cisco-nsp@puck.nether.net
> Subject: [nsp] bgp vulnerability?
>
> If only the algorithm in RFC was weak, how could a vendor fix it?
> According to Cisco Psirst postings there are fixed IOS
> versions, meaning
> the implemntation differs from that of proposed in the RFC.



While there have several excellent suggestions posted on this and other
lists, I don't think anyone has answered Attila's question directly.

Cisco has released fixed versions of IOS. What exactly has been fixed
in these new releases?

-michael
Re: [nsp] bgp vulnerability? [ In reply to ]
On Wed, Apr 21, 2004 at 12:13:05PM -0400, Michael Costello wrote:
> Cisco has released fixed versions of IOS. What exactly has been fixed
> in these new releases?

http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt

Sadly, they still don't randomize source ports though.


Regards,
Daniel
RE: [nsp] bgp vulnerability? [ In reply to ]
On Tue, 20 Apr 2004, Dan Hollis wrote:

> Attacking a looking glass connection is cute, but what does it accomplish?
>
> Or is anyone actually routing important traffic *through* looking glass
> routers?

Lots of people, just go browsing the many lg's out there!

Also, the LG will have peerings with core routers, theres some suggestion that
the knowledge of a largely irrelevant peering session can be used to attack the
peer router more successfully.

Steve
RE: [nsp] bgp vulnerability? [ In reply to ]
Jared,

Sorry, maybe silly question:
What do You mean by "You can run your iBGP in a vrf already" ? -
to put all Internet RT in VRF ?? Is anyone actually doing this ?

Thanks,
Dmitry

> -----Original Message-----
> From: Jared Mauch [mailto:jared@puck.nether.net]
> Sent: Tuesday, April 20, 2004 5:08 PM
> To: Gert Doering
> Cc: Dmitry Volkov; 'Steve Francis'; cisco-nsp@puck.nether.net; 'Don
> Bowman'
> Subject: Re: [nsp] bgp vulnerability?
>
>
> On Tue, Apr 20, 2004 at 11:00:30PM +0200, Gert Doering wrote:
> > Hi,
> >
> > On Tue, Apr 20, 2004 at 04:55:57PM -0400, Dmitry Volkov wrote:
> > > Well I was not asking about operational workarounds -
> like MD5 And RFC 2827,
> > > etc but rather about vendor's fixes like Checkpoint, IIJ,
> I'm sure cisco
> > > will come up soon...
> >
> > A *real* vendor fix would be to completely decouple the
> control plane
> > from the forwarding plane.
>
> You can run your iBGP in a vrf already, I assume you've
> at least taken this level of securing your devices based on your
> above statement :)
>
> - jared
>
> --
> Jared Mauch | pgp key available via finger from jared@puck.nether.net
> clue++; | http://puck.nether.net/~jared/ My statements
> are only mine.
RE: [nsp] bgp vulnerability? [ In reply to ]
On Thu, 22 Apr 2004, Stephen J. Wilcox wrote:
> Also, the LG will have peerings with core routers, theres some suggestion that
> the knowledge of a largely irrelevant peering session can be used to attack the
> peer router more successfully.

How, exactly?

-Dan
RE: [nsp] bgp vulnerability? [ In reply to ]
On Thu, 22 Apr 2004, Dan Hollis wrote:

> On Thu, 22 Apr 2004, Stephen J. Wilcox wrote:
> > Also, the LG will have peerings with core routers, theres some suggestion that
> > the knowledge of a largely irrelevant peering session can be used to attack the
> > peer router more successfully.
>
> How, exactly?

I'm not trying to exploit it so I'm not looking at the detail here :)

I gave one idea in "Re: [nsp] bgp vulnerability, just note" .. that the LG can
be used to find out details about the iBGP setup (IPs of loopbacks, ports etc)
and you can learn a lot about a previously unknown core router...

I'm sure theres other things you can do if you spend time thinking :)

Steve
RE: [nsp] bgp vulnerability? [ In reply to ]
Hi!

You may find this presentation useful.

Cisco PSIRT TCP Q&A
http://www.cansecwest.com/csw04/csw04-Ahlawat.ppt

Sergio.

> -----Original Message-----
> From: Michael Costello [mailto:mikeco@corp.ptd.net]
> Sent: 21 April 2004 18:13
> To: cisco-nsp@puck.nether.net
> Subject: RE: [nsp] bgp vulnerability?

> > -----Original Message-----
> > From: BALLA Attila [mailto:atis@eik.bme.hu]
> > Sent: Wednesday, April 21, 2004 9:06 AM
> > To: cisco-nsp@puck.nether.net
> > Subject: [nsp] bgp vulnerability?
> >
> > If only the algorithm in RFC was weak, how could a vendor fix it?
> > According to Cisco Psirst postings there are fixed IOS
> > versions, meaning
> > the implemntation differs from that of proposed in the RFC.
>
> While there have several excellent suggestions posted on this and other
> lists, I don't think anyone has answered Attila's question directly.
>
> Cisco has released fixed versions of IOS. What exactly has been fixed
> in these new releases?
>
> -michael

1 2  View All