Subject: (ION) mobile NHCs

From: "James V. Luciani" <[email-masked]>
Date: Tue, 24 Mar 1998 13:22:01 -0500

Folks,

  There has been some recent interest in having roaming NHCs which do not 
know the addresses of any of their serving NHS(s) (be they ATM or IP).  
We made some modifications in the soon to be RFC for NHRP in order to support 
this.  However, the security mechanisms described in NHRP have 
hop by hop semantics.  This would imply that a roaming NHC which connects 
to a non-serving NHS in order to register with one of its serving NHSs 
would have to be in a security relationship with every possible 
non-serving NHS with which it might connect.  There is sentiment that this is 
unreasonable.  Hence the authors of the following draft would like 
to suggest the use of a new NHRP extension which is described below.  The 
semantics of this new security extension are end to end
between NHC and serving NHS and it is only applicable to Registration and Purge
messages which may have these peculiar properties.

--Jim Luciani

________________________________________________________________

Internetworking Over NBMA                               James V. Luciani
INTERNET-DRAFT                                            (Bay Networks)
<draft-luciani-ion-nhrp-mobile-nhc-00.txt>                Hiroshi Suzuki
                                                       (NEC Corporation)
                                                      Naganand Doraswamy
                                                          (Bay Networks)
                                                            David Horton
                                                          (CiTR Pty Ltd)

                                                     Expires August 1998

                         NHRP with Mobile NHCs

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

Abstract

   This document describes an extension for Mobile NHCs to use when they
   register with their home LIS but initially connect to a non-serving
   NHS to do so.

1. Introduction

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [4].

Luciani, et al.                                                 [Page 1]

INTERNET-DRAFT                 NBMA NHRP             Expires August 1998

   This document describes an extension for Mobile NHCs to use when they
   wish to register with their home LIS but initially connect to a non-
   serving NHS to do so.  The reader is encouraged to read [1] for more
   details on the NHRP registration process.

2.0 Definition of the NHRP Mobile NHC Authentication Extension

    Compulsory = 1
    Type = 10 (proposed)
    Length = variable

   The NHRP Mobile NHC Authentication Extension is carried in NHRP
   Registration packets to convey end to end authentication Information.
   This extension is used when a mobile NHC initially connects to an NHS
   which is not one of its serving NHSs and the mobile NHC and non-
   serving NHS are not in a security relationship.  The mobile NHC does
   this in order to send an NHRP Registration Request, via normal
   routing and forwarding processes, to one of its serving NHSs with
   which it does have a security relationship.  As defined in [1], a
   serving NHS is an NHS in the NHC's home LIS with which the NHC will
   register.  Upon receiving such an NHRP Registration Request, the
   serving NHS will do the following: authenticate the sender NHC, set
   up a VC to the NHC, and then send an NHRP Resolution Reply in
   response on that new VC.

   Note that a transit NHS (such as the one to which the mobile NHC
   initially connects) MUST ignore an extension which it does not
   understand and that an NHS MUST not change the order of extensions in
   an NHRP packet. Thus, the end to end semantics of this extension are
   preserved without causing changes to existing implementations.

   If a serving NHS receives a packet which fails the hop by hop
   authentication test defined in [1] then the NHS MUST generate an
   Error Indication of type "Authentication Failure" and discard the
   packet. However in the case where the NHRP Mobile NHC Authentication
   Extension is used as described above, sending an Error Indication is
   not possible since no route exists back toward the mobile NHC
   assuming a VC does not already exist between the mobile NHC and the
   serving NHS which received the NHRP Registration Request. In this
   case, the NHRP Registration Request is merely dropped.

2.1 Header Format

   The authentication header has the following format:

Luciani, et al.                                                 [Page 2]

INTERNET-DRAFT                 NBMA NHRP             Expires August 1998

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved                    | Security Parameter Index (SPI)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Src Addr...                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Security Parameter Index (SPI) can be thought of as an index into a
   table that maintains the keys and other information such as a hash
   algorithm. Src and Dst communicate either offline using manual keying
   or online using a key management protocol to populate this table. The
   sending NHRP entity always allocates the SPI and the parameters
   associated with it.

   The Src Addr field is a variable length field which contains the
   address assigned to the outgoing interface. The length of the field
   is obtained from the source protocol length field in the mandatory
   part of the NHRP header.  The tuple <spi, src addr> uniquely
   identifies the key and the other parameters that are used in
   authentication.

   The length of the authentication data field is dependent on the hash
   algorithm used. The Authentication Data field contains the keyed hash
   calculated over the following fields: fixed  part (with  hop count,
   packet size and checksum being treated as if set to zero), mandatory
   part, and extensions up to and including the Mobile NHC
   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, Hop by Hop Authentication Extension) MUST appear
     after the Mobile NHC Authentication Extension.

   Calculation of the hash for this extension should allow intervening
   vendor private extensions. This is in line with the mechanisms
   described in RFC2002 [3]. An example of such an extension would be a
   timestamp extension which would counter replay attacks. The RFC2002
   authentication extensions include a timestamp. Other examples could
   include new NHRP or MPOA extensions defined at a future date.

Luciani, et al.                                                 [Page 3]

INTERNET-DRAFT                 NBMA NHRP             Expires August 1998

2.2 SPI and Security Parameters Negotiation

   SPI's can be negotiated either manually or using an Internet Key
   Management protocol. Manual keying MUST be supported. The following
   parameters are associated with the tuple <SPI, src>- lifetime,
   Algorithm, Key. Lifetime indicates the duration in seconds for which
   the key is valid. In case of manual keying, this duration can be
   infinite. Also, in order to better support manual keying, there may
   be multiple tuples active at the same time (Dst being the same).

   Algorithm specifies the hash algorithm agreed upon by the two
   entities. HMAC-MD5-128 [2] is the default algorithm. Other algorithms
   MAY be supported by defining new values. IANA will assign the numbers
   to identify the algorithm being used as described in [1].

   Any Internet standard key management protocol MAY so be used to
   negotiate the SPI and parameters.

2.3 Message Processing

   Unauthenticated 'Mobile' Registration Request processing proceeds as
   follows [1]:
      - the NHC inserts the internetwork address of a serving NHS in
        the 'Destination  Protocol Address' field; If the NHS address
        is unknown, then the NHC inserts its own internetwork address.
        A 'responder address' extension is optionally added.
      - the non-serving NHS forwards the packet along the routed path
        based on the contents of the 'Destination  Protocol Address' field.
   - the serving NHS which receives the NHRP Registration Request will
     set up a direct VCC to NHC after authenticating the request
   - the serving NHS will then send the NHRP Registration Reply
        back to the NHC on that new VCC.
   - the NHC will subsequently send all NHRP traffic to the serving NHS on
     the direct VCC.

   When the NHC adds the authentication extension header, it performs a
   table looks up in order to fetch the SPI and the security parameters
   based on the outgoing interface address. If there are no entries in
   the table and if there is support for key management, the NHC
   initiates the key management protocol to fetch the necessary
   parameters. The NHC constructs the Authentication Extension payload
   and calculates the hash by zeroing out the authentication data field.
   The result is placed in the authentication data field. The src
   address field in the payload is the internetwork address assigned to
   the outgoing interface.

Luciani, et al.                                                 [Page 4]

INTERNET-DRAFT                 NBMA NHRP             Expires August 1998

   If key management is not supported and authentication is mandatory,
   the packet is dropped and this information is logged.

   On the receiving end, the serving NHS fetches the parameters based on
   the SPI and the internetwork address in the authentication extension
   payload. The authentication data field is extracted before being
   zeroed out in order to calculate the hash. It computes the hash on
   the entire payload and if the hash does not match, then an "abnormal
   event" has occurred.

   The keys used by the mobile NHC for communicating with the serving
   NHS in NHRP Registration Requests can be used in subsequent
   resolution and purge requests made directly to the serving NHS after
   receiving the NHRP Registration Reply.  However, the authentication
   extension defined in [1] MUST be used when these keys are applied to
   resolution and purge packets.

   Hop by Hop Authentication[1] and End to End authentication may be
   used in combination to provide protection against both spoofing and
   denial of service attacks.           If only an end-to-end Mobile NHC
   Authentication Extension is present, it MAY be the policy of each
   transit NHS to reject the NHRP Registration Request based on the
   requirement for having a Hop by Hop authentication present.  Such a
   requirement is a local matter.

2.4 Security Considerations

   It is important that the keys chosen are strong since the security of
   the entire system depends on the keys being chosen properly.

   End-to-end authentication counters spoofing attacks on the home
   subnet through not relying on the potentially compromised chain of
   trust. The use of end-end authentication is further described in [3].

   Hop-by-hop authentication prevents denial of service attacks by
   introducing access control at the first point of contact to the NHRP
   infrastructure.

   The security of this extension is performed on an end to end basis.
   The data received can be trusted only so much as one trusts the end
   point entities in the path traversed. A chain of trust is established
   amongst NHRP entities in the path of the NHRP Message . If the
   security in an NHRP entity is compromised, then security in the
   entire NHRP domain is compromised.

   Data integrity covers the entire NHRP payload up to and including the
   Mobile NHC Authentication Extension. This guarantees that the data

Luciani, et al.                                                 [Page 5]

INTERNET-DRAFT                 NBMA NHRP             Expires August 1998

   and extensions covered by this authentication hash were not modified
   and that the source is authenticated as well. If the authentication
   extension is not used or if the security is compromised, then NHRP
   entities are liable to both spoofing attacks, active attacks, and
   passive attacks.

   There is no mechanism to encrypt the messages. It is assumed that a
   standard layer 3 confidentiality mechanism will be used to encrypt
   and decrypt messages.  It is recommended to use an Internet standard
   key management protocol to negotiate the keys between the neighbors.
   Transmitting the keys in clear text, if other methods of negotiation
   is used, compromises the security completely.

References
   [1] "NBMA Next Hop Resolution Protocol (NHRP)", Luciani, Katz, Piscitello,
       Cole, Doraswamy, RFC TBD.

   [2] "HMAC: Keyed Hashing for Message Authentication", Krawczyk, Bellare,
       Canetti, RFC 2104.

   [3] "IP Mobility Support", C.Perkins, RFC 2002.

   [4]  Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,
        RFC 2119.

Authors' Addresses

Luciani, et al.                                                 [Page 6]

INTERNET-DRAFT                 NBMA NHRP             Expires August 1998

   James V. Luciani
   Bay Networks
   3 Federal Street
   Mail Stop: BL3-03
   Billerica, MA 01821
   Phone:  +1 978 916 4734
   Email:  [email-masked]

   Hiroshi Suzuki
   NEC Corporation
   4-1-1 Miyasaki Miyamae
   Kawasaki, 216 Japan
   Phone:  +011 81 44 856 2123
   Email: [email-masked]

   Naganand Doraswamy
   Bay Networks
   3 Federal Street
   Mail Stop: BL3-03
   Billerica, MA 01821
   Phone:  +1 978 916 4734
   Email:  [email-masked]

   David Horton
   CiTR PTY Ltd
   Level 2 South Tower
   339 Coronation Drive
   Milton, Australia 4064
   Phone: +011 61 7 32592222
   Email:  [email-masked]

Luciani, et al.                                                 [Page 7]

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Albert Manfredi <[email-masked]>
Date: Wed, 25 Mar 1998 10:35:53 -0500

James V. Luciani wrote:

> non-serving NHS with which it might connect.

I'm confused by this concept: that a roaming NHC would be served by
any NHS that is not the topologically closest one to it at any given
time.

The point of NHRP is to create shortcuts without the IP layer
knowing what the NBMA topology looks like. So NHS routers must find
the shortest IP path and then translate this into an ATM (for
example) shortcut.

>    serving NHS to do so.

If I have a mobile ATM terminal, and I switch it on half-way around
the world from my home NHS, would I not want my serving NHS to be
the one that is close by? If someone wants to establish a shorcut to
my roaming terminal, why would the "home" NHS, on the other side of
the world, be my serving NHS?

I'm also trying to approach this from a purely mobile ATM point of
view. It seems to me that NBMA net shortcuts for mobile hosts and
the concept of "home NHS" are sort of mutually exclusive? Unless
I've missed something just so I can look foolish. (For example, is
the "home NHS" _only_ used for authentication?)

I believe that mobility at the ATM level can be handled really well,
allowing a mobile ATM terminal to configure itself for whatever
location it finds itself. And the ATM Forum is now worrying about
the radio handoff issues. So to accommodate IP over ATM, should we
not worry about establishing efficient shortcuts based on the mobile
terminal's _current_ location?

Thanks.

Bert
[email-masked]
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.