Subject: Re: [MOBILE-IP] Draft for Vendor/Organization Specific Extensions

From: Patrice Calhoun <[email-masked]>
Date: Fri, 24 Sep 1999 10:36:28 -0700

Gopal,

I think that this is a fine idea, however I have an issue with it. Since there is no way
to know a priori which vendor's box you will be talking to, what is the expected action
if one receives either an unsupported vendor extension, or an unknown extension from a
known vendor? Remember that in the RADIUS world, it has become almost a custom to start
supporting all of the various documented, and undocumented, vendor specific attributes and
the same may apply here.

PatC

>Hello:
>
>Attached (and also sent in the previous mail) is a preliminary draft:
>
>Vendor/Organization-Specific Extensions for Mobile IP
>                  <draft-dommety-mobileip-vendor-ext-00.txt>
>
>
>Would really appreciate your comments.
>
>Thanks.
>-Gopal
>
>
>>
>> Mobile IP Working Group                                    Gopal Dommety
>> INTERNET DRAFT                                             Kent Leung
>> August 1999                                                Cisco Systems
>>
>>
>>             Vendor/Organization-Specific Extensions for Mobile IP
>>                   <draft-dommety-mobileip-vendor-ext-00.txt>
>>
>>
>> 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 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.
>>
>> Abstract
>>
>>    This draft proposes an extensions that can be used as a vendor
>>    or organization-Specific Extensions.  These extensions will facilitate
>>    organizations to make specific extensions as they see fit for research
>>    or deployment purposes.
>>
>> 1.0   Introduction
>>
>>    Current specification of Mobile IP [1] does not allow for
>>    organizations and vendor to include organization/vendor-specific
>>    extensions in the Mobile IP messages. With the wide scale deployment
>>    of Mobile IP it is useful to have a vendor or organization-Specific
>>    Extension.  This draft proposes  extensions that can be used for
>>    making organization specific extensions.
>>
>>
>> 2.0 Vendor/Organization Specific Extensions
>>
>> Two  Vendor/Organization Specific Extensions  are described,  Critical
>> and Normal    Vendor/Organization  Specific Extensions.     The  basic
>> differeces are between the Critical and  the Normal Extensions is that
>> whan the  Critical extension  is encountered  but not  recognized, the
>> message   containing the   extension    MUST  be   silently
>> discarded.  Whereas   when   a  Normal   Vendor/Organization  Specific
>> Extension is encountered and not recognized, the extension is ignored,
>> but  the  rest  of  the Extensions  and   message data  MUST still  be
>> processed. Another    difference between the    two is  that  Critical
>> Vendor/Organization Extension has a lenght feild of two bytes.
>>
>>
>> 2.1 Critical Vendor/Organization Specific Extension
>>
>>    The format of this extension is as shown below.
>>
>>        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             |   Vendor-ID
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>                      Vendor-ID (cont)                 | Opaque Data...
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>>                 Figure 1: Vendor/Organization Specific Extension
>>
>>
>>       Type       TBD-1 (value should be in the range of 0-127)
>>
>>       Length     Length in bytes of this extension, not including the Type
>>                  and Length bytes.
>>
>>       Vendor-ID
>>                  The high-order octet is 0 and the low-order 3 octets are the
>>                  SMI Network Management Private Enterprise Code of the Vendor
>>                  in network byte order, as defined in the Assigned Numbers
>>                  RFC [2].
>>
>>       Opaque Data
>>                  Vendor/organization specific data.  These data fields
>>                  may be publicized in future RFCs.
>>
>> 2.2 Normal Vendor/Organization Specific Extension
>>
>>    The format of this extension is as shown below.
>>
>>        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     |   Vendor-ID
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>                  Vendor-ID (cont)     | Opaque Data...                |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>>                 Figure 1: Vendor/Organization Specific Extension
>>
>>
>>       Type       TBD-2 (value should be in the range of 128-255)
>>
>>       Length     Length in bytes of this extension, not including the Type
>>                  and Length bytes.
>>
>>       Vendor-ID
>>
>>                  The high-order octet is  0 and the low-order 3 octets
>>                are the SMI Network Management Private Enterprise
>>                Code of         the Vendor in network byte order, as
>>                defined in the Assigned Numbers RFC [2].
>>
>>       Opaque Data
>>                  Vendor/organization specific data.  These data fields
>>                  may be publicized in future RFCs.
>>
>>
>> 3.0 Restrictions
>>
>>    Multiple TLV's with the TBD-1 and TBD-2 types can  be included in a
>> message. TLVs with TBD-1 and TBD-2 types can  be placed anywhere after
>> the fixed  portion of the Mobile IP  meggase.  These TLVs are expected
>> to  be protected by   the  corresponding authenticator as   necessary.
>> Ordering of these TLV's should not be modified by intermediate nodes.
>>
>>
>>
>> 4.0 Security Considerations
>>
>>    This document assumes that the Mobile IP messages are authenticated
>> using a method defined by the Mobile IP protocol.  This proposal does
>> not impose any additional requirements on Mobile IP messages from a
>> security point of view. So this is not expected to be a security
>> issue.
>>
>>
>> 5.0 IPv6 considerations
>>
>>       This extension can be used in IPv4 and IPv6 alike.
>>
>> References
>>
>>    [1] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October
>>        1996.
>>    [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
>>        1700, USC/Information Sciences Institute, October 1994.
>>
>> Authors' Addresses
>>
>>    Questions about this memo can be directed to:
>>
>>       Gopal Dommety                   Kent Leung
>>       Cisco Systems                     Cisco Systems
>>       170 West Tasman Drive             170 West Tasman Drive
>>       San Jose, CA 95134                San Jose, CA 95134
>>       USA                               USA
>>
>>       Phone:  +1-408-525-1404           Phone:  +1-408-526-5030
>>       EMail:  [email-masked]        EMail:  [email-masked]
>>
>>
>>

---

From: "Kent K. Leung" <[email-masked]>
Date: Fri, 24 Sep 1999 10:54:00 -0700

Pat,

The convention for dealing with unsupported/unknown vendor extensions
is described in RFC 2002 Section 1.9:

   "When an Extension numbered in either of these sets within the range 0
   through 127 is encountered but not recognized, the message containing
   that Extension MUST be silently discarded.  When an Extension
   numbered in the range 128 through 255 is encountered which is not
   recognized, that particular Extension is ignored, but the rest of the
   Extensions and message data MUST still be processed."

So for Critical Vendor Extensions (Type 0 - 127), the agent MUST discard
the entire message.  And for Normal Vendor Extensions (Type 128 - 255),
the agent MUST ignore the TLV but process the message.

-- Kent --

--
     |          |                         Kent Leung
    :|:        :|:                        Software Engineer
   :|||:      :|||:                       IOS Development
.:|||||||:..:|||||||:.                    408.526.5030
c i s c o S y s t e m s                   [email-masked]

---

From: Gopal Dommety <[email-masked]>
Date: Fri, 24 Sep 1999 11:02:16 -0700

> known vendor? Remember that in the RADIUS world, it has become almost a custom to start

Unsupported   vendor extension, or an  unknown  extension from a known
vendor  for  a  CVSE (Critical)   will  result in  discarding  of  the
message. For NVSE the extension will be ignored. Is  this what you are
referring to?

Thanks Pat.

-Gopal