My understanding is irrelevant, really, as I fully understand how it
works. But as I wrote in my message - I think it's important to
understand that OSPF authentication is a 2-stage process when
troubleshooting problems.
-- Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor - IPexpert On Sun, Mar 11, 2012 at 11:49, Narbik Kocharians <narbikk_at_gmail.com> wrote: > I don't think anyone took cheap shots, read this and tell me what your > understanding is: > > > This is what the RFC (2328 page 227) states, it clearly states that there is > no authentication: > > > > > > B B B D.1 Null authentication > > > > B B B B B B B Use of this authentication type means that routing exchanges > > B B B B B B B over the network/subnet are not authenticated.B The 64-bit > > B B B B B B B authentication field in the OSPF header can contain anything; it > > B B B B B B B is not examined on packet reception. When employing Null > > B B B B B B B authentication, the entire contents of each OSPF packet (other > > B B B B B B B than the 64-bit authentication field) are checksummed in order > > B B B B B B B to detect data corruption. > > > On Sun, Mar 11, 2012 at 11:17 AM, Marko Milivojevic <markom_at_ipexpert.com> > wrote: >> >> In fact, if you wanted to simplify the things, that's exactly how it >> should be understood. >> >> -- >> Marko Milivojevic - CCIE #18427 (SP R&S) >> Senior CCIE Instructor - IPexpert >> >> On Sun, Mar 11, 2012 at 10:37, Paul Negron <negron.paul_at_gmail.com> wrote: >> > Brian, >> > >> > If null is the type and "0"is technically the value. >> > >> > Then is it true that we have 5 types of authentication...TECHNICALLY? >> > >> > >> > Null- with value 0 >> > Simple password - with no value >> > Simple Password- with value >> > Cryptographic- with no value >> > Cryptographic- with value >> > >> > This would confuse the issue considerably with everything written on the >> > subject. >> > >> > Paul >> > >> > -- >> > Paul Negron >> > CCIE# 14856 CCSI# 22752 >> > Senior Technical Instructor >> > >> > >> > >> >> From: Brian McGahan <bmcgahan_at_ine.com> >> >> Reply-To: Brian McGahan <bmcgahan_at_ine.com> >> >> Date: Sun, 11 Mar 2012 10:49:36 -0500 >> >> To: Narbik Kocharians <narbikk_at_gmail.com> >> >> Cc: Aaron <aaron1_at_gvtc.com>, CCIE GROUPSTUDY <ccielab_at_groupstudy.com> >> >> Conversation: ospf authentication >> >> Subject: Re: ospf authentication >> >> >> >> This isn't saying what you're saying: http://goo.gl/SmxY2 >> >> >> >> >> >> Brian McGahan, CCIE #8593 (R&S/SP/Security) >> >> bmcgahan_at_INE.com<mailto:bmcgahan_at_INE.com> >> >> >> >> Internetwork Expert, Inc. >> >> http://www.INE.com >> >> >> >> On Mar 11, 2012, at 3:33 AM, "Narbik Kocharians" >> >> <narbikk_at_gmail.com<mailto:narbikk_at_gmail.com>> wrote: >> >> >> >> Brian, >> >> >> >> This is not saying what you are stating: >> >> >> >> >> >> http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a >> >> 0080094069.shtml >> >> >> >> On Sat, Mar 10, 2012 at 11:56 PM, Brian McGahan >> >> <bmcgahan_at_ine.com<mailto:bmcgahan_at_ine.com>> wrote: >> >> Technically NULL authentication means you are authenticating with any >> >> arbitrary string. B If you read the OSPF specification >> >> (http://www.ietf.org/rfc/rfc2328.txt) is gives more detail: >> >> >> >> D. Authentication >> >> >> >> B B All OSPF protocol exchanges are authenticated. B The OSPF packet >> >> B B header (see Section A.3.1) includes an authentication type field, >> >> B B and 64-bits of data for use by the appropriate authentication scheme >> >> B B (determined by the type field). >> >> >> >> B B The authentication type is configurable on a per-interface (or >> >> B B equivalently, on a per-network/subnet) basis. B Additional >> >> B B authentication data is also configurable on a per-interface basis. >> >> >> >> B B Authentication types 0, 1 and 2 are defined by this specification. >> >> B B All other authentication types are reserved for definition by the >> >> B B IANA (iana_at_ISI.EDU<mailto:iana_at_ISI.EDU>). B The current list of >> >> authentication types is >> >> B B described below in Table 20. >> >> >> >> >> >> >> >> B B B B B B B B B AuType B B B Description >> >> B B B B B B B B B ___________________________________________ >> >> B B B B B B B B B 0 B B B B B B Null authentication >> >> B B B B B B B B B 1 B B B B B B Simple password >> >> B B B B B B B B B 2 B B B B B B Cryptographic authentication >> >> B B B B B B B B B All others B Reserved for assignment by the >> >> B B B B B B B B B B B B B B B IANA (iana_at_ISI.EDU<mailto:iana_at_ISI.EDU>) >> >> <snip> >> >> >> >> "NULL" authentication is technically not "no" authentication, but in >> >> reality >> >> it means the same thing. B The key point is that there is a difference >> >> between >> >> then negotiation of the authentication *type* and the authentication >> >> *key*. >> >> >> >> Both the authentication types and keys can be NULL. B Even though "NULL" >> >> is a >> >> zero value, it still counts as a value. B This is why if you configure >> >> two >> >> routers to authenticate each other with MD5 (Type 2) authentication, >> >> but don't >> >> set the key, it still works. B This is because they have agreed on >> >> Authentication Type 2 (MD5) and Authentication Key NULL. >> >> >> >> >> >> HTH, >> >> >> >> Brian McGahan, CCIE #8593 (R&S/SP/Security) >> >> bmcgahan_at_INE.com<mailto:bmcgahan_at_INE.com> >> >> >> >> Internetwork Expert, Inc. >> >> http://www.INE.com >> >> >> >> -----Original Message----- >> >> From: nobody_at_groupstudy.com<mailto:nobody_at_groupstudy.com> >> >> [mailto:nobody_at_groupstudy.com<mailto:nobody_at_groupstudy.com>] On Behalf >> >> Of >> >> Narbik Kocharians >> >> Sent: Saturday, March 10, 2012 10:24 PM >> >> To: Aaron >> >> Cc: Joe Astorino; CCIE GROUPSTUDY >> >> Subject: Re: ospf authentication >> >> >> >> Aaron, >> >> >> >> Remember that the "Ip ospf authentication null" is the command that is >> >> used to >> >> *disable* authentication. OSPF authentication can either be none (Or as >> >> Brian >> >> called it Null), simple or MD5. The authentication method none (Null), >> >> means >> >> that you have *no* authentication. >> >> >> >> >> >> On Sat, Mar 10, 2012 at 5:36 PM, Aaron >> >> <aaron1_at_gvtc.com<mailto:aaron1_at_gvtc.com>> wrote: >> >> >> >>> But that's where it was weird (unless I'm not understanding what you >> >>> are saying). >> >>> >> >>> I did this >> >>> >> >>> Router ospf 1 >> >>> Area 0 auth messag >> >>> >> >>> r6(config-subif)#do sh ip osp | in auth >> >>> B B B B Area has message digest authentication >> >>> >> >>> and it seems that even with that turned on I can neighbor up with >> >>> routers and I don't even have to provide a md5 password anywhere. B Is >> >>> that called type 0, 1, or 2? B I'm getting the impression that what >> >>> I've done was a half-baked type 2. B In other words it ain't truly type >> >>> 2 md5 auth until the int config "ip osp mess 1 md5 cisco" is applied. >> >>> B True? >> >>> >> >>> Aaron >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: Joe Astorino >> >>> [mailto:joeastorino1982_at_gmail.com<mailto:joeastorino1982_at_gmail.com>] >> >>> Sent: Saturday, March 10, 2012 7:24 PM >> >>> To: Aaron; CCIE GROUPSTUDY >> >>> Subject: Re: ospf authentication >> >>> >> >>> There are 3 types >> >>> >> >>> NULL, Clear text and MD5. So technically it can work without a >> >>> password using NULL authentication type >> >>> >> >>> >> >>> >> >>> On 3/10/12, Aaron <aaron1_at_gvtc.com<mailto:aaron1_at_gvtc.com>> wrote: >> >>>> Isn't it weird that ospf authentication works even without a >> >>>> password? >> >>>> >> >>>> >> >>>> >> >>>> I enabled area 0 authentication and it works, even before I ever >> >>>> specify a password anywhere. >> >>>> >> >>>> >> >>>> >> >>>> Aaron >> >>>> >> >>>> >> >>>> Blogs and organic groups at http://www.ccie.net >> >>>> >> >>>> ____________________________________________________________________ >> >>>> __ _ Subscription information may be found at: >> >>>> http://www.groupstudy.com/list/CCIELab.html >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >>> -- >> >>> Sent from my mobile device >> >>> >> >>> Regards, >> >>> >> >>> Joe Astorino >> >>> CCIE #24347 >> >>> http://astorinonetworks.com >> >>> >> >>> "He not busy being born is busy dying" - Dylan >> >>> >> >>> >> >>> Blogs and organic groups at http://www.ccie.net >> >>> >> >>> ______________________________________________________________________ >> >>> _ Subscription information may be found at: >> >>> http://www.groupstudy.com/list/CCIELab.html >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >> >> >> >> >> -- >> >> *Narbik Kocharians >> >> *CCSI#30832, CCIE# 12410 (R&S, SP, Security) >> >> *www.MicronicsTraining.com<http://www.MicronicsTraining.com>* >> >> <http://www.micronicstraining.com/> >> >> Sr. Technical Instructor >> >> YES! We take Cisco Learning Credits! >> >> Training & Remote Racks available >> >> >> >> >> >> Blogs and organic groups at http://www.ccie.net >> >> >> >> _______________________________________________________________________ >> >> Subscription information may be found at: >> >> http://www.groupstudy.com/list/CCIELab.html >> >> >> >> >> >> Blogs and organic groups at http://www.ccie.net >> >> >> >> _______________________________________________________________________ >> >> Subscription information may be found at: >> >> http://www.groupstudy.com/list/CCIELab.html >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Narbik Kocharians >> >> CCSI#30832, CCIE# 12410 (R&S, SP, Security) >> >> www.MicronicsTraining.com<http://www.micronicstraining.com/> >> >> Sr. Technical Instructor >> >> YES! We take Cisco Learning Credits! >> >> Training & Remote Racks available >> >> >> >> >> >> Blogs and organic groups at http://www.ccie.net >> >> >> >> _______________________________________________________________________ >> >> Subscription information may be found at: >> >> http://www.groupstudy.com/list/CCIELab.html >> > >> > >> > Blogs and organic groups at http://www.ccie.net >> > >> > _______________________________________________________________________ >> > Subscription information may be found at: >> > http://www.groupstudy.com/list/CCIELab.html >> > >> > >> > >> > >> > >> > >> > > > > > > -- > Narbik Kocharians > CCSI#30832, CCIE# 12410 (R&S, SP, Security) > www.MicronicsTraining.com > Sr. Technical Instructor > YES! We take Cisco Learning Credits! > Training & Remote Racks available Blogs and organic groups at http://www.ccie.netReceived on Sun Mar 11 2012 - 11:57:33 ART
This archive was generated by hypermail 2.2.0 : Sun Apr 01 2012 - 07:56:52 ART