The IP Over NBMA (ION) Archive

[David Horton <horton@citr.com.au>]

                                              Hiroshi Suzuki, NEC
                                              David Horton, CiTR

We point out some issues related to the NHRP authentication. 
These issues can be fixed with small changes in specification wording
and/or packet format.


Method of generating MD5 digest for End-End Authentication 

Current  NHRP-08 says:  
For NHRP packets except Registration request/reply, authentication is done
on NHRP hop-by-hop basis.  For NHRP Registration request/reply, the
authentication is checked on an end-to-end basis rather than
hop-by-hop. The current specification says that Authentication Data
contains the 16 byte MD5 digest of the entire NHRP packet.

However, this could be applied only for Hop-by-Hop Authentication.  For
End-End, some parts of packet content, such as hop count and Transit record
extensions change hop-by-hop when packets are forwarded between NHS.
Therefore, for End-End Authentication, the part of packet should be
restricted for the MD5 digest generation, rather than generating MD5 digest
with the entire packet.

End-end authentication (of registration messages) must allow for all the
required data for protocol operation to be able to be authenticated.  That
means that the digest must be able to be calculated over parts verifiable
at the NHC and responding NHS. Intermediate NHS could modify packets for
reasons of protocol operation, e.g. NBMA-ID and transit extensions, or as
attacks. The fixed and mandatory parts of the NHRP packet are examples of
what must be authenticated. In a related proposal, we suggest that the
Responder NHS address information is also required as trusted data. NBMA-ID
and transit extensions are examples of data that are inserted by transit
NHS, and hence should not be included in the end-to-end authentication.

Although Authentication itself is a part of the NHRP extension,
interoperability may be broken if each vendor selects a different policy on
selecting the part of the packet for End-End Authentication.

So, the desirable solution is to specify the part of the packet for which
MD5 digest is generated for end-end authentication of Registration
Request/reply packets.

One example is

		Fixed header part,
		(with  hop count, packet size and checksum being set to zero)
		+
		Mandatory part.
		+
		No extension part.
are selected for the target of MD5 digest.

A second example is to require preservation of the extension ordering as
inserted by the NHC for registration request packets, and the responding
NHS for registration reply packets.
		Fixed header part,
		(with  hop count, packet size and checksum being set to zero)
		+
		Mandatory part.
		+
		extensions up to and including authentication extension
		(but no further extensions)
are selected for the target of MD5 digest. This allows responder address
extension, vendor private extensions and any other extensions considered
necessary and appropriate to be authenticated.



--
Hiroshi Suzuki:
Network Research Lab., C&C  Research Labs.
NEC Corp. (tel: +81-44-856-2123), (fax: +81-44-856-2230 )
--
 David Horton
 Centre for Information Technology Research
 Level 2 South Tower, 339 Coronation Drive, Milton, Australia 4064
 Email: d.horton@citr.uq.oz.au       Phone +61 7 32592222   Fax +61 7 32592259