From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Thu Oct 14 2004 - 07:00:19 GMT-3
Brian,
the "authentication" commands in R2 are the identity tokens
(password/secret) that are in both of your examples in R2 config!
Default authentication is "authenticate if needed" so to say, both ways.
R1 in your example requires R2 to authenticate.
I was just curious about what you call a "two way process".
Authentication is a security function about a peer. PAP and CHAP are
implementations, and I would say PAP is a "one way process" because the
one who wants to be authenticated provides credentials and that's it.
CHAP, on the other hand, I would call two way, because the one
requesting authentication chalenges the other party, and the response is
the authentication. Response, per se, implies a two way process...
All in all, I would say that in ppp all authentication are two way
processes, because the authenticating peer requests the other to
authenticate...
I guess the whole confusion for me was the use of "process" in your
statement.
Brian McGahan wrote:
> Tim,
>
> Ummm... interesting story, but here is what I really meant ;)
> Below are PAP and CHAP configs for routers R1 and R2 connected via a PPP
> link with R1 authenticating R2:
>
> PAP
> ---
> R1:
> username R2 password PAPPASS
> !
> interface PPPLINK
> ppp authentication pap
>
> R2:
> interface PPPLINK
> ppp pap sent-username R2 password PAPPASS
>
>
> CHAP
> ----
> R1:
> username R2 password CHAPPASS
> !
> interface PPPLINK
> ppp authentication chap
>
> R2:
> username R1 password CHAPPASS
>
>
>
> Where are the "ppp authentication" commands on R2? Why does
> this work?
>
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
>
>
>>-----Original Message-----
>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
>
> Of
>
>>ccie2be
>>Sent: Wednesday, October 13, 2004 5:39 PM
>>To: Carlos G Mendioroz; Brian McGahan
>>Cc: Gene Thorne; ccielab@groupstudy.com
>>Subject: Re: Something New (the myths we believe)
>>
>>Assume r1 and r2 are connected via ppp (could be isdn, but it doesn't
>
> have
>
>>to be).
>>
>>You can configure ppp authentication on r1 but not configure
>>authentication
>>on r2. If you do this, r2 has to authenticate before it can
>
> communicate
>
>>with R1, but r1 doesn't have to authenticate with r2 to communicate
>
> with
>
>>it.
>>
>>Think of it like this.
>>
>>Suppose you go to a free standing ATM machine in some mall somewhere
>
> to
>
>>take
>>out some cash. You put your card in the slot and the atm machine
>
> tells
>
>>you
>>to enter your pin, so you do.
>>
>>Then you get a message saying something like, "Sorry, but we can't
>
> reach
>
>>your bank to authenticate your identity. Please try again later."
>>
>>Quite possibly you have become a victim of a fraud. That ATM machine
>>"authenticated" you by getting your card # and pin, but you didn't get
>>your
>>cash. And, even worse, in about 5 minutes your bank account is clean
>>out.
>>
>>All because you didn't authenticate that atm before giving up your
>
> pin.
>
>>HTH, Tim
>>----- Original Message -----
>>From: "Carlos G Mendioroz" <tron@huapi.ba.ar>
>>To: "Brian McGahan" <bmcgahan@internetworkexpert.com>
>>Cc: "Gene Thorne" <gthorne@netcogov.com>; <ccielab@groupstudy.com>
>>Sent: Wednesday, October 13, 2004 6:01 PM
>>Subject: Re: Something New (the myths we believe)
>>
>>
>>
>>>What do you mean by ppp authentication not being a two way process ?
>>>
>>>
>>>Brian McGahan wrote:
>>>
>>>
>>>>Better yet that you can't remove a line out of a numbered
>
> access-list
>
>>>>without destroying and recreating the entire list. (you can)
>>>>
>>>>"no arp frame-relay" stops inverse-arp replies (it doesn't)
>>>>
>>>>ppp authentication is a two way process (it's not)
>>>>
>>>>Don't start listing these behaviors as "gotchas" though, they
>>>>are simply technologies that the fundamental behaviors are
>>>>misunderstood. Most of these "myths" can be eliminated by simply
>>
>>trying
>>
>>>>the configuration out and seeing how it works firsthand on the
>
> command
>
>>>>line.
>>>>
>>>>Brian McGahan, CCIE #8593
>>>>bmcgahan@internetworkexpert.com
>>>>
>>>>Internetwork Expert, Inc.
>>>>http://www.InternetworkExpert.com
>>>>Toll Free: 877-224-8987 x 705
>>>>Outside US: 775-826-4344 x 705
>>>>24/7 Support: http://forum.internetworkexpert.com
>>>>Live Chat: http://www.internetworkexpert.com/chat/
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
>
> Behalf
>
>>>>Of
>>>>
>>>>
>>>>>Gene Thorne
>>>>>Sent: Wednesday, October 13, 2004 12:12 PM
>>>>>To: ccielab@groupstudy.com
>>>>>Subject: RE: Something New (the myths we believe)
>>>>>
>>>>>My favorite myth is that static routes pointing to an interface
>
> have
>
>>>>an
>>>>
>>>>
>>>>>admin distance of 0, not 1.
>>>>>
>>>>>-----Original Message-----
>>>>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
>
> Behalf Of
>
>>>>>Joe Rinehart
>>>>>Sent: Wednesday, October 13, 2004 12:02 PM
>>>>>To: ccielab@groupstudy.com
>>>>>Subject: Something New (the myths we believe)
>>>>>
>>>>>
>>>>>Just when you think you have things halfway figured out you
>
> realize
>
>>>>how
>>>>
>>>>
>>>>>far
>>>>>off your perceptions can be. I had two "revelations" while
>
> working on
>
>>>>the
>>>>
>>>>
>>>>>Netmaster DoIt lab #1 (its pretty grueling, in a good way). There
>>>>
>>>>were
>>>>
>>>>
>>>>>two
>>>>>things that really bit me because I thought I knew these for
>>>>
>>>>certain....
>>>>
>>>>
>>>>>Myth#1 A Catalyst 3550 cannot do BGP.
>>>>>
>>>>>When the lab asked for this I thought it was a joke, and to be
>
> honest
>
>>>>I
>>>>
>>>>
>>>>>cannot remember where I picked this idea up, but a quick check on
>
> the
>
>>>>doc
>>>>
>>>>
>>>>>CD
>>>>>and I found my face turning red (proverbially speaking). I think
>
> I
>
>>>>was
>>>>
>>>>
>>>>>relying on a "features not supported" on one of the CCIE Cisco
>
> Press
>
>>>>study
>>>>
>>>>
>>>>>books... In any case there are some limitations but it does
>
> indeed
>
>>>>>support
>>>>>BGP....
>>>>>
>>>>>Myth#2 Subinterfaces cannot coexist with natural interfaces on the
>>>>
>>>>same
>>>>
>>>>
>>>>>physical interface.
>>>>>
>>>>>This one blew me away. When I read the question I figured it was
>
> one
>
>>>>of
>>>>
>>>>
>>>>>those "trick answers" that just had to be interpreted, so I did a
>>>>>multipoint
>>>>>subinterface and a point to point subinterface. When I was
>
> working
>
>>>>though
>>>>
>>>>
>>>>>the answer key I was rather taken aback to see that it was on the
>>>>
>>>>physical
>>>>
>>>>
>>>>>interface. Still a skeptic, I removed the multipoint
>
> subinterface,
>
>>>>put
>>>>
>>>>
>>>>>the
>>>>>code on the main interface (leaving the P2P subif) and then
>
> reloaded
>
>>>>the
>>>>
>>>>
>>>>>router. I was shocked it worked.
>>>>>
>>>>>I think my reason for posting this is just to see if there have
>
> been
>
>>>>any
>>>>
>>>>
>>>>>other experiences like this for other folks and what those
>
> assumptions
>
>>>>>were.
>>>>>After all, there is a saying about assume.....
>>>>>
>>>>>Joe Rinehart, CCNP, CCDP
>>>>>Data Network Consultant, AT&T Corporation
>>>>>Pacific Northwest Enterprise Markets
>>>>>
>>>>>
>>>>
>>>>
> _______________________________________________________________________
>
>>>>>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
>>>>
>>>
>>>--
>>>Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
>>>
>>>
>
> _______________________________________________________________________
>
>>>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
>
>
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:47 GMT-3