Link Management Protocol (LMP)
Note: This ballot was opened for revision 10 and is now closed.
(Ted Hardie) Discuss
In section 3.2.1, there is a recommendation for setting the default values for the HelloInterval to 150ms and the HelloDeadInterval to 500ms. The text seems to indicate that the same default is used when you pass the traffic over an IP network as when you are directly connected. This seems low in the presence of a multi-hop IP network, as you seem likely to end up in Degraded state unnecessarily. Language indicating how to judge a deviation from this default would be very useful. The draft does not seem to be clear on what happens if a TestStatusSuccess or TestStatusFailure message is lost in flight; the current language could be read to indicate that the same TestStatusAck message would be sent in both cases (5.0, just above 5.1) In section 8, Graceful Restart, it is not clear whether Multicast discovery is re-done on interfaces which have had Interface_Ids discovered through that method, or whether these are also assumed to remain stable. In section 12.1, how are bits which are currently reserved later assigned? Notes: In the introduction, paragraph 2 the use of "neighboring" is non-trivially different from the usual, so defining it would be a good idea. The first SHOULD occurs before the Terminology definition. In LMP overview the statement "All LMP packest are run over UDP with an LMP port number [except in some cases]" would be better if "Except in for test messages, which may be limited by the transport mechanism to in-band messaging, all LMP..." In section 3. there is a requirement for a unique 32-bit non-zero integer, but no specification for how to ensure uniqueness. In Section 3.0, is a unicast source address used for the multicast packet? In section 3.1, the nodes MAY continue to retransmit Config messages both when Node_Ids are equal and when a ConfigNack with unacceptable alternate values is received. Some justification for *why*it would seems useful. In Section 3.2.1, it notes that "if other methods are used to indicate bi-directional control channel connectivity", but there are no pointers to other methods; if none are currently specified, it might be useful to change the language to indicate that. Is the Verify_Id monotonically increasing, or random? In 6.0, "procedure can be used to rapidly isolate link failures" seems to mean data link failures, and it might be better to be more precise. In Section 7, the statement "Note that the 32-bit Message_Id value MAY wrap" does not need an RFC 2119 MAY, since it is a statement of fact, not an interoperability point. In 11.3.1, there is a ligatured ae in the text for Down:
(Russ Housley) Discuss
Section 16.1 says: o Security mechanism should provide for well defined key management schemes. The key management schemes should be well analyzed to be cryptographically secure. The key management schemes should be scalable. I think that automated key management SHOULD be provided. Section 16.2 recommends the use of AH in tunnel mode. I would greatly prefer ESP in tunnel mode, even if confidentiality is not turned on. In my opinion, ESP with integrity-only security associations is better. In section 16.2, the term "crypto channel" is not clear. Usually, it means "IPsec security association." Yet, sometimes it refers to both the IKE SA as well as the IPsec SA. I think that IKE SA and IPsec SA can be used. In section 16.2, please change "man-in-the middle attacks" to "man-in-the-middle attacks." Section 16.2 says: Digital signature based authentication is not prone to such problems. It is recommended using digital signature based authentication mechanism where possible. If pre-shared key based authentication is required, then aggressive mode SHOULD be used. IKE pre-shared authentication key values SHOULD be protected in a manner similar to the user's account password. Please change "recommended" to upper case.
(Thomas Narten) Discuss
The LMP Message Type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-127 are allocated by Standards Action, 128-240 are allocated through an Expert Review, and 241-255 are reserved for Private Use. It might be good to expand on expert review just a bit. Is the intention that anyone can get one an allocation? Allocations only for stuff that will clearly eventually be published as an RFC? What sort of review is the expert expected to do? The more text one can give here, the less confusion there will be later should people disagree with the decision of the expert. The LMP Sub-object Class name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range of 0-127 are allocated by Standards Action, 128-247 are allocated through an Expert Review, and 248-255 are reserved for Private Use. seems wrong. the sub-object assignment policy should be determined by the Class. I.e., when you create a class, you define what the policy should be for sub-classes. For some sub-classes, FCFS might be fine, for others maybe only standards action. One-size fits all doesn't seem right. I'd suggest something like: The policy for allocating values out of the LMP Sub-object Class name space is part of the defintion of the specific Class instance. When a Class is defined, its definition must also include a description of the policy underwhich sub-objects are allocated. note: that also means this needs to be done for all of the sub-objects that are defined in this document. The LMP Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use. ditto
(Bert Wijnen) Yes
ID-NITS biting me too Bad chars at 1870 -: 1 lines containing non-US-ASCII characters RFC-Editor note: Pls change on page 33, line 1870: OLD: (i.e., the link is not xE6in service') NEW: (i.e., the link is not 'in service')
(Harald Alvestrand) No Objection
(Steven Bellovin) No Objection
(Randy Bush) No Objection
(Bill Fenner) No Objection
(Ned Freed) No Objection
(Allison Mankin) No Objection
(Erik Nordmark) No Objection
I didn't see anything about autorization/access control in the document. Presumably there is something an implementation needs to do to associate authority for certain TE links with a particular IPsec SA. Nit: In two places it explicitly talks about 22.214.171.124 even though the document supports IPv6 for example: the control channel. This is done by sending the Config message to the Multicast address (126.96.36.199). The ConfigAck and ConfigNack How about at least saying "188.8.131.52 or ff02::1" instead.