The IP Over NBMA (ION) Archive

["James V. Luciani" <luciani@BayNetworks.com>]

[Hiroshi Suzuki and David Horton write:]
> 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.
David pointed some of this out a while ago and I asked for text so I guess
this comes close.
> 
> 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.
I like this idea but might be persuaded for the next one too.

> 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.
Can't use vendor private since that might be modified in flight by having
multiple such extensions added.  Please name exact suggestions
of extensions and I will add this or profer this as suggested text
in Montreal.

--Jim