Internet Engineering Task Force Mohamed M.Khalil
INTERNET-DRAFT Raja Narayanan
<draft-ietf-mobileip-mier-02.txt> Haseeb Akhtar
Date: Dec, 1999 Emad Qaddoura
Expires: May, 2000 Nortel Networks
Mobile IP Extensions Rationalization (MIER)
Status of this memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Khalil, et al. Expires May 2000 [Page 1]
Internet-Draft MIER May 2000
Abstract
It is in the interest of the Mobile IP WG to conserve the
usage of the type field since we see many drafts proposing
new extensions for Mobile IP. Therefore there is a real
need to find ways to limit the usage of the type field in the
extensions structure. MIER describes a new extension
structure to Mobile IP to make the extensions far more
extensible.
1.0 Introduction
The type field in the Mobile IP extension structure can support
upto 255 (skippable and not skippable) uniquely identifiable
extensions. With new developments/additions to Mobile IP
there is a strong possibility that the available space will
run out.
Mobile IP Extensions Rationalization (MIER) describes a
new extension structure to solve this problem. MIER strategy
is to initially aggregate certain types of extensions (e.g,
NAI) and sub types to identify the precise extension (example
MN/User NAI, HA NAI etc). This will greatly reduce the usage
of the type field.
MIER proposal is a natural evolution to the existing extension
structure. It does not impact extensions that have been already
defined.
1.1 Terminology
SA - Security Association [Perkins96]
MN - Mobile Node [Perkins96]
HA - Home Agent [Perkins96]
FA - Foreign Agent [Perkins96]
AAA - Authentication, Authorization, and Accounting.
SPI - Security Parameters Index is a 32 bit number to index a SA
in a database [Perkins96].
Khalil, et al. Expires May 2000 [Page 2]
Internet-Draft MIER May 2000
2.0 Mobile IP Extension formats
The extension structure proposed in this draft [Sec 2.2] is
applicable to new extensions that are proposed to enhance
Mobile IP. It does not apply to the extensions that have already
been defined and standardised.
2.1 Existing Mobile IP Extension format
According to [Perkins96] : Mobile IP defines a general Extension
mechanism to allow optional information to be carried by Mobile
IP control messages. Each of these Extensions is encoded in the
following Type-Length-Value format:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type Indicates the particular type of Extension.
Length Indicates the length (in bytes) of the data field within
this Extension. The length does NOT include the Type and
Length bytes.
Data The particular data associated with this Extension. This
field may be zero or more bytes in length. The format
and length of the data field is determined by the type
and length fields.
2.2 New Mobile IP Extension format
This draft proposes the following two structures for Mobile IP
extensions to be carried in the Mobile IP control messages.
Since the new extension structures will cause an efficient
usage of the extension type space, it is strongly recommended
that all the new proposals for the Mobile IP WG that have new
extensions SHOULD follow this format unless there is an overwhelming
reason not to do so.
Khalil, et al. Expires May 2000 [Page 3]
Internet-Draft MIER May 2000
2.2.1 Long Extension Format
This format is applicable for non-skippable extensions which carry
information more than 256 bytes. It should be applicable to any future
standardization which consider non-skippable extensions which accommodate
up to 64 KBytes of data.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The proposed general structure of the Long Extension consists
of the following fields:
Type is the type which describe a collection of extensions which
has a common data type (see A.1, A.3).
Sub-Type is a unique number given to each member in the
aggregated type. Sub-Type values between of 200 through
255 are reserved for future use and standardization.
Length indicates the length (in bytes) of the data field within
this Extension. It does NOT include the Type, Length
and Sub-Type bytes.
Data is the data associated with this extension. This data MAY
be represented in many ways (see A.1, A.3)
Two bytes for the length field is suggested to enable providing a
sufficiently large space for the extension data (maximum 64Kbytes).
Khalil, et al. Expires May 2000 [Page 4]
Internet-Draft MIER May 2000
2.2.2 Short Extension Format
This format is backward compatible with the skippable extensions
as it is defined in [Perkins96]. Also, it applicable for extensions
which doe not require more than 256 bytes of data.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The proposed general structure of the Short Extension consists
of the following fields:
Type is the type which describe a collection of extensions which
has a common data type (see A.2).
Sub-Type is a unique number given to each member in the
aggregated type. Sub-Type values between of 200 through
255 are reserved for future use and standardization.
Length indicates the length (in bytes) of the data field within
this Extension. It does NOT include the Type, Length
and Sub-Type bytes if the extension is non-skippable.
if the extension is skippable the length will include
the Sub-Type and data fields length only.
Data is the data associated with this extension. This data MAY
be represented in many ways (see A.2)
3.0 Acknowledgements
The authors would like to acknowledge Basavaraj Patil, Pat
Calhoun, Neil Justusson, C. Perkins, N. Asokan, and Jouni Malinen
for their input in writing this draft.
4.0 References
[Calhoun99a] Calhoun, Perkins, "Mobile IP Network Access
Identifier Extension", draft-ietf-mobileip-mn-nai-05.txt
[Perkins96] Perkins, "IP mobility Support", RFC 2002, Oct 96
[Perkins99] Perkins, "Mobile IP Challenge/Response Extensions"
draft-ietf-mobileip-challenge-06.txt
[Bradner97] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Mar 97
Khalil, et al. Expires May 2000 [Page 5]
Internet-Draft MIER May 2000
A APPENDIX
The following are some exmples where we could use the concept
of the proposed extensions' structure.
A.1 General Authentication Extension
This section defines a generic authentication extensions.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Sub Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Authentication Extension type (TBD)
Sub-Type this field describes the type of the entity which
owns the Authentication Extension. The following
types are defined:
1 MN-AAA Authentication Extension
length The length of the Authenticator field.
SPI Security Parameters Index
Authenticator The variable length Authenticator field consists
random value of at least 128 bits.
A.2 General NAI Extension
This section defines a general purpose NAI extension for
different types of entities such MN, HA, FA etc.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | NAI-INFO ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type NAI Aggregate type (TBD)
length The length of the NAI-INFO field.
Khalil, et al. Expires May 2000 [Page 6]
Internet-Draft MIER May 2000
Sub-Type this field describes the type of the entity which
owns the NAI. The following types are defined:
0 MN-NAI
1 FA-NAI
2 HA-NAI
3 Previous FA-NAI Extension
NAI-INFO Contains the NAI in a string format.
A.3 General Session Key Extension
This section defines a general purpose security association
extension which carries information necessary to establish security
association between different entities in the Mobile IP model
(e.g. MN-FA, FA-HA and MN-HA ).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Sub Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| security information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Generic AA Key Extension (TBD)
length The length of the SA-INFO field.
Sub-Type defines the type of entity which owns the key
address:
0 MN-HA Key Extension
1 MN-FA Key Extension
2 FA-HA Key Extension
SPI1 A 32-bit opaque value, indicating the SPI that the
mobile node must use to determine the algorithm to use
for recovering the security information.
SPI2 A 32-bit opaque value, which the mobile node MUST use
to index all the necessary information recovered from
the FA security information after it is decoded.
Security Information
The necessary information (including the
key, algorithm etc) required by the mobile node
to create a Mobility Security Assocation between
itself and another entity such as HA and FA.
Khalil, et al. Expires May 2000 [Page 7]
Internet-Draft MIER May 2000
Author Information:
Mohamed Khalil Emad Qaddoura
Nortel Networks Inc. Nortel Networks Inc.
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX 75082-4399 Richardson, TX 75082-4399
Phone: +1 972 685-0564 Phone: +1 972 684-2705
E-mail: mkhalil@nortelnetworks.com E-mail: emadq@nortelnetworks.com
Raja Narayanan Haseeb Akhtar
Nortel Networks Inc. Nortel Networks Inc.
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX 75082-4399 Richardson, TX 75082-4399
Phone: +1 972 684-5707 Phone: +1 972 684-8850
E-mail: raja@nortelnetworks.com E-mail: haseeb@nortelnetworks.com
Khalil, et al. Expires May 2000 [Page 8]