OSPF Link-Local Signaling
draft-ietf-ospf-lls-08

[Ballot discuss]
I would suggest some more crisp text that makes clear the criteria for approving TLVs i.e. for the goal of OSPF Link-Local signaling. Unless the intent is to allow for this technique to become a vehicle for transfering arbitrary information, it would be good to make clear that such overloading of the semantics is not permitted.

[Ballot discuss]
(Updated for version -06)

I have reviewed draft-ietf-ospf-lls-06. Overall, the document looks
good, but I have the following concerns that I'd like to discuss
before recommending approval of the document:

- The document needs to describe its relationship to RFC 4813, and list
changes done since it (based on quickly look, this includes at least
OSPFv3 support and changed format for Private/Enterprise TLVs in
Section 2.6), and explain why this is upgraded from Experimental
to Standards Track (i.e. what was learned from the experiment).

- A question: do you have data to show that existing implementations
(that don't support RFC 4813/this draft) actually behave as assumed
here? (That is, accept OSPF packets with extra junk at the end -- this
sounds like the kind of thing implementations often get wrong....) 
I assume you have such data, but briefly summarizing the real-world
situation in Section 4 would be very useful. (Authors have replied
they have data, but it hasn't been added to the document.)

- Section 3 is unclear whether the IANA is asked to create a registry
for this document, or just update the registry created for RFC 4813 to
point to this document. (The authors replied it's the latter, but
the document doesn't say it.)


From Stephen Farrell's SecDir review:

- Section 2.5 is quite vague on exactly what data is used when
calculating AuthData.  Does "the LLS data block" mean the whole
LLS data block (including the CA-TLV, presumably with AuthData
set to zero or something?), or just the TLVs before this TLV?

[Ballot comment]
> 2.4.  Extended Options TLV
>  Bits in the Value field do not have any semantics from the point of
>    view of the LLS mechanism.  This field MAY be used to announce some
>    OSPF capabilities that are link-specific.  Also, other OSPF
>    extensions MAY allocate bits in the bit vector to perform boolean
>    link-local signaling.

This field doesn't seem to scope the LLS options to be link-local in nature, which I would think would be a minimum requirement. Further, it seems that the bits are not even restricted to being "Extended Options" given that there is explicit wording allowing the bits to be used as boolean flags.

I think that at a minimum this needs to be scoped to link-local signaling, and should probably be renamed to "Extended Flags" or some such so that people will not mistake that it is only used for capability option signaling, but also is open for use for any sort of boolean signaling.

> 2.1.  Options Field

I would rename this section to "L-bit in Options Field" so as not to imply that the Options field is being defined in this document, just that the L bit is.

> 2.6.  Private TLVs
All other TLVs come with a picture, except this one.

>    The data included in the LLS block attached to a Hello packet MAY be
>    used for dynamic signaling since Hello packets may be sent at any
>    time in time.

time in time?

[Ballot discuss]
My discuss is really a question. I apologize that I didn't get a chance to ask the authors prior to the telechat and expect that I am quite likely to clear during the telechat.

How much testing and/or deployment experience is there with this feature? Are we confident that there aren't any existing implementations that suffer some sort of unfortunate reaction (such as crashing) when they get OSPF packets that contain TLVs encoded in this manner?

[Ballot discuss]
1. The IANA considerations section should be expressed in terms of RFC 5226, which replaces RFC 2434 whichwould have been the correct reference for [IANA]. If I understand correctly the policy for values 0-32767 is intended to be IETF Review, while the policy for values 32768-65536 is Expert Review.

2. It is not clear to me what Private and Experimental TLVs mean. Will an Expermental TLV be marked in any way, so that routers know that they are dealing with an experiment? I do not understand how this is possible, and unless there is some good reason I suggest to drop Experimental and leave this option for private usage only.

3. I would suggest some more crisp text that makes clear the criteria for approving TLVs i.e. for the goal of OSPF Link-Local signaling. Unless the intent is to allow for this technique to become a vehicle for transfering arbitrary information, it would be good to make clear that such overloading of the semantics is not permitted.

[Ballot discuss]
Two issues I would like to discuss about LLS.  Assuming that these issues need to be
addressed, I believe they could be handled in the security considerations.

(1) Since LLS is optional and is not a negotiated capability, there is no way to determine
if the OSPF router receiving the OSPF packet is using this information.  Section 2 glosses
over these complications by stating "changes made due to LLS block TLV's do not affect
the basic routing when interacting with non-LLS routers." 

This strikes me as a goal rather than a promise. I think text describing the implications
of poorly designed LLS data processing is needed, and provide reasonable guidance for
protocol designers that want to use this feature.

(2) I think there is a decent chance that a router will be connected to a router that either
doesn't recognize LLS at all or expects different information to be transmitted (routers
from a different domain or manfacturer?).  Given that, wouldn't it be prudent to recommend
that this feature be configurable on a per-interface basis?

[Ballot comment]
The security considerations section would benefit from a few pointers and a bit more text.
I suggest adding the following to the first paragraph:

Security Considerations inherited from OSPFv2 are described in [OSPFV2].

I would suggest adding the following to the second paragraph:

Security considerations inherited from OSPFv3 are described in [OSPFv3] and [OSPFV3AUTH].

[Ballot discuss]
After having reviewed this document I have some questions that I really think need to be answered before I am feeling comfortable allowing this document to be approved.

This document allows for up to 64k big data objects to be added to OSPF messages. This clearly affects the amount of data consumed by OSPF however, this document seems to have no discussion about the potential transport issues that adding arbitrary data objects can cause.

Fragmentation of OSPF messages. A quick glance in RFC 2328 indicates that there are no built in fragmentation support. The reliance on IP fragmentation have two issues:

1. First how the addition of extra data changes the loss probability for the message due to that a single loss among the fragments results in message delivery failure.

2. That the potential size of the arbitrary data is not 64k, but actually 64k minus all the other message parts in the OSPF message.

Then there is the issue of congestion avoidance and transmission rate control. I have now idea how this works in OSPF (please enlighten me), but enlarging the messages clearly have a potential impact on the message transmission behavior and consumed resources that at least needs to be commented on. Are you certain that the existing mechanism is suitable for arbitrary data?

What reliability are provided for the arbitrary data? It seems that the core messages in OSPF handles reliability in various protocol dependent ways directly related to the message type. It is not at all clear that the arbitrary data object will have the same reliability requirements that the OSPF message it is being sent in. That needs consideration.

[Ballot comment]
- Stephen Farrell's SecDir review had some suggestions for 
  clarification and editorial nits.
- [IANA] has been obsoleted by RFC 5226.
- [OSPFV3] has been obsoleted by RFC 5340.

[Ballot discuss]
I have reviewed draft-ietf-ospf-lls-05. Overall, the document looks
good, but I have the following concerns that I'd like to discuss
before recommending approval of the document:

- Should this document (once approved) obsolete RFC 4813?  Either way,
the document needs to describe its relationship to RFC 4813, and list
changes done since it (based on quickly look, this includes at least
OSPFv3 support and changed format for Private/Enterprise TLVs in
Section 2.6), and explain why this is upgraded from Experimental
to Standards Track (i.e. what was learned from the experiment).

- A question: do you have data to show that existing implementations
(that don't support RFC 4813/this draft) actually behave as assumed
here? (That is, accept OSPF packets with extra junk at the end -- this
sounds like the kind of thing implementations often get wrong....) 
I assume you have such data, but briefly summarizing the real-world
situation in Section 4 would be very useful.

- Section 3 is unclear whether the IANA is asked to create a registry
for this document, or just update the registry created for RFC 4813 to
point to this document (or possibly something else).

From Stephen Farrell's SecDir review (which also needs a reply):

- Section 2.2 describes the use of the checksum field, but never says
what to do if the checksum is wrong. Is just the LLS block ignored or
the entire OSPF message?

- Section 2.2 doesn't say whether the checksum bits (presumably
zero'd?) are considered part of the LLS block when calculating the
checksum.

- The spec doesn't say what to put in the checksum field when using
the Cryptographic Authentication TLV (presumably 0, but should be said)

- Section 2.5 is quite vague on exactly what data is used when
calculating AuthData. Does it include the TLVs following CA-TLV?
(Presumably yes, but the text should say so.) What's placed in
the AuthData field during the calculation? (Presumably zeroes,
but the text doesn't say.)

[Ballot comment]
Section 2., paragraph 4:
>    The LLS data block MAY be attached to OSPF Hello and DD packets.

  The "MAY" is ambiguous - do you mean "MUST only"?


Section 6.1., paragraph 4:
>    [OSPFV3]  Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
>              RFC 2740, December 1999.

  Obsolete normative reference: RFC 2740 (ref. 'OSPFV3') (Obsoleted by
  RFC 5340). Please add RFC Editor Note.

[Ballot discuss]
Spencer Dawkins raised a few questions in his Gen-ART Review that was
  posted on 2008-11-05.  There was not a response to these questions.
  Please address these questions.
 
  The document says:
  >
  > The 16-bit LLS Data Length field contains the length (in 32-bit
  > words) of the LLS block including the header and payload.
  > Implementations MUST NOT use the Length field in the IP packet header
  > to determine the length of the LLS data block.
  >
  Spencer asked: "I'm not sure this is a 2119 MUST NOT - aren't you just
  saying that if you try it, you'll fail?"

  The document says:
  >
  > The CA-TLV MUST only appear once in the the LLS block.  Also, when
  > present, this TLV SHOULD be the last TLV in the LLS block.
  >
  Spencer asked: "Why SHOULD and not MUST? At a minimum, I would expect
  to see some description of what should happen if CA-TLV is NOT the
  last TLV in the LLS block - and if the expectation is that processing
  continues, I'm not sure what this sentence means..."

IANA Last Call comments:

Please confirm that we have identified these actions correctly:

Upon the approval of this document, IANA will make the following
changes in the "Open Shortest Path First (OSPF) Link Local
Signalling (LLS) - Type/Length/Value Identifiers (TLV)" registry
at http://www.iana.org/assignments/ospf-lls-tlvs:

OLD:

Registry Name: Link Local Signalling TLV Identifiers (LLS Types)
Reference: [RFC4813]
Registration Rules: IETF Consensus

Registry:
LLS Type Name Reference
----------- -------------------------------------- ---------
0 Reserved
1 Extended Options [RFC4813]
2 Cryptographic Authentication [RFC4813]
3-32767 Unassigned
32768-65535 Reserved for Private Use

Sub-registy: LLS Type 1 Extended Options
Reference: [RFC4813]
Registration Rules: IETF Consensus

Registry:
Extended Options Bit Name Reference
------------------ --------------------------------- ---------
0x00000001 LSDB Resynchronization (LR) [OOB] [RFC4813]
0x00000002 Restart Signal (RS-bit) [RESTART] [RFC4813]


NEW:

Registry Name: Link Local Signalling TLV Identifiers (LLS Types)
Reference: [RFC4813]
Registration Rules: IETF Consensus

Registry:
LLS Type Name Reference
----------- ----------------------------- ---------
0 Reserved [RFC-ietf-ospf-lls-05.txt]
1 Extended Options [RFC-ietf-ospf-lls-05.txt]
2 Cryptographic Authentication [RFC-ietf-ospf-lls-05.txt]
3-32767 Unassigned
32768-65535 Reserved for Private Use [RFC-ietf-ospf-lls-05.txt]

Sub-registy: LLS Type 1 Extended Options
Reference: [RFC4813]
Registration Rules: IETF Consensus

Registry:
Extended Options Bit Name Reference
------------------ --------------------------------- ---------
0x00000001 LSDB Resynchronization (LR) [OOB] [RFC-ietf-ospf-lls-05.txt]
0x00000002 Restart Signal (RS-bit) [RESTART] [RFC-ietf-ospf-lls-05.txt]

If we should add "[RFC-ietf-ospf-lls-05.txt]" to the current
references, rather than replace the current references, please
let us know.

Proto writeup by Acee Lindem:

  1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do they believe this ID is ready
    to forward to the IESG for publication?

    Yes

  2. Has the document had adequate review from both key WG members and
    key non-WG members?

    Yes - I've reviewed it and we had some good comments during the WG
    last call.

    Do you have any concerns about the depth or
    breadth of the reviews that have been performed?
   
    No

  3. Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

    No

  4. Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of? For example,
    perhaps you are uncomfortable with certain parts of the document,
    or have concerns whether there really is a need for it. In any
    event, if your issues have been discussed in the WG and the WG has
    indicated it that it still wishes to advance the document, detail
    those concerns in the write-up.

    No

  5. How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with
    others being silent, or does the WG as a whole understand and
    agree with it?

    This draft represents the promotion of RFC 4813 from experimental
    to proposed standard. It also extends LLS to OSPFv3 which is
    simpler since authentication is handled via IPsec.


  6. Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict
    in separate email to the Responsible Area Director.

    No

  7. Have the chairs verified that the document adheres to all
    of the ID Checklist items?

idnits 2.09.00

tmp/draft-ietf-ospf-lls-05.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  ** Obsolete normative reference: RFC 2740 (ref. 'OSPFV3') (Obsoleted by RFC
    5340)


    Summary: 1 error (**), 0 warnings (==), 0 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

-------------------------------------------------------------------------------

This can be fixed in a new revision or as part of the RFC Editor
process (they check this).


  8. Is the document split into normative and informative references?

    Yes

    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state?
    (note here that the RFC editor will not publish an RFC with
    normative references to IDs, it will delay publication until all
    such IDs are also ready for publication as RFCs.)

    No - only references to RFCs.

  9. What is the intended status of the document? (e.g., Proposed
    Standard, Informational?)

    Proposed Standard

10. For Standards Track and BCP documents, the IESG approval
    announcement includes a write-up section with the following 
    sections:

    * Technical Summary
    * Working Group Summary
    * Protocol Quality

  OSPF LLS represents an extendible backward compatible mechanism for
  signaling protocol parametes and events to immediate OSPF neighbors.
  The OSPFv2 is currently deployed in Cisco IOS-based routers. The
  OSPFv3 version of LLS has been implemented by several independent
  parties in the context of the OSPF MANET experimental drafts.