0

When an OSPFv2 packet does not contain the LLS data block, then the calculated MD5 hash should be on the "Auth Crypt Data" field. For example, here is a LS Update message which does not contain the LLS data block:

OSPFv2 LS Update with MD5 auth

However, am I correct that in case the LLS data block is present, then two hashes are calculated? One for LLS part and the second one for the rest of the message? It sure seems to be so when I inspect the OSPFv2 Hello or DB Description with MD5 authentication: OSPFv2 Hello with MD5 auth

OSPFv2 DB Description with MD5 auth

2
+200

You're correct. Let's illustrate it with a few facts.

Section D of RFC2328 states clearly that all OSPF protocol exchanges are authenticated. The AuType field is included in all OSPF packet types (this is important):

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).

It also lays out the types of authentication, even though "Null authentication" means no authentication, it still signals that to the neighbor.

AuType       Description
___________________________________________
0            Null authentication
1            Simple password
2            Cryptographic authentication
All others   Reserved for assignment by the
             IANA (iana@ISI.EDU)


    Table 20: OSPF authentication types.

RFC5613 specifies that the L-bit can only be set in Hello and DD packets and NOT other packet types...

The LLS block MAY be attached to OSPF Hello and Database Description
(DD) packets.  The LLS block MUST NOT be attached to any other OSPF
packet types on generation and MUST be ignored on reception.

...if "cryptographic authentication" (AuType 2) is enabled:

This TLV MUST only be
included in the LLS block when cryptographic authentication is
enabled on the corresponding interface.

Furthermore, it states how the authentication should be handled.

Note that if the OSPF packet is cryptographically authenticated, the
LLS data block MUST also be cryptographically authenticated. 
2

Yes you are correct,as per RFC 5613, a special TLV is used for cryptographic authentication (CA-TLV) of the LLS data block. Which you can see at the bottom of your last screenshot. This TLV is to be only included in the LLS block when cryptographic authentication is enabled on the corresponding interface. The message digest of the LLS block is calculated using the same key and authentication algorithm as used for the rest of OSPFv2 packet. The cryptographic sequence number is included in the TLV and MUST be the same as the one in the OSPFv2 authentication data for the LLS block to be considered authentic.

https://www.rfc-editor.org/rfc/rfc5613#section-2.5

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.