Re: ospf authentication

:-) That's funny, but let's put aside cheap shots at each other and
focus on, what I think is not merely an academic discussion.

While I would agree to extent with both of you in this case, i.e. that
Null authentication effectively means "no authentication", I think in
the context of the CCIE lab and especially the troubleshooting part of
it; it *is* important to understand that Null authentication is in
fact an authentication type without a password, but an authentication
type nevertheless.

It's important to at least *be aware* of that when troubleshooting
mismatched authentication. A very simple example:

R2--R5:

R2:
interface Serial0/2/0
 ip address 192.168.25.2 255.255.255.0
!
router ospf 1
 network 0.0.0.0 0.0.0.0 area 0
!

R5:
interface Serial0/2/0
 ip address 192.168.25.5 255.255.255.0
!
router ospf 1
 network 0.0.0.0 0.0.0.0 area 0
!

If I run a simple "debug ip ospf packet" on R2, this is what I will
see once the adjacency is up:

  OSPF: rcv. v:2 t:1 l:48 rid:192.168.25.5 aid:0.0.0.0 chk:3942 aut:0
auk: from Serial0/2/0

Please note the "aut:0" part. It indicates that Null authentication is
in use. It's not an optional part of the hello packet - it will always
be there and as Brian Dennis explained earlier, OSPF authentication is
a two-stage process. In this case, password is not going to be taken
in account, but the type is still important.

Now, if Null authentication was truly "no authentication", R2 would
simply ignore all authentication settings coming from R5. Let's then
change authentication type on R5 and see what happens on R2. I will
enable "debug ip ospf events" for this part.

R5:
interface Serial0/2/0
 ip ospf authentication
!

Rcv pkt from 192.168.25.5, Serial0/2/0 : Mismatch Authentication type.
Input packet specified type 1, we use type 0

So, at this point, R2 is complaining that it's receiving packets with
mismatched authentication. It's not ignoring as would be the case if
Null authentication was truly no authentication.

After 4 of these, we can see this error message:

OSPF: 192.168.25.5 address 192.168.25.5 on Serial0/2/0 is dead

R2 is declaring its neighbor as dead. We can observe the same behavior
on R5 as well, but it's important to understand that even Null
authentication end will behave the same way.

[ cheap shots, so don't read 'em: I believe it's our responsibility as
instructors on this list to set aside mutual attacks and ridicule and
teach our students. By teaching I don't mean simply quote books, RFCs
and Cisco documents or write on whiteboards, but in fact show how
things work - use IOS to prove it. ]

--
Marko Milivojevic - CCIE #18427 (SP R&S)
Senior CCIE Instructor - IPexpert
On Sun, Mar 11, 2012 at 08:49, Brian McGahan <bmcgahan_at_ine.com> wrote:
> 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_example09186a0080094069.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  All OSPF protocol exchanges are authenticated. B The OSPF packet
> B  header (see Section A.3.1) includes an authentication type field,
> B  and 64-bits of data for use by the appropriate authentication scheme
> B  (determined by the type field).
>
> B  The authentication type is configurable on a per-interface (or
> B  equivalently, on a per-network/subnet) basis. B Additional
> B  authentication data is also configurable on a per-interface basis.
>
> B  Authentication types 0, 1 and 2 are defined by this specification.
> B  All other authentication types are reserved for definition by the
> B  IANA (iana_at_ISI.EDU<mailto:iana_at_ISI.EDU>). B The current list of authentication types is
> B  described below in Table 20.
>
>
>
> 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  0 B  B  B  B  B  B Null authentication
> 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  2 B  B  B  B  B  B Cryptographic authentication
> 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