The IP Over NBMA (ION) Archive

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

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


The way I saw this working for vendor private extensions is :-

===> 		Fixed header part,
+ 		(with  hop count, packet size and checksum being set to zero)
+ 		Mandatory part.
+		Responder address ext
+		VendorNHC/code=1
+		VendorNHC/code=2
===> 		authentication extension
		NBMA-ID ext
		VendorNHC/code=3
		Vendor-IntermediateNHS/code=1

===>
+ 	MD5 digest calculation
===>

For the NHC the vendor private extensions 1 and 2 are not augmented
by any intermediate NHS (whether they are the same vendor or not),
but private extension 3 is potentially augmented by knowing 
intermediate NHS. (Perhaps this is some kind of load recording
extension used in QoS calculations).
Another vendor may choose to tack on some additional info?

The preservation of the ordering of the extensions is required
to ensure that extensions inside the MD5 digest calculation 
remain the same. If the NHC generates the order wrongly, then I
think it is reasonable for the packet to be rejested at the end NHS.

My feeling on what must be inside, and outside is :-

Must be inside
(3) Responder Address Extension

Must be outside
(2) NBMA Subnetwork ID extension
(4) NHRP Forward Transit NHS Record Extension
(5) NHRP Reverse Transit NHS Record Extension
(7) NHRP Authentication Extension

Unsure
(6) NHRP QoS Extension
	I can think of examples where this may have end-end data, and also
	where there may be information added to the extension as it
	progresses through the network.
(8) NHRP Vendor private
	I think these could be inside or outside depending on the
	particular extension. Provided the order is preserved, and
	the NHC understands the extension, it can insert in the correct place.


cheers,
David

 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