Subject: (ION) re: draft-ietf-rolc-nhrp-14.txt

From: David Horton <[email-masked]>
Date: Tue, 10 Feb 98 16:42:27 +1000

I believe the new text added in the security considerations is
wrong for registration packets:-

   Data integrity covers the entire NHRP payload. This guarantees that
   the message was not modified and the source is authenticated as well.

It is possible for registration request packets to be forwarded
for a guest NHC by transit NHS to the home NHS. In this case the
authentication is between the guest NHC and the home NHS.
In order for the authentication checksum to be preserved end to end,
then any extensions that may be modified on transit must not
be included. This will include Forward Transit extensions and
potentially some vendor private extensions. 
At the time of the introduction of registration forwarding the
agreed authentication processing was to run the checksum up to
and including the authentication extension. Any extensions beyond
that were ignored for checksum calculations.

In a registration packet, as opposed to a resolution packet, there
is only tracing information in the transit extensions.
In a vendor private extension, there may be information that
could be compromised. The NHC which is inserting and ordering the
extensions presumably is aware of this, and can place end-end
type extensions before the authentication and hop by hop after.

More specifically and concretely we suggest the following :-

Section 5.3.4 NHRP Authentication Extension needs to be changed as follows,
from 

   The authentication is always done pairwise on an NHRP hop-by-hop
   basis;  i.e., the authentication extension is regenerated at each
   hop.  If a received packet fails the authentication test, the station
   SHALL generate an Error Indication of type "Authentication Failure"
   and discard the packet. Note that one possible authentication failure
   is the lack of an Authentication Extension; the presence or absence
   of the Authentication Extension is a local matter.

To
   **Except in the case of an NHRP Registration Request/Reply
  
   The authentication is always done pairwise on an NHRP hop-by-hop
   basis;  i.e., the authentication extension is regenerated at each
   hop. 

   **In the case
   **of an NHRP Registration Request/Reply, the Authentication is checked
   **on an end-to-end basis rather than hop-by-hop.

   If a received packet fails the authentication test, the station
   SHALL generate an Error Indication of type "Authentication Failure"
   and discard the packet. Note that one possible authentication failure
   is the lack of an Authentication Extension; the presence or absence
   of the Authentication Extension is a local matter.

Also the calculation of the authentication HASH in section 5.3.4.1
should also be modified to

   The authentication hash covers only the following fields of the NHRP
   packet: fixed  part (with  hop count, packet size and checksum being set
   to zero), mandatory part, and extensions up to and including the 
   authentication extension.  Note that there is an explicit ordering of
   the extensions such that: 
   (a) If the Responder Address extension exists then it MUST appear before
       the Authentication Extension. 
   (b) Any extensions that may be modified in transit (e.g., Forward
       Transit Extension) MUST appear after the Authentication Extension.

Additionally we note that now UNI 4.0 has been released, anycast is now 
publicly known and so the ATM address of an NHS need not be individually
configured at the NHC. This relates to a specific NBMA technology
but may be worthy on mention here.

regards,
David

 David Horton
 CiTR Pty Ltd
 Level 2 South Tower, 339 Coronation Drive, Milton, Australia 4064
 Email: [email-masked]     Phone +61 7 32592222   Fax +61 7 32592259
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.