Subject: [forces] IANA and Security Sections

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 2 Jul 2011 16:27:08 +0800

Hi all, 
 
Below is the text for the IANA consideration section and the Security Considerations section. Pls review it and make comments.

Sorry that there is a table inside which is not well aligned because of the plane text mode.

thanks a lot.

Weiming

------------------
1. IANA Considerations
 
The LFB library needs for a unique XML namespace for ForCES library definition usage. IANA has registered a new XML namespace, as per the guidelines in RFC 3688 [RFC3688]. The URI for this namespace is urn:ietf:params:xml:ns:forces:lfbmodel:1.0. 
 
The LFB library needs for unique class names and numeric class identifiers of all LFBs. Besides, the document also needs to define the following namespaces:
 
.Metadata ID, Section 4.3 and 4.4 
.Exception ID, Section 4.4
.Validate Error ID, Section 4.4
 
1.1.LFB Class Names and LFB Class Identifiers
 
In order to have well defined ForCES LFB Classes and identifiers for those classes, IANA has created a registry of LFB class names, corresponding class identifiers, and the document that defines the LFB class. 
 
LFB classes defined by this document belongs to IETF defined LFBs by Standard Track RFCs. The LFB class identifier space ranges from 3 to 65535.
 
The assignment of LFB class names and LFB class identifiers is as in the following table.
 
LFB Class Identifier
LFB Class Name
Description
Refererence

3
EtherPHYCop
Define an Ethernet port abstracted at physical layer. 
RFC ????(this document)

4
EtherMACIn
Define an Ethernet input port at MAC data link layer.
RFC ????

5
EtherClassifier
Define the process to decapsulate Ethernet packets and classify the packets.
RFC ????

6
EtherEncapsulator
Define the process to encapsulate IP packets to Ethernet packets. 
RFC ????

7
EtherMACOut
Define an Ethernet output port at MAC data link layer.
RFC ????

8
IPv4Validator
Perform IPv4 packets validation.
RFC ????

9
IPv6Validator
Perform IPv6 packets validation.
RFC ????

10
IPv4UcastLPM
Perform IPv4 Longest Prefix Match Lookup.
RFC ????

11
IPv6UcastLPM
Perform IPv6 Longest Prefix Match Lookup.
RFC ????

12
IPv4NextHop
Define the process of selecting Ipv4 next hop action.
RFC ????

13
IPv6NextHop
Define the process of selecting Ipv6 next hop action.
RFC ????

14
RedirectIn
Define the process for CE to inject data packets into FE LFB topology.
RFC ????

15
RedirectOut
Define the process for LFBs in FE to deliver data packets to CE.
RFC ????

16
BasicMetadataDispatch
Dispatch input packets to a group output according to a metadata. 
RFC ????

17
GenericScheduler
Define a preliminary generic scheduling process.
RFC ????

 
1.2.Metadata ID
 
The Metadata ID namespace is 32 bits long.  The following is the guideline for managing the namespace.
 
Metadata ID 0x00000000-0x7FFFFFFF
Metadata with IDs in this range are Specification Required [RFC5226].  A metadata ID using this range MUST be documented in an RFC or other permanent and readily available references.
 
Values assigned by this specification:
 
Value           Name
0x00000001       PHYPortID
0x00000002          SrcMAC 
0x00000003          DstMAC 
0x00000004          LogicalPortID 
0x00000005       EtherType
0x00000006       VlanID
0x00000007          VlanPriority 
0x00000008       NexthopIPv4Addr 
0x00000009       NexthopIPv6Addr 
0x0000000A       HopSelector 
0x0000000B       ExceptionID 
0x0000000C       ValidateErrorID
0x0000000D        L3PortID
0x0000000E        RedirectIndex 
0x0000000F       MediaEncapInfoIndex 
   
Metadata ID 0x80000000-0xFFFFFFFFF
Metadata IDs in this range are reserved for vendor private extensions and are the responsibility of individuals.
 
1.3.Exception ID
 
The Exception ID namespace is 32 bits long.  The following is the guideline for managing the namespace.
 
Exception ID 0x00000000-0x7FFFFFFF
Exception IDs in this range are Specification Required [RFC5226].  An exception ID using this range MUST be documented in an RFC or other permanent and readily available references.
 
Values assigned by this specification:
 
Value           Name
0x00000000       Any unrecognized exception case   
0x00000001       BroadCastPacket
0x00000002          BadTTL
0x00000003          IPv4HeaderLengthMismatch 
0x00000004          LengthMismatch 
0x00000005       RouterAlertOptions
0x00000006       RouteInTableNotFound
0x00000007          NextHopInvalid 
0x00000008       FragRequired   
0x00000009       LocalDelivery
0x0000000A       GenerateICMP
0x0000000B       PrefixIndexInvalid
0x0000000C       IPv6HopLimitZero
0x0000000D        IPv6NextHeaderHBH
   
Exception ID 0x80000000-0xFFFFFFFFF
Exception IDs in this range are reserved for vendor private extensions and are the responsibility of individuals.

1.4.Validate Error ID
 
The Validate Error ID namespace is 32 bits long.  The following is the guideline for managing the namespace.
 
Validate Error ID 0x00000000-0x7FFFFFFF
Validate Error IDs in this range are Specification Required [RFC5226].  An exception ID using this range MUST be documented in an RFC or other permanent and readily available references.
 
Values assigned by this specification:
 
Value           Name
0x00000000       Any unrecognized validate error case
0x00000001       InvalidIPv4PacketSize
0x00000002          NotIPv4Packet
0x00000003          InvalidIPv4HeaderLengthSize
0x00000004          InvalidIPv4Checksum 
0x00000005       InvalidIPv4SrcAddrCase1
0x00000006       InvalidIPv4SrcAddrCase2
0x00000007          InvalidIPv4SrcAddrCase3 
0x00000008       InvalidIPv4SrcAddrCase4
0x00000009       InvalidIPv6PakcetSize
0x0000000A       NotIPv6Packet
0x0000000B       InvalidIPv6SrcAddrCase1
0x0000000C       InvalidIPv6SrcAddrCase2
0x0000000D        InvalidIPv6DstAddrCase1
   
Validate Error ID 0x80000000-0xFFFFFFFFF
Validate Error IDs in this range are reserved for vendor private extensions and are the responsibility of individuals.
 
2. Security Considerations
 
The ForCES framework document [RFC3746] provides a comprehensive security analysis for the overall ForCES architecture.  For example, the ForCES protocol entities must be authenticated per the ForCES requirements before they can access the information elements described in this document via ForCES.  Access to the information contained in this document is accomplished via the ForCES protocol[RFC5810], which is defined in separate documents, and thus the security issues will be addressed there.

---

From: "t.petch" <[email-masked]>
Date: Sat, 2 Jul 2011 09:52:47 +0200

I think that the IANA section needs more work.

Think of IANA as a administrative function with no technical skills who have to
be told precisely what to do, and they will do a superb job for you.

You need to tell them that this is (or is not) ForCES (and how to capitalise
it:-), that these all form part of this part of the IANA Protocol Registry and
precisely what name you use for the section of the registry, and choosing a
usable, accurate well thought out name makes a big difference in the long run.

For each section, you need to specify the relevant fields (which you more or
less have done).

For each section, you must specify the initial entries, if any, and where they
are defined
eg RFCxxxx section 4.2.
-- Note to RFC Editor replace xxxx with the number of this RFC --

and what the rules for adding entries to the registry are, FCFS, Standards
Track, Expert review etc.

Border Gateway Protocol is not a bad example in the Protocl Registry.

Tom Petch

----- Original Message -----
From: "Wang,Weiming" <[email-masked]>
To: "Wang,Weiming" <[email-masked]>; "Haleplidis Evangelos"
<[email-masked]>; "'forces'" <[email-masked]>
Cc: "'Joel M. Halpern'" <[email-masked]>; "'Chuanhuang Li'"
<[email-masked]>; "'wmwang'" <[email-masked]>
Sent: Saturday, July 02, 2011 10:27 AM
Subject: [forces] IANA and Security Sections

> Hi all,
>
> Below is the text for the IANA consideration section and the Security
Considerations section. Pls review it and make comments.
> The LFB library needs for a unique XML namespace for ForCES library definition
usage. IANA has registered a new XML namespace, as per the guidelines in RFC
3688 [RFC3688]. The URI for this namespace is
urn:ietf:params:xml:ns:forces:lfbmodel:1.0.
>
> The LFB library needs for unique class names and numeric class identifiers of
all LFBs. Besides, the document also needs to define the following namespaces:
> In order to have well defined ForCES LFB Classes and identifiers for those
classes, IANA has created a registry of LFB class names, corresponding class
identifiers, and the document that defines the LFB class.
>
> LFB classes defined by this document belongs to IETF defined LFBs by Standard
Track RFCs. The LFB class identifier space ranges from 3 to 65535.
> Metadata with IDs in this range are Specification Required [RFC5226].  A
metadata ID using this range MUST be documented in an RFC or other permanent and
readily available references.
> Exception IDs in this range are Specification Required [RFC5226].  An
exception ID using this range MUST be documented in an RFC or other permanent
and readily available references.
> Validate Error IDs in this range are Specification Required [RFC5226].  An
exception ID using this range MUST be documented in an RFC or other permanent
and readily available references.
> Validate Error IDs in this range are reserved for vendor private extensions
and are the responsibility of individuals.
> The ForCES framework document [RFC3746] provides a comprehensive security
analysis for the overall ForCES architecture.  For example, the ForCES protocol
entities must be authenticated per the ForCES requirements before they can
access the information elements described in this document via ForCES.  Access
to the information contained in this document is accomplished via the ForCES
protocol[RFC5810], which is defined in separate documents, and thus the security
issues will be addressed there.
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces