From: Brian Dennis (bdennis@internetworkexpert.com)
Date: Fri May 06 2005 - 09:53:27 GMT-3
Tim,
In regards to the first question, the task does not say "use a
solution that will not involve someone possibly calling the helpdesk".
The point is that the neighbor command alone will not ensure only one
device receives the RIP update over a medium like Ethernet.
In regards to your second question, I'll give you a quote from
RFC 2028 "RIPv2 MD5 Authentication":
<RFC 2028>
The mechanism does not afford confidentiality, since messages stay in
the
clear; however, the mechanism is also exportable from most countries,
which test a privacy algorithm would fail.
</RFC 2028>
Here is a quote from RFC 2328 "OSPF Version 2":
<RFC 2328>
None of the OSPF authentication types provide confidentiality. Nor
do they protect against traffic analysis.
</RFC 2328>
Routing protocol authentication (RIPv2, OSPFv2, etc) is not
encrypting the routing updates. The routing updates are sent in the
clear even if authentication is used. The reason is that routing
protocol authentication is designed to provide authentication and packet
integrity but not confidentiality.
If regards to your statement "I thought MD5 is an encryption
algorithm and as such DOES provide confidentiality". I would highly
recommend that you look up MD5 and see what it actually is and does:
http://en.wikipedia.org/wiki/MD5
http://en.wikipedia.org/wiki/Cryptographic_hash_function
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Friday, May 06, 2005 5:09 AM
To: Brian Dennis; 'John Matus'; 'Group Study'
Subject: RE: Preventing rogue hosts from intercepting rip packets
Hi Brian,
That post was a real eye opener. Thanks for that contribution.
However, you say 2 things which should raise eyebrows.
"R2 (the rogue device)has applied the same IP address as R1 and is
receiving
the RIP updates along with R1."
and
"Remember that MD5 authentication provides authentication and packet
integrity but not confidentiality."
In the first remark, you're talking about duplicate ip addresses - a
definite no-no. Wouldn't that become almost immediately because people
would start calling the help desk complaining about reachability?
Re: your 2nd remark. I thought MD5 is an encryption algorithm and as
such
DOES provide confidentiality. What am I missing?
TIA, Tim
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian Dennis
Sent: Friday, May 06, 2005 1:22 AM
To: John Matus; Group Study
Subject: RE: Preventing rogue hosts from intercepting rip packets
John,
First off this will not work as outbound ACL's will not affect
traffic sourced by the router (by default). Secondly it makes more
sense to use the passive-interface default command along with a neighbor
statement if you only want to send RIP updates to certain neighbors.
Lastly I'll add that the neighbor statement does not guarantee that only
the intended neighbor will receive the RIP updates. Let me demonstrate
this issue:
We have three routers running RIPv2 in the same VLAN. R4 has a
neighbor command pointing to R1 (155.1.146.1). R2 (the rogue device)
has applied the same IP address as R1 and is receiving the RIP updates
along with R1.
Rack1R4#sho run | be router rip
router rip
version 2
passive-interface default
network 155.1.0.0
neighbor 155.1.146.1
no auto-summary
Rack1R1#sho ip int brie e0/0
Interface IP-Address OK? Method Status
Protocol
Ethernet0/0 155.1.146.1 YES manual up up
Rack1R1#
Rack1R1#sho ip rout rip
155.1.0.0/24 is subnetted, 2 subnets
R 155.1.44.0 [120/1] via 155.1.146.4, 00:00:18, Ethernet0/0
Rack1R1#
Rack1R2#sho ip int brie e0/0
Interface IP-Address OK? Method Status
Protocol
Ethernet0/0 155.1.146.1 YES manual up up
Rack1R2#
Rack1R2#sho ip rout rip
155.1.0.0/24 is subnetted, 4 subnets
R 155.1.44.0 [120/1] via 155.1.146.4, 00:00:29, Ethernet0/0
Rack1R2#
So does the neighbor command alone stop a rogue device from
receiving the RIP updates? You could use the neighbor command and a
static ARP entry on R4 (R1's MAC/R1's IP address). This would be a more
secure solution since R2 or any other device would never receive RIP
updates sourced by R4 destined for R1. Taking it one step further you
could add a static MAC address entry on the 3550 for R1 so that another
device never hijacks its MAC address.
Technically authentication by itself does not meet the
requirements since the packets themselves are still sent in the clear.
This means a rogue device could still receive the updates and
technically view the updates. But that device could not authenticate
the updates and could not alter them in order to resent them. Remember
that MD5 authentication provides authentication and packet integrity but
not confidentiality. So in this situation I would add authentication
even though it does not stop a rogue device from receiving the updates.
Of course we may be starting to out thinking the question but I
just wanted to point out that the neighbor command alone doesn't really
meet the requirements. In the real CCIE lab do not out think the
question like this and go with the option you believe the developer of
the lab intended (neighbor statement along with authentication).
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
John Matus
Sent: Thursday, May 05, 2005 9:40 PM
To: Jim; Sean C; Edwards, Andrew M; Shaikh, Nasir; ccie2be; Group Study
Subject: Re: Preventing rogue hosts from intercepting rip packets
couldn't you do something like the following so that rip packets are
only
sent to inteded recipients?
r1 = 150.1.1.1 r2 = 150.1.2.2
ip access-list extended security
permit udp host 150.1.1.1 host 150.1.2.2 eq rip
deny udp any any eq rip
permit ip any any
int e0/0
ip access-group security out
Regards,
John D. Matus
MCSE, CCNP
Office: 818-782-2061
Cell: 818-430-8372
jmatus@pacbell.net
----- Original Message -----
From: "Jim" <nhatquang@thiennam.org>
To: "Sean C" <Upp_and_Upp@hotmail.com>; "Edwards, Andrew M"
<andrew.m.edwards@boeing.com>; "Shaikh, Nasir"
<Nasir.Shaikh@atosorigin.com>; "ccie2be" <ccie2be@nyc.rr.com>; "Group
Study"
<ccielab@groupstudy.com>
Sent: Thursday, May 05, 2005 6:52 PM
Subject: Re: Preventing rogue hosts from intercepting rip packets
> since hackers can cheat or simulate chap session if they have enough
> access to
> the topology, it is not impossible
> to play something fun with 3 ways authentication sessions. If the task
> requires preventing rogue hosts from intercepting routing packets,
> I might use unicast update instead of multicasting routing packets
over
> shared
> medias such as LAN, FR or ATM. Another useful way to prevent
> intercepting is compression. I see that, sometimes, the task wording
> requires
> compression other than authentication or p2p session.
>
> HTH, Jim.
>
>
> ----- Original Message -----
> From: Sean C
> To: Edwards, Andrew M ; Shaikh, Nasir ; ccie2be ; Group Study
> Sent: Friday, May 06, 2005 5:53 AM
> Subject: Re: Preventing rogue hosts from intercepting rip packets
>
>
> I agree with Andrew on this one. Setting authentication won't stop a
> rogue
> host from intercepting the packets, albeit the packets will be
encrypted,
> but they'll still be intercepted. Sending the packets to a unicast
> address
> instead of a multicast and using passive ints, that will prevent the
> rogue
> host from intercepting the packets.
>
> HTH, Sean
> ----- Original Message -----
> From: "Edwards, Andrew M" <andrew.m.edwards@boeing.com>
> To: "Shaikh, Nasir" <Nasir.Shaikh@atosorigin.com>; "ccie2be"
> <ccie2be@nyc.rr.com>; "Group Study" <ccielab@groupstudy.com>
> Sent: Thursday, May 05, 2005 5:37 PM
> Subject: RE: Preventing rogue hosts from intercepting rip packets
>
>
> > Interesting...
> >
> > My inclination is towards passive default and neighbor commands.
> Either
> > RIP 1 or 2 will cause a switch to forward frames out all ports
(e.g.
> > broadcast and multicast) not received. So, to prevent rogue hosts
from
> > intercepting rip packets in general I would opt to unicast my
updates.
> >
> > I would think authentication would be a secondary concern.
> >
> > But, knowing this lab... Do both!~
> >
> > -----Original Message-----
> > From: Shaikh, Nasir [mailto:Nasir.Shaikh@atosorigin.com]
> > Sent: Thursday, May 05, 2005 11:28 AM
> > To: ccie2be; Group Study
> > Subject: RE: Preventing rogue hosts from intercepting rip packets
> >
> >
> > Tim,
> > I believe the requirement is asking for authentication. So method 1
(I
> > guess you mean passive interface) does not suffice. I would go for
> > method 2
> > and if the requirements of the task allow then combine method 1 and
2
> >
> > greetz
> > Nash
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf
Of
> > ccie2be
> > Sent: donderdag 5 mei 2005 16:00
> > To: Group Study
> > Subject: Preventing rogue hosts from intercepting rip packets
> >
> >
> > Hi guys,
> >
> > To achieve the above requirement which method do you think is
better?
> > If you think one method is better than another, do you also think
the
> > less preferred method would be considered wrong in the lab?
> >
> > Method 1
> >
> > use default interface and neighbor combo or
> >
> > Method 2
> >
> > use authentication on the links involved or
> >
> > Method 3
> >
> > Use both Method 1 and Method 2
> >
> > TIA, Tim
> >
> >
This archive was generated by hypermail 2.1.4 : Fri Jun 03 2005 - 10:11:56 GMT-3