Skip to main content

Last Call Review of draft-ietf-lisp-vendor-lcaf-10
review-ietf-lisp-vendor-lcaf-10-secdir-lc-kivinen-2022-05-19-00

Request Review of draft-ietf-lisp-vendor-lcaf
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2022-04-12
Requested 2022-03-29
Authors Alberto Rodriguez-Natal , Vina Ermagan , Anton Smirnov , Vrushali Ashtaputre , Dino Farinacci
I-D last updated 2022-05-19
Completed reviews Rtgdir Last Call review of -10 by Dhruv Dhody (diff)
Secdir Last Call review of -10 by Tero Kivinen (diff)
Genart Last Call review of -09 by Christer Holmberg (diff)
Assignment Reviewer Tero Kivinen
State Completed
Request Last Call review on draft-ietf-lisp-vendor-lcaf by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/8LW_5Yb6ioNtUcYn7eLNv_7sTBc
Reviewed revision 10 (document currently at 12)
Result Has nits
Completed 2022-05-19
review-ietf-lisp-vendor-lcaf-10-secdir-lc-kivinen-2022-05-19-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. This is review is quite late, as this document was first assigned
to another reviewer, and was then withdrawn and assigned to me today.

This document describes how to generate Vendor Specific LCAFs. The
document seems to be otherwise fine, except it incorrectly uses IEEE
terminology and provides reference to very old IEEE document. 

The references section include:

   [IEEE.802_2001]
              IEEE, "IEEE Standard for Local and Metropolitan Area
              Networks: Overview and Architecture", IEEE 802-2001,
              DOI 10.1109/ieeestd.2002.93395, 27 July 2002,
              <http://ieeexplore.ieee.org/servlet/opac?punumber=7732>.

This document is dated reference to IEEE document, and I see no reason
to use dated reference here. Using IEEE 802-2001 fixes the reference
to that specific document published in 2001. There is new revision 
of this document IEEE Std 802-2014 which do contain significant changes
related to topic of this draft. It would be better to use undated 
reference i.e "IEEE Std 802" instead of dated reference. That way
this document will always refer to the latest IEEE Standard. 

(i.e. difference is same as using old obsoleted RFC numbers instead
latest RFC numbers or STD numbers).

Also the correct spelling of the IEEE Standards is to "Std" between
IEEE and number, i.e. "IEEE Std 802", or "IEEE Std 802-2014" (note, no
period after Std).

The major issue is the text using OUI:

      Organizationally Unique Identifier (OUI): This is a 24-bit field
      that carries the IEEE OUI [IEEE.802_2001] of the organization.

The IEEE Std 802-2014 defines multiple types of OUIs, and in addition to
them there is CID (Company ID). There are 4 different registries where
those can be allocated (CID, MA-L, MA-M, and MA-S). One of them uses CID, 
another OUI, and one OUI-36.

CID is 24-bit number assigned by IEEE which shares the same registry as 
MA-L, but is generated so that the X-bit (U/L address bit in mac address)
is set to one, thus it cannot be created to generate universal addresses.

24-bit OUI uses the same MA-L registry and as CID but has the X-bit set to
zero, so it can be used both to generate universal MAC addresses, and 
to identify organization. 

Here you want to allow both 24-bit OUI and CID. To fix this you want
to say something like this:

      Organizationally Unique Identifier (OUI): This is a 24-bit field
      that carries and OUI or CID assigned by the IEEE Registration 
      Authority (RA) as define by the IEEE Std 802 [IEEE.802].

This text is adopted from IEEE Std 802.15.9-2021 section 8.2, which
uses OUI and CID in similar context.

Btw, the IEEE Std 802-2014 has following notes in section 8.2.2:

    NOTE 1—The terms OUI and OUI-36 were previously used by 
    the IEEE RA to refer to what are now called MA–L and
    MA–S, respectively. The acronym OUI without modification
    was used to refer to the 24-bit field assigned by the IEEE
    RA. However, while not appropriate, the acronym OUI has 
    been used to refer to generally to all IEEE RA assignments.
    As a result, the use of OUI is not always consistent within 
    all IEEE standards.
    NOTE 2—The CID comes from the same 24-bit space as the MA-L/OUI.
    A CID assignment is used to identify a company or organization, 
    but is not used to create universal addresses. A CID assignment 
    has the X bit (the U/L address bit in a MAC address) set to one,
    which would place any address created with a CID in the locally 
    administered address space.(13)

...

    (13) More information on CIDs can be found on the IEEE RA tutorial 
    web page, http://standards.ieee.org/develop/regauth/tut/index.html.

IEEE Standards usually also put a footnote after first mention of RA
which says:

    (n) Interested applicants should contact the IEEE Registration Authority,   
        http://standards.ieee.org/develop/regauth/.