From: John Matus (jmatus@pacbell.net)
Date: Fri May 06 2005 - 01:39:55 GMT-3
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
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Jun 03 2005 - 10:11:56 GMT-3