Re: ospf authentication

From: Paul Negron <negron.paul_at_gmail.com>
Date: Sun, 11 Mar 2012 13:10:09 -0700

I agree with that statement fully.

-- 
Paul Negron
CCIE# 14856 CCSI# 22752
Senior Technical Instructor
> From: Marko Milivojevic <markom_at_ipexpert.com>
> Date: Sun, 11 Mar 2012 11:57:33 -0700
> To: Narbik Kocharians <narbikk_at_gmail.com>
> Cc: Paul Negron <negron.paul_at_gmail.com>, Brian McGahan <bmcgahan_at_ine.com>,
> Aaron <aaron1_at_gvtc.com>, CCIE GROUPSTUDY <ccielab_at_groupstudy.com>
> Subject: Re: ospf authentication
> 
> 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:
>> 
>> 
>> 
>> 
>> 
>>     D.1 Null authentication
>> 
>> 
>> 
>>         Use of this authentication type means that routing exchanges
>> 
>>         over the network/subnet are not authenticated.  The 64-bit
>> 
>>         authentication field in the OSPF header can contain anything; it
>> 
>>         is not examined on packet reception. When employing Null
>> 
>>         authentication, the entire contents of each OSPF packet (other
>> 
>>         than the 64-bit authentication field) are checksummed in order
>> 
>>         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_example09
>>>>> 186a
>>>>> 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.  If you read the OSPF specification
>>>>> (http://www.ietf.org/rfc/rfc2328.txt) is gives more detail:
>>>>> 
>>>>> D. Authentication
>>>>> 
>>>>>    All OSPF protocol exchanges are authenticated.  The OSPF packet
>>>>>    header (see Section A.3.1) includes an authentication type field,
>>>>>    and 64-bits of data for use by the appropriate authentication scheme
>>>>>    (determined by the type field).
>>>>> 
>>>>>    The authentication type is configurable on a per-interface (or
>>>>>    equivalently, on a per-network/subnet) basis.  Additional
>>>>>    authentication data is also configurable on a per-interface basis.
>>>>> 
>>>>>    Authentication types 0, 1 and 2 are defined by this specification.
>>>>>    All other authentication types are reserved for definition by the
>>>>>    IANA (iana_at_ISI.EDU<mailto:iana_at_ISI.EDU>).  The current list of
>>>>> authentication types is
>>>>>    described below in Table 20.
>>>>> 
>>>>> 
>>>>> 
>>>>>                  AuType       Description
>>>>>                  ___________________________________________
>>>>>                  0            Null authentication
>>>>>                  1            Simple password
>>>>>                  2            Cryptographic authentication
>>>>>                  All others   Reserved for assignment by the
>>>>>                               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.  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.  Even though "NULL"
>>>>> is a
>>>>> zero value, it still counts as a value.  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.  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
>>>>>>        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.  Is
>>>>>> that called type 0, 1, or 2?  I'm getting the impression that what
>>>>>> I've done was a half-baked type 2.  In other words it ain't truly type
>>>>>> 2 md5 auth until the int config "ip osp mess 1 md5 cisco" is applied.
>>>>>>  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.net
Received on Sun Mar 11 2012 - 13:10:09 ART

This archive was generated by hypermail 2.2.0 : Sun Apr 01 2012 - 07:56:52 ART