Link Management Protocol (LMP)
draft-ietf-ccamp-lmp-10

Comments from SMB after the telechat, checking with
others.

SMB:
Most of my comments have not been addressed.  I said the following
about 16.2:

                The IPsec selectors are all SHOULDs -- what are the MUSTs?
                Setting the port number to 0 means that all UDP traffic between
                those nodes is protected -- is that right? I though the
                document spoke of an LMP port.

Point 2 still has SHOULD instead of MUST, and still says UDP port 0.

                The channel identifer is part of the payload, not the IP or UDP
                headers, and thus can't be a selector.

There is still text about the channel identifier, in a context that
makes it appear like part of the selector.

                IKE is listed as a SHOULD, not a MUST, but the requirements
                mandate replay detection. You can't do that with manual keying.
                (The requirements also mandate support for manual keying.)
                If replay protection is needed, either IKE must be required,
                or an application-specific replay protection mechanism must
                be defined.

16.1 now speaks of automatic key management, but it says "should" (not
SHOULD), when it needs to say MUST, and point 2 of 16.2 still mandates
manual keying.  That has to be deleted.

[Ballot discuss]
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 224.0.0.1 even though the
document supports IPv6 for example:
      the control channel. This is done by sending the Config message to
      the Multicast address (224.0.0.1). The ConfigAck and ConfigNack

How about at least saying "224.0.0.1 or ff02::1" instead.

[Ballot discuss]
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')

[Ballot discuss]
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 224.0.0.1 even though the
document supports IPv6 for example:
      the control channel. This is done by sending the Config message to
      the Multicast address (224.0.0.1). The ConfigAck and ConfigNack

How about at least saying "224.0.0.1 or ff02::1" instead.

[Ballot discuss]
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')

[Ballot 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

[Ballot 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.

[Ballot 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:

[Ballot discuss]
I'm not sure how much the ccamp and forces people talk, but isn't this
sentence:

      the control channel MUST terminate on the same two nodes
      that the TE link spans.

incorrect with remote control elements?

16.2:
                The IPsec selectors are all SHOULDs -- what are the MUSTs?
                Setting the port number to 0 means that all UDP traffic between
                those nodes is protected -- is that right? I though the
                document spoke of an LMP port.

                The channel identifer is part of the payload, not the IP or UDP
                headers, and thus can't be a selector.

                IKE is listed as a SHOULD, not a MUST, but the requirements
                mandate replay detection. You can't do that with manual keying.
                (The requirements also mandate support for manual keying.)
                If replay protection is needed, either IKE must be required,
                or an application-specific replay protection mechanism must
                be defined.

Various IESG comments and concerns to be addressed via a new revision.

Also note that a few ADs have a 2-week Defer for reading the doc.

Here are the comments:

Russ:
      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.

Steve:
I'm not sure how much the ccamp and forces people talk, but isn't this
sentence:

      the control channel MUST terminate on the same two nodes
      that the TE link spans.

incorrect with remote control elements?

16.2:
                The IPsec selectors are all SHOULDs -- what are the MUSTs?
                Setting the port number to 0 means that all UDP traffic between
                those nodes is protected -- is that right? I though the
                document spoke of an LMP port.

                The channel identifer is part of the payload, not the IP or UDP
                headers, and thus can't be a selector.

                IKE is listed as a SHOULD, not a MUST, but the requirements
                mandate replay detection. You can't do that with manual keying.
                (The requirements also mandate support for manual keying.)
                If replay protection is needed, either IKE must be required,
                or an application-specific replay protection mechanism must
                be defined.

Ted:
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:

COMMENTS:
=========
Bert:
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')

Erik:
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 224.0.0.1 even though the
document supports IPv6 for example:
      the control channel. This is done by sending the Config message to
      the Multicast address (224.0.0.1). The ConfigAck and ConfigNack

How about at least saying "224.0.0.1 or ff02::1" instead.

AD review posted to WG mailing list:

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: donderdag 13 maart 2003 22:16
To: Ccamp-wg (E-mail)
Subject: AD review of draft-ietf-ccamp-lmp-07.txt


Since I do not intend to request IETF Last Call before the
IETF meeting in SF is over, maybe the authors can do a quick
rev to try and address the following points.

Here are my review comments

- More or less serious:
- scenario at end of sect 3.2.2
  WOuld it not be wise to include the "waiting for interval
  to expire" before a resend is done? Otherwise, if people
  forget, I can see congestion being created.
- IANA considerations
  - I wonder if you want "IETF Consensus" based assignments.
    There was quite some debate as to what that means recently.
    Maybe you mean or want "standards action" instead?
  - I also wonder... values 0-127 are allocated by expert review,
    while the values in this doc (and a few other lmp related
    docs on my plate) are in that space and are on stds track,
    so they would be "standards action" based.
  - So pls make sure that you have documented what you want/intend
- sect 12.1 as example (this occurs several times). It says:
  Msg Type: 8 bits.  The following values are defined.  All other
            values are reserved and should be sent as zero and ignored
            on receipt.
  But the values seem to be integer values and not bits. So I do not
  understand the "All other values are reserved and should be sent as zero.."
  especially the "should be sent as zero" seems strange in this case.

Nits:
- sect 1. Expand acronyms when used for first time
  examples are DWDM, TDm, WDM. There may be others
- When I read (2nd para pge 9)
    LMP adjacency.  The value of the Message_Id is monotonically
    increasing and only decreases when the value wraps.
  Then I think I would change
    and only decreases when the value wraps.
  into
    and wraps when teh max value is reached
- 2nd para sect 3.1
  I guess that Node-Id of two nodes can never be equal.
  But if such happens (by error) who is then the winning node,
  or what should the behaviour be?
- sect 3.2.1 2nd and 3rd para
  Is for example a 1 millisecond interval valid?
  WOuld it possibly cause congestion (rfc2914) ??
- sect 3.2.2 (3rd para) explains when difference can be more
  than 1. I think that in the case of UDP packet loss, the
  diff can slo be more then 1, no?
- at a few places I see msoft (non-ASCII) characters
  p48, p57, maybe other places too.
- I see at various places 16-bit flags (or other) fields and then
  values are shown as:
    0x01
    0x02
  This may not be 100% clear as to which bits are then used.
  Do you mean
    0x0001
    0x0002
  An example is page 53
- Last sentence of sect 18 ?? DId that sonet test stuff not go to
  a separate document ??

Thanks,
Bert

AD review comments (posted to ccamp list):

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: donderdag 13 maart 2003 22:16
To: Ccamp-wg (E-mail)
Subject: AD review of draft-ietf-ccamp-lmp-07.txt


Since I do not intend to request IETF Last Call before the
IETF meeting in SF is over, maybe the authors can do a quick
rev to try and address the following points.

Here are my review comments

- More or less serious:
- scenario at end of sect 3.2.2
  WOuld it not be wise to include the "waiting for interval
  to expire" before a resend is done? Otherwise, if people
  forget, I can see congestion being created.
- IANA considerations
  - I wonder if you want "IETF Consensus" based assignments.
    There was quite some debate as to what that means recently.
    Maybe you mean or want "standards action" instead?
  - I also wonder... values 0-127 are allocated by expert review,
    while the values in this doc (and a few other lmp related
    docs on my plate) are in that space and are on stds track,
    so they would be "standards action" based.
  - So pls make sure that you have documented what you want/intend
- sect 12.1 as example (this occurs several times). It says:
  Msg Type: 8 bits.  The following values are defined.  All other
            values are reserved and should be sent as zero and ignored
            on receipt.
  But the values seem to be integer values and not bits. So I do not
  understand the "All other values are reserved and should be sent as zero.."
  especially the "should be sent as zero" seems strange in this case.

Nits:
- sect 1. Expand acronyms when used for first time
  examples are DWDM, TDm, WDM. There may be others
- When I read (2nd para pge 9)
    LMP adjacency.  The value of the Message_Id is monotonically
    increasing and only decreases when the value wraps.
  Then I think I would change
    and only decreases when the value wraps.
  into
    and wraps when teh max value is reached
- 2nd para sect 3.1
  I guess that Node-Id of two nodes can never be equal.
  But if such happens (by error) who is then the winning node,
  or what should the behaviour be?
- sect 3.2.1 2nd and 3rd para
  Is for example a 1 millisecond interval valid?
  WOuld it possibly cause congestion (rfc2914) ??
- sect 3.2.2 (3rd para) explains when difference can be more
  than 1. I think that in the case of UDP packet loss, the
  diff can slo be more then 1, no?
- at a few places I see msoft (non-ASCII) characters
  p48, p57, maybe other places too.
- I see at various places 16-bit flags (or other) fields and then
  values are shown as:
    0x01
    0x02
  This may not be 100% clear as to which bits are then used.
  Do you mean
    0x0001
    0x0002
  An example is page 53
- Last sentence of sect 18 ?? DId that sonet test stuff not go to
  a separate document ??

Thanks,
Bert