I was hoping that the minutes/discussion notes from the IDR working group
was going
to be made available on the web or through a list-server. I briefly read
through Sandra
Murphy's Draft and based on security model(for origination/adjacency
protection), it sounds somewhat like the model in place for ssl based
security.
I have been reading William Stallings "Cryptography and Network Security"
and he
makes some of what I think (having limited knowledge) are some good
suggestions in
appending the information (key or signatures) of peers to the FCS. His
example draw
upon peer-to-peer connections, which allows the TCP header to become a
another level
of security based on it's ability to sequence packets and it's use of a
checksum
Stallings also addresses another issue mentioned in Sandra Murphy's Draft
known to
MD5, collisions. Based on the performance issues with implementing
suitable security
for the information exchanged between peers are there currently any
discussions on
possibly implementing any other forms of security beyond MD5 and IPSec.
Nigel
----- Original Message -----
From: "Howard C. Berkowitz"
To:
Sent: Friday, December 21, 2001 11:27 AM
Subject: Re: Latest Hackers Target: Routers [7:29844]
> >Chuck and Andreas,
> > I take note on the fact that
authentication
> >can add major increases to the time taken in forming neighbor peer
> >relationships. Yes, MD5 based authentication as I suggested in my
original
> >post is currently the operational model, but it was noted in rfc 2385
that
> >the MD5 was considered weak.
> >
> >Nigel .
> >
> >I guess this issue just spells out MPLS/VPN...
>
>
> But MPLS inherently offers no more security than BGP. RFC2547 and
> RFC2547 bis, as well as several other proposals, use BGP to
> distribute reachability information. The various link setup
> protocols have no particular security.
>
> The problem becomes more tractable if you look at the main place for
> security, QoS, etc., being at the edge. If a hacker has managed to
> crack a major interprovider link or a major core link, you have even
> more serious problems with sniffing.
>
> Encrypting, even with IPsec, the connections from customers to their
> first upstream is much more feasible. Most customers don't get full
> routes anyway. Other precautions can be used at the edge, such as
> ingress filtering of source addresses/unicast reverse path
> verification, peer count limits, and traffic shaping directed against
> DoS attacks.
>
> There is a current discussion in the IDR working group that
> resurrects and updates Sandy Murphy's BGP security analysis.
>
> Not a very first step, but in the BMWG work on BGP convergence, we do
> plan to have an option for measuring the overhead of MD5.
>
> >
> >
> >----- Original Message -----
> >From: "Chuck Larrieu"
> >To:
> >Sent: Friday, December 21, 2001 3:16 AM
> >Subject: RE: Latest Hackers Target: Routers [7:29844]
> >
> >
> >> I know from my studies that there is BGP neighbor md5 authentication.
> >>
> >> Somewhere in my reading I seem to recall that employing authentication
> can
> >> add 50-100% to the time it takes a neighbor relationship to form. Fine
> for
> >> lab work. maybe not so fine in the world of the production ISP.
> >>
> >> phrak, this is all we need. ISP's start preventing BGP packets from
any
> >but
> >> known and trusted sources to cross their networks and there go the
> >internet
> >> BGP practice labs.
> >>
> >> damn anarchists.
> >>
> >> Chuck
> >>
> >> -------
> >> neighbor password
> >> To enable Message Digest 5 (MD5) authentication on a TCP connection
> >between
> >> two Border Gateway Protocol (BGP) peers, use the neighbor password
router
> >> configuration command. To disable this function, use the no form of
this
> >> command.
> >>
> >> neighbor {ip-address | peer-group-name} password string
> >> -------
> >>
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> >> Andras Bellak
> >> Sent: Thursday, December 20, 2001 9:59 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: RE: Latest Hackers Target: Routers [7:29844]
> >>
> >>
> >> Nigel-
> >>
> >> If you dig back through the NANOG archives, there was a rather in
depth
> >> and discouraging discussion of encrypting / authorizing BGP session
> >> neighbors. The general result was that almost nobody supported it, and
> >> many in the ISP groups that offer BGP connectivity didn't even know
what
> >> it was.
> >>
> >> While it might or might not be on the CCIE exams, having some form of
> >> authentication between routing partners is a good thing to practice in
> >> your test labs, and put into production in your networks.
> >>
> >> Andras
> >>
> >> -----Original Message-----
> >> From: Nigel Taylor [mailto:[EMAIL PROTECTED]]
> >> Sent: Thursday, December 20, 2001 8:33 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: Latest Hackers Target: Routers [7:29844]
> >>
> >>
> >> Chuck,
> >> Yes, I got the thread on this today and forwarded a copy
to
> >> some of my co-workers. I hope folks are making use of the various IOS
> >> implementations to limit the damage done by a prospective attacker.
> >> Things
> >> like CBAC, rate-limit could go a long way in simply providing the
needed
> >> time to identify a serious attack and implement more specific
filtering
> >> techniques to identify or completely block the attacker.
> >>
> >> As it applies to the sniffing of BGP packets to gain route
information,
> > > I
> >> was wondering where do things stand now on the implementation of
> >> encrypted
> >> authentication within BGP. If I'm not mistaken, isn't this suppose to
> >> happen along with support for IPv6. This document references
> >> authentication which sounds like the existing support for MD5 based
> >> authentication.
> >>
> >> http://search.ietf.org/internet-drafts/draft-ietf-idr-bgp4-16.txt (pg
> >> 9(a) )
> >>
> >>
> >> Now this document does seem to address current issues with respects to
> >> the
> >> flaws/vulnerabilities inherent to all TCP based protocols. The
important
> >> thing to note is this can be done without the presence of a MPLS aware
> >> backbone based on the model identified by RFC2547bis (MPLS/VPN).
> >>
> >>
http://search.ietf.org/internet-drafts/draft-declercq-bgp-ipsec-vpn-01.t
> >> xt
> >>
> >>
> >> Thoughts anyone..
> >>
> >> Nigel .
> >>
> >> ----- Original Message -----
> >> From: "Chuck Larrieu"
> >> To:
> >> Sent: Thursday, December 20, 2001 10:14 PM
> >> Subject: RE: Latest Hackers Target: Routers [7:29810]
> >>
> >>
> >> > anyone see a thread about this on NANOG today? The archives are not
up
> >> to
> >> > date with today's topics.
> >> >
> >> > Chuck
> >> >
> >> > -----Original Message-----
> >> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
Of
> >> > Eric Rogers
> >> > Sent: Thursday, December 20, 2001 1:29 PM
> >> > To: [EMAIL PROTECTED]
> >> > Subject: OT: Latest Hackers Target: Routers [7:29810]
> >> >
> >> >
> >> > Paste into your browser:
> >> >
> >> > dailynews.yahoo.com/h/cmp/20011217/tc/inw20011217s0004_1.html
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=29917&t=29917
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
