Dynamic Link Exchange Protocol (DLEP)
draft-ietf-manet-dlep-29

[Ballot comment]
This is generally a well written document and I enjoyed reading it.

Section 14 (Security Considerations) now says:

  At the transport layer, when TLS is in use, each peer SHOULD check
  the validity of credentials presented by the other peer during TLS
  session establishment.  Implementations following the "dedicated
  deployments" model attempting use of TLS MAY need to consider use of
  pre-shared keys for credentials

I think you need an reference here, such as RFC 5487.

  , and provide specialized techniques
  for peer identity validation.

Section 4 of 7925 has some discussion of credential types for IoT, some of which might be useful in DLEP. But I am not sure whether this is the great reference. (If you add it, you probably should make it Informative.)

  Implementations following the
  "networked deployment" model described in Implementation Scenarios
  SHOULD refer to [RFC7525] for additional details.

[Ballot discuss]
This is generally a well written document and I enjoyed reading it.

I have one remaining question which I would like to quickly discuss before recommending approval of this document:

Section 14 (Security Considerations) now says:

  When TLS is in use, each peer SHOULD check the validity of
  credentials presented by the other peer during TLS session
  establishment.  Mobile implementations MAY need to consider use of
  pre-shared keys for credentials; implementations following the
  "networked deployment" model described in Implementation Scenarios
  SHOULD refer to [RFC7525] for additional details.

RFC 7525 that you are referencing contains recommendations on version of TLS and ciphersuites to use.
Section 6.1 of RFC 7525 talks about "Host Name Validation". I don't think this section applies to DLEP. So can you elaborate on how server identity is going to be verified using pre-shared keys and which parts of RFC 7525 do you think apply to DLEP?

[Ballot discuss]
This is generally a well written document and I enjoyed reading it.

I have one remaining question which I would like to discuss before recommending approval of this document:

3) 14.  Security Considerations

  At the transport layer, implementations of DLEP SHOULD implement, and
  use, TLS [RFC5246] to protect the TCP session.  Deployments that are
  protected by strong physical security (e.g., deployments where the
  DLEP router and modem are the only devices on a physical Layer 2
  segment) may consider use of DLEP without TLS.  When TLS is in use,
  each peer SHOULD check the validity of credentials presented by the
  other peer during TLS session extablishment.  Refer to [RFC7525] for
  additional details.

How can credentials presented by the other peer can be validated?
RFC 7525 is referencing RFC 6125, which talks about hostname validation,
which is something which might not apply to DLEP deployments?

[Ballot comment]
Thank you for addressing my earlier DISCUSS points.

13.  DLEP Data Items

  Following is the list of core Data Items that MUST be recognized by a
  DLEP compliant implementation.  As mentioned before, not all Data
  Items need be used during a session, but an implementation MUST
  correctly process these Data Items when correctly associated with a
  Signal or Message.

Is "skip over or ignore" a valid way to "correctly process"? I think so, but
this might not be obvious from the text as written.

[Ballot comment]

- 5.1: Is a modem supposed to ignore peer discovery
signals from routers with which the modem does not have a
TCP connection?

- 10.7: This says: "If the modem is capable of
understanding and forwarding this information (via
mechanisms not defined by DLEP)," I don't get why that's
here, can you explain? If modem-modem comms is part of
DLEP deployments (even if not fully spec'd) then that does
change the security model.

- 10.9 and elsewhere: none of these messages have anything
like a cookie. Why not? That'd help mitigate potential off
path attacks, where we currently depend solely on TTL=255
(and TLS, which seems to not be some people's favourite;-)

- 11.8/9: are there any special addresses that MUST NOT
occur here? E.g. ::1, 127.0.0.10? What about the addresses
IANA allocates for you from 13.14/15?

- 11.10/11: what does prefix=0 mean?

- I agree with Alexey's DISCUSS#3, the TLS stuff needs
more work to be usable. Maybe recommend PSK?

[Ballot comment]
For the Latency and Relative Link Quality metrics, it seems like allowing their measurement methods to be implementation-dependent reduces their usefulness. If two different implementations calculate these in different ways, then the results may not be comparable. Are these not meant to be compared between different destination implementations?

[Ballot discuss]
Am I missing something or does the doc not specify which policy/policies should be used for registration of new values in these new registries? (Also previously mentioned by the tsv-art reviewer - thx!)

[Ballot comment]
Technical comments:
1) You say
"If a Signal is received with a TTL value that is NOT equal to 255,
  the receiving implementation MUST ignore the Signal."
and
"If a packet in the TCP stream is received with a TTL value other than
  255, the receiving implementation MUST immediately transition to the
  Session Reset state."
However, there is no requirement that the initial TTL must be 225. I guess you can just add a sentence to require this from the sender.

2) You say:
"If an unrecognized, or unexpected Signal is received, or a received
  Signal contains unrecognized, invalid, or disallowed duplicate Data
  Items, the receiving implementation MUST ignore the Signal."
Would it make sense to also send an error signal in this case or was this omitted as it could be used as a DoS reflector? If so, maybe add a sentence.

3) in section 10.5:
"DLEP Heartbeats are not fully established until receipt of the
  Session Initialization Response Message (Section 10.6), and therefore
  implementations MUST use their own timeout and retry heuristics for
  this Message."
I'm not sure if re-trying makes sense given that TCP should deliver the data reliably here. I guess time-out to terminate the TCP and a local error log would be more appropriate.

4) section 11.16:
"The Latency value is reported as transmission delay.  The calculation
  of latency is implementation dependent.  For example, the latency may
  be a running average calculated from the internal queuing."
Not sure if this is very useful. I would either recommend to define to report the average (or max?) latency (where the calculation is still of course implementation specific) or have three different items for min, max, and current average.

Editorial comment:
The 2119 boilerplate has a weird position as part of a subsection. I assume that this is intended to say that the normative text starts here but it could also be interpreted to be just part of the subsection. Also having 'Requirements' (3.1) as subsection of 'Extension' (3) seems to be an error. I would suggest to have the 2119 boilerplate as well as the Requirements section both as own main level sections. And sec 3 and sec 7 are both called 'Extensions'...?

Further:
I didn't see a reply to the tsv-art review by Micheal Scharf. Have those comments be addressed?
Here is his review on -25:
This draft is basically ready for publication, but has nits that should be fixed before publication.

TSV-ART review comments:

* I think the DLEP protocol makes an implicit assumption that the 1-hop link between the router and the modem is unlikely to become a bottleneck, e.g., because its bandwidth is larger than the maximum possible bandwidth of the modem. I assume that in typical deployments this condition can be fulfilled, and the hop count limitation provides some safety measures. Yet, the link between the router and modem could possibly run over a tunnel, with unknown performance characteristics (e.g., another wireless backhaul link). It is unclear what a router would indeed learn from the information provided by DLEP in such a case. This scenario is not the target environment for the protocol, but it would make sense to more explicitly spell out that assumption, e.g., in Section 1. 

Other comments:

* Page 9: "If the router and modem support both IPv4 and IPv6, the IPv6 transport MUST be used for the DLEP session." seems inconsistent with page 21: "For routers supporting both IPv4 and IPv6 DLEP operation, it is RECOMMENDED that IPv6 be selected as the transport."

* I am not an IANA expert but at first sight the IANA section does not comprehensively describe the policy for modifying the IANA registries (Section 4 in RFC 5226). Is it "Standards Action"? This in particular matters for the extensions in Section 13.6.

[Ballot comment]
Technical comment:
1) You say
"If a Signal is received with a TTL value that is NOT equal to 255,
  the receiving implementation MUST ignore the Signal."
and
"If a packet in the TCP stream is received with a TTL value other than
  255, the receiving implementation MUST immediately transition to the
  Session Reset state."
However, there is no requiremnet that the initial TTL must be 225. I guess you can just add a sentence to require this from the sender.

2) You say:
"If an unrecognized, or unexpected Signal is received, or a received
  Signal contains unrecognized, invalid, or disallowed duplicate Data
  Items, the receiving implementation MUST ignore the Signal."
Would it make sense to also send an error signal in this case or was this omitted as it could be used as a DoS refelctor? If so, maybe add a sentence.

3) in section 10.5:
"DLEP Heartbeats are not fully established until receipt of the
  Session Initialization Response Message (Section 10.6), and therefore
  implementations MUST use their own timeout and retry heuristics for
  this Message."
I'm not sure if re-trying makes sense given that TCP should deliver the data reliably here. I guess timout to terminate the TCP and a local error log would be more appropriate.

4) section 11.16:
"The Latency value is reported as transmission delay.  The calculation
  of latency is implementation dependent.  For example, the latency may
  be a running average calculated from the internal queuing."
Not sure if this is very useful. I would either recommend to define to report the averange (or max?) latency (where the calculation is still of course implementation specific) or have three different items for min, max, and current average.

Editorial comment:
The 2119 boilerplate has a weird position as part of a subsection. I assume that this is intended to say that the normative text starts here but it could also be interpreted to be just part of the subsection. Also having 'Requirements' (3.1) as subsection of 'Extension' (3) seems to be an error. I would suggest to have the 2119 boilerplate as well as the Requirements section both as own main level sections. And sec 3 and sec 7 are both called 'Extensions'...?


- I didn't see a reply to the tsv-art review by Micheal Scharf. Have those comments be addressed?
Here is his review on -25:
This draft is basically ready for publication, but has nits that should be fixed before publication.

TSV-ART review comments:

* I think the DLEP protocol makes an implicit assumption that the 1-hop link between the router and the modem is unlikely to become a bottleneck, e.g., because its bandwidth is larger than the maximum possible bandwidth of the modem. I assume that in typical deployments this condition can be fulfilled, and the hop count limitation provides some safety measures. Yet, the link between the router and modem could possibly run over a tunnel, with unknown performance characteristics (e.g., another wireless backhaul link). It is unclear what a router would indeed learn from the information provided by DLEP in such a case. This scenario is not the target environment for the protocol, but it would make sense to more explicitly spell out that assumption, e.g., in Section 1. 

Other comments:

* Page 9: "If the router and modem support both IPv4 and IPv6, the IPv6 transport MUST be used for the DLEP session." seems inconsistent with page 21: "For routers supporting both IPv4 and IPv6 DLEP operation, it is RECOMMENDED that IPv6 be selected as the transport."

* I am not an IANA expert but at first sight the IANA section does not comprehensively describe the policy for modifying the IANA registries (Section 4 in RFC 5226). Is it "Standards Action"? This in particular matters for the extensions in Section 13.6.

[Ballot discuss]
* Section 11.7
The MAC address encoding on the wire seems to be wrong. Instead of using 6 bytes for MAC-48 the document seems to using 8 bytes. Similarly for EUI-64 the document seems to be using 12 bytes instead of 8. Please fix this (Also Note that the length values specified under the format of the data item seem to be correct i.e. 6 & 8 - it is the data item format that is wrong)

[Ballot comment]
* Sections 11.2, 11.3, 11.9 and 11.10
The IPv4 and IPv6 addresses do not seem to be aligned on word boundaries. Didn't you face any inefficiencies/difficulties due to this in your implementations (I saw there were four independent ones)?

* Section 11.11.1
Agree with Alia's point that there seems to be a typo in "IPv4 Attached Subnet"

[Ballot comment]
I agree with Alexey's discuss point about the security considerations.

-5.1: Is discovery support optional?
Can you offer any guidance on a reasonable maximum interval for peer discovery signals?

- 5.2: It's probably worth mentioning that the messages from here onward go over the TCP connection established as a result of discovery.
Can you offer any guidance on how long a modem should wait for the Session Initiation Message before abandoning a connection?

-7, paragraph 2: "they will need to
  be standardized either as an update to this document, or as an
  additional stand-alone specification."
I'm not sure what the distinction is between an update vs a stand-alone specification in this context. But in any case, it's unusual to require that a spec update an RFC to exercise  defined extension points.

- 8, first paragraph: "At large scale, implementations SHOULD
  consider employing techniques to prevent flooding its peer with a
  large number of Messages in a short time."

The SHOULD consider is an odd use of a 2119 SHOULD. If the intent is to tell implentors to think about this, then the SHOULD is probably not appropriate. Or does this mean "implementations SHOULD employ techniques" (which would be perfectly reasonable)?

-10.3: This seems to forbid the configuration of non-standard ports. Is that the intent?

- 10.5, 2nd to last paragraph: Can you offer any sort of guidance at all for Session Initiation timeout values?

-11.5: Do heartbeat messages occur in parallel to other active traffic, or only when things are quiet? Or in other words, do messages other than heartbeats reset the heartbeat interval timer?

Can you offer any guidance on reasonable heartbeat interval values, or guidance on how to choose a value? It seems like there could be a lot of heartbeat messages if people choose low values.

-12 Is eavesdropping a concern? Could inserted messages be used to direct user traffic over a compromised link?
What is the reasoning to not at least require implementation of TLS?
Do you imagine situations where it might make sense not to use TLS, other than the mentioned? ("deployments where the DLEP router and modem are the only devices on a physical Layer 2"). Would a "MUST use TLS unless..." construction make sense here?

Editorial Comments:

- General: Neither the abstract or the first few paragraphs of the introduction mention that this draft creates a protocol. That sort of buries the lede. Please consider mentioning that both in the abstract and near the top of section 1.

- 10.5, 2nd to last paragraph: "DLEP Heartbeats are not fully established "

I'm not sure what it means to fully establish heartbeats. Would it be reasonable to say "... not started"?

[Ballot comment]
Thank you for a well-written clear document.  Every time I had a question, I found the answer in the next section.

typo:
  a) bottom of 11.11.1 "  Modems that do not track IPv6 subnets MUST silently ignore IPv4
  Attached Subnet Data Items."  The IPv4 should be IPv6.

[Ballot comment]
Thanks, Alexey for asking the question on validating credentials in your discuss.  It would be good to see more clarity on how that will be done and I see the response stating it is an outstanding problem in Manet - I'd like to know the plan to solve this.

[Ballot discuss]
This is generally a well written document and I enjoyed reading it.

I have a small set of questions which I would like to discuss before recommending approval of this document:

1) In 10.4.  Peer Offer Signal

  A Peer Offer Signal MUST be sent by a DLEP modem in response to a
  properly formatted and addressed Peer Discovery Signal
  (Section 10.3).

  A Peer Offer Signal MUST be encoded within a UDP packet.  The IP
  destination MUST be set to the IP address and port number received in
  the corresponding Peer Discovery Signal.  The source IP address MUST
  be set to the modem's IP address associated with the DLEP interface.
  The source port number MUST be set to the DLEP well-known port
  number.

The port number can be omitted to signal that the well-known port number is to
be used (as per 11.2 and 11.3). It looks like requiring that the source port is always a well-known
port is an error here.

2) In 10.17:

  If metrics are supplied with the Message (e.g., Resources), these
  metrics are MUST be applied to all destinations identified in the
  Message.

Nit: extra "are" before "MUST".

Question: how can multiple destinations be specified?

  Note that this may overwrite metrics provided in a
  previously received Session or Destination Up Messages.

3) 12.  Security Considerations

  At the transport layer, implementations of DLEP SHOULD implement, and
  use, TLS [RFC5246] to protect the TCP session.  Deployments that are
  protected by strong physical security (e.g., deployments where the
  DLEP router and modem are the only devices on a physical Layer 2
  segment) may consider use of DLEP without TLS.  When TLS is in use,
  each peer SHOULD check the validity of credentials presented by the
  other peer during TLS session extablishment.  Refer to [RFC7525] for
  additional details.

How can credentials presented by the other peer can be validated?
RFC 7525 is referencing RFC 6125, which talks about hostname validation,
which is something which might not apply to DLEP deployments?

[Ballot comment]
In Section 6, last para:

  DLEP transactions do not time out and are not cancellable.

What exactly does this mean? Does this mean that a router (or modem) can terminate
a session, then reconnect later on and continue the transaction? Or did you mean
something else?

  An
  implementation can detect if its peer has failed in some way by use
  of the session heartbeat mechanism during the In-Session state, see
  Section 5.3.

In 10.2, 2nd para:

  A DLEP participant receiving any Message apart from Session
  Termination Message (Section 10.9) containing a Status Data Item with
  a status code value with failure mode 'Terminate' MUST immediately
  issue a Session Termination Message containing an identical Status
  Data Item, and then transition to the Session Termination state.

I had to reread this multiple times, but I still want to double check whether I understood
this correctly: are you saying that the Session Termination Message echoes
back the Status Data Item that caused the session to terminate?
If yes, you might want to reword this in order to make this clear. If no, you should
definitely reword this ;-).

10.9.  Session Termination Message

  A Session Termination Message MUST be sent by a DLEP participant when
  the DLEP session needs to be terminated.

This probably means "MUST attempted to be sent", because the TCP connection might
already be dead.

11.  DLEP Data Items

  Following is the list of core Data Items that MUST be recognized by a
  DLEP compliant implementation.  As mentioned before, not all Data
  Items need be used during a session, but an implementation MUST
  correctly process these Data Items when correctly associated with a
  Signal or Message.

Is "skip over or ignore" a valid way to "correctly process"? I think so, but
this might not be obvious from the text as written.

In 11.1:

  Text:  UTF-8 encoded string of UNICODE [RFC3629] characters,
      describing the cause, used for implementation defined purposes.
      Since this field is used for description, implementations SHOULD
      limit characters in this field to printable characters.
      Implementations receiving this Data Item SHOULD check for
      printable characters in the field.

Checking for printable Unicode characters might require keeping an up-to-date
table of which Unicode characters are valid and are printable.
This seems like a rather high bar to implement, I suspect implementations
wouldn't bother. I suggest either deleting the last sentence or downgrading
it to MAY.

11.4.  Peer Type

  Peer Type:  UTF-8 encoded string of UNICODE [RFC3629] characters.
      For example, a satellite modem might set this variable to
      "Satellite terminal".  Since this Data Item is intended to provide
      additional information for display commands, sending
      implementations SHOULD limit the data to printable characters, and
      receiving implementations SHOULD check the data for printable
      characters.

As above.

[Ballot comment]
In 3.1, last para:


  DLEP further requires that security of the implementations (e.g.,
  authentication of stations, encryption of traffic, or both) is dealt
  with by utilizing Layer 2 security techniques.  This reliance on
  Layer 2 mechanisms secures all DLEP Messages - both the UDP discovery
  Signals and the TCP control Messages.

Really?

In Section 6, last para:


  DLEP transactions do not time out and are not cancellable.

What exactly does this mean? Does this mean that a router (or modem) can terminate
a session, then reconnect later on and continue the transaction? Or did you mean
something else?

  An
  implementation can detect if its peer has failed in some way by use
  of the session heartbeat mechanism during the In-Session state, see
  Section 5.3.


In 10.2, 2nd para:

  A DLEP participant receiving any Message apart from Session
  Termination Message (Section 10.9) containing a Status Data Item with
  a status code value with failure mode 'Terminate' MUST immediately
  issue a Session Termination Message containing an identical Status
  Data Item, and then transition to the Session Termination state.

I had to reread this multiple times, but I still want to double check whether I understood
this correctly: are you saying that the Session Termination Message echoes
back the Status Data Item that caused the session to terminate?
If yes, you might want to reword this in order to make this clear. If no, you should
definitely reword this ;-).

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: aretana@cisco.com, manet@ietf.org, bebemaster@gmail.com, draft-ietf-manet-dlep@ietf.org, manet-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Dynamic Link Exchange Protocol (DLEP)) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Dynamic Link Exchange Protocol (DLEP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-11-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  When routing devices rely on modems to effect communications over
  wireless links, they need timely and accurate knowledge of the
  characteristics of the link (speed, state, etc.) in order to make
  routing decisions.  In mobile or other environments where these
  characteristics change frequently, manual configurations or the
  inference of state through routing or transport protocols does not
  allow the router to make the best decisions.  A bidirectional, event-
  driven communication channel between the router and the modem is
  necessary.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ballot/


No IPR declarations have been submitted directly on this I-D.

=== AD Review of draft-ietf-manet-dlep-22 ===

Hi!

I just finished reading this document.  I have (what I think are) significant (mostly) security-related concerns (see details below).  The only "assumption" (which should be reworded as a "requirement") is the existence of L2 security (which has its own vulnerabilities).

I think I understand the intended scenario where DLEP is expected to mainly be used: on a dedicated link (modem/router) in an environment where physical security and L2 security are present.  An example may be a secure vehicle (let's call it "tank"), where in general, if an attacker can place himself on the wire there are bigger problems to deal with.  However,

A. That primary deployment scenario (or any other for that matter) is not described in the document (Figures 1 and 2 don't provide enough context of the location of the router-modem link).  Describing it could ease some concerns at the lack of security.

B. Even if L2 security is present, there are still cases where the system could be compromised.  Again, explaining the primary scenario would help.  But it probably won't stop people from asking "what if that primary scenario is not used?", or even from using DLEP in less secure (physically and from the L2 point of view) deployments.

I'm not suggesting you add authentication or encryption, but that you consider what would be needed if the expected deployment is not implemented.  Besides describing that expected deployment, you might want to add to the Security Considerations a section that says something like: "If the expected deployment is not implemented, then additional security mechanisms should be considered, such as….".

I will wait for the "Major" comments (below) to be addressed before starting the IETF Last Call.

Thanks!

Alvaro.



Major:

M1. Security Considerations related to the one hop requirement/assumption.  Back in version –18 there was a thread in which I participated related to the assumption vs requirement of DLEP working in a one hop environment.  Stan posted a message [1] related to the fact that the one hop deployment is not an assumption, but a requirement — it seemed to me that the WG agreed with that (the Chairs can correct me if I'm wrong).  However, the current version of the document still has language about assumptions (specifically Section 2.1. (Assumptions)).  Please clearly state the requirements: (something along the lines of) "DLEP MUST be implemented on a single L2 domain".  Stan's message also included a short description of why a multi-hop implementation just wouldn't work (because the MAC addresses wouldn't be connected) -- that seems like a good piece of text to include somewhere as well.

M1.1 How is the one-hop connection enforced?  It is obvious that off-segment MAC addresses won't work, but it is not obvious to me how to prevent the connection from being more than directly connected.  A non-directly connected modem (or someone acting as one) may inject information about local MAC Addresses that is simply incorrect.  Was rfc5082 (The Generalized TTL Security Mechanism (GTSM)) considered?

[1] https://mailarchive.ietf.org/arch/msg/manet/-tsnTSwkRXtlY3Ng9Dva12GH808



M2. Use of MAC addresses.  Part of the justification above about the requirement for a one hop deployment is that the MAC addresses of the destination simply won't be connected: "DLEP identifies destinations by using the MAC address for delivering data traffic."  However, DLEP is not a routing protocol, in this context "destination" is defined by this text in Section 2. (Protocol Overview): "The router/modem session provides a carrier for information exchange concerning 'destinations' that are available via the modem device.  Destinations…represent a specific, addressable location that can be reached via the link(s) managed by the modem."  I interpret that text as talking about the next-hop for a routing protocol — and not the end destination.

M2.2 Please clarify the use of "destination".  There are several flavors through the document.  Maybe use something like "local destination" to refer to that one identified by the MAC address.  It should be useful to clarify the terminology somewhere.

M2.3 Without DLEP, on a "normal" ethernet link, the routing protocol will discover its routing neighbors and then the router will ARP (or use the MAC address learned from the Hellos) to eventually encapsulate traffic to the next hop, for destinations beyond.  DLEP seems to want — and maybe even constrain routing protocol neighbor discovery to just what DLEP communicates.

M2.3.1 Is that the intent?  If so, then please be explicit about it.  I can see the advantages in not blindly trying to discover who is out there…

M2.3.2 Are there any deployment scenarios where an interface would be shared between DLEP participants and non-DLEP participants (other local routers, for example)?  I'm assuming that maybe two routers sharing the same modem might be ok (is it?) -- in that case the routers might want to talk to each other.



M3. Preconfigured TCP parameters on the router.  Let's see if I understand the Peer Discovery (4.1) and Session Initialization (4.2) correctly…  During Peer Discovery the modem may offer (using a Peer Offer Signal) a series of address/port pairs for the router to initialize a session to…if nothing is offered, then the router "MUST use the source address of the UDP packet containing the Signal as the IP address, and the DLEP well-known port number".  But the router may not use Peer Discovery at all and just be preconfigured with an IP/port pair.  Is my understanding correct?

M3.1 The "packet containing the Signal" is the one containing the Peer Offer Signal, right?  Please don't let the reader guess.

M.3.2 How does the modem verify that the preconfigured router is really one that should be establishing a DLEP connection?  It seems like the preconfigured option puts the modem in a promiscuous mode where it has to listen for a TCP connection (and eventually a segment containing a Session Initialization Message) on any port, and any of its configured IP addresses.  This mode seems to open a door for anyone (on the local L2, even post 802.1x authentication) to send random packets to the modem, which won't know if the session is valid until after establishment. 

M3.2 (Following one of the points above…)  Note that without being able to enforce the one-hop connection (using rfc5082, for example), then these packets could come from anywhere (IOW, I don't even have to break into the "tank"!!).



Minor: 

p1. It would be very nice/useful to include a reference to the appendixes somewhere in the text.


Nits:

n1. "Addressing the challenges listed above, the co-authors have developed the Dynamic Link Exchange Protocol, or DLEP."  s/the co-authors/the WG or just leave it generic: "To address…DLEP has been developed."

n2. "SCTP port allocation is not required."  Seems unnecessary.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard is appropriate.  There are many years of experience with similar technologies within industry.  Much of the experience comes in the form of similar but non-standard stand-alone implementations (wi-fi drivers and radio waveforms drivers) but the IETF does have experience with similar drafts pppoe and LMP.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions.  In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions.  A bidirectional, event-driven communication channel between the router and the modem is necessary. The DLEP protocol provides this channel by defining signals to be passed between a router and its attached modem devices, allowing the modem to communicate link characteristics as they change, and convergence events (acquisition and loss of potential routing destinations). The signals are used to communicate events that occur on the physical link(s) managed by the modem to the attached routers.

Working Group Summary:

Development of the DLEP document has taken quite some time with a few major revisions along the way.  DLEP has previously passed WGLC but was then sent back to the WG after an extensive RtgDir review.  As a result the document was split into two documents the base specification (this document) and one for a credit windowing extension.  There were also some minor technical changes were made, some major editorial changes were done.

Previous changes of note: the change between UDP based messaging format into a TCP based messaging paradigm, a change of messaging format from RFC5444 (MANET packet building block) to a newly developed DLEP specific packet format, and the change from stateless communication to state-full communication session. 

There is support within the working group on moving this document forward.  Previous areas of contention within DLEP were worked out within the working group with no serious objections regarding the final compromise decisions.

Document Quality:

There are multiple existing implementations of the protocol, the Shepherd knows of at least 4 independant ones.  There is broad support within industry and the Shepard fully expects many more implementations once standardized and well as demand on the customer side.  The document quality was addressed extensively in the RtgDir review and subsequent WG discussions.

Personnel:

Document Shepherd is Justin Dean
Area Director Alvaro Retana
Directorate Reviewer: Lou Burger

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The Shepherd has read the draft document (and multiple previous versions).  Recent updates (after document was sent back to the WG) resolves the shepherds previous concerns about outstanding issues raised in the RgtDir review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

A security review would be appropriate.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The Shepherd has apprehension about the current security approach but does not have expertise in the area. Regardless the documented security approach has been discussed in depth within the WG.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) 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?

The WG as a whole understands and agrees with it moving forward. There is bimodal support:  Some strongly support moving it forward and others support moving it forward with various small issues (which have been discussed, addressed, and compromised on by the WG)

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits was run and there was one formatting error and 4 warnings which can be fixed in the next version.  The error provided was.

** There are 44 instances of too long lines in the document, the longest
    one being 3 characters in excess of 72.
   

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

A RtrDir review has been preformed.  A security review would be appropriate.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document defines 5 new registry spaces and requests a well known port/multicast address.  These registries are clearly identified.  Reasonable names are provided for the new registries.  The newly created registries have a detailed list of initial valid entries. 

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

DLEP Signal Type Values
DLEP Message Type Values
DLEP Data Item Values
DLEP Status Code Values
DLEP Extension Type Values

Of the author team S. Ratliff and R. Taylor are most active and knowledgable regarding IETF procedures and would be good expert picks.  All members listed as part of the design team would be appropriate experts.  Lou Berger would also be an appropriate choice.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

None.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard is appropriate.  There are many years of experience with similar technologies within industry.  Much of the experience comes in the form of similar but non-standard stand-alone implementations (wi-fi drivers and radio waveforms drivers) but the IETF does have experience with similar drafts pppoe and LMP.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions.  In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions.  A bidirectional, event-driven communication channel between the router and the modem is necessary. The DLEP protocol provides this channel by defining signals to be passed between a router and its attached modem devices, allowing the modem to communicate link characteristics as they change, and convergence events (acquisition and loss of potential routing destinations). The signals are used to communicate events that occur on the physical link(s) managed by the modem to the attached routers.

Working Group Summary:

Development of the DLEP document has taken quite some time with a few major revisions along the way.  DLEP has previously passed WGLC but was then sent back to the WG after an extensive RtgDir review.  As a result the document was split into two documents the base specification (this document) and one for a credit windowing extension.  There were also some minor technical changes were made, some major editorial changes were done.

Previous changes of note: the change between UDP based messaging format into a TCP based messaging paradigm, a change of messaging format from RFC5444 (MANET packet building block) to a newly developed DLEP specific packet format, and the change from stateless communication to state-full communication session. 

There is support within the working group on moving this document forward.  Previous areas of contention within DLEP were worked out within the working group with no serious objections regarding the final compromise decisions.

Document Quality:

There are multiple existing implementations of the protocol, the Shepherd knows of at least 4 independant ones.  There is broad support within industry and the Shepard fully expects many more implementations once standardized and well as demand on the customer side.  The document quality was addressed extensively in the RtgDir review and subsequent WG discussions.

Personnel:

Document Shepherd is Justin Dean
Area Director Alvaro Retana
Directorate Reviewer: Lou Burger

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The Shepherd has read the draft document (and multiple previous versions).  Recent updates (after document was sent back to the WG) resolves the shepherds previous concerns about outstanding issues raised in the RgtDir review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

A security review would be appropriate.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The Shepherd has apprehension about the current security approach but does not have expertise in the area. Regardless the documented security approach has been discussed in depth within the WG.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) 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?

The WG as a whole understands and agrees with it moving forward. There is bimodal support:  Some strongly support moving it forward and others support moving it forward with various small issues (which have been discussed, addressed, and compromised on by the WG)

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

ID nits was run and there was one formatting error and 4 warnings which can be fixed in the next version.  The error provided was.

** There are 44 instances of too long lines in the document, the longest
    one being 3 characters in excess of 72.
   

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

A RtrDir review has been preformed.  A security review would be appropriate.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document defines 5 new registry spaces and requests a well known port/multicast address.  These registries are clearly identified.  Reasonable names are provided for the new registries.  The newly created registries have a detailed list of initial valid entries. 

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

DLEP Signal Type Values
DLEP Message Type Values
DLEP Data Item Values
DLEP Status Code Values
DLEP Extension Type Values

Of the author team S. Ratliff and R. Taylor are most active and knowledgable regarding IETF procedures and would be good expert picks.  All members listed as part of the design team would be appropriate experts.  Lou Berger would also be an appropriate choice.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

None.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard is appropriate.  There are many years of experience with similar technologies within industry.  Much of the experience comes in the form of similar but non-standard stand-alone implementations (wi-fi drivers and radio waveforms drivers) but the IETF does have experience with similar drafts pppoe and LMP.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions.  In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions.  A bidirectional, event-driven communication channel between the router and the modem is necessary. The DLEP protocol provides this channel by defining signals to be passed between a router and its attached modem devices, allowing the modem to communicate link characteristics as they change, and convergence events (acquisition and loss of potential routing destinations). The signals are used to communicate events that occur on the physical link(s) managed by the modem to the attached routers.

Working Group Summary:

Development of the DLEP document has taken quite some time with a few major revisions along the way.  Of note: the change between UDP based messaging format into a TCP based messaging paradigm, a change of messaging format from RFC5444 (MANET packet building block) to a newly developed DLEP specific packet format, and the change from stateless communication to state-full communication session. 

There is broad support within the working group on moving this document forward.  Previous areas of contention within DLEP were worked out within the working group with no serious objections regarding the final decisions.  Of note: experimental extensions definitions and credit windowing metric as a default or extended feature.

Document Quality:

There are multiple existing implementations of the protocol, the Shepherd knows of at least 4 independant ones.  There is broad support within industry and the Shepard fully expects many more implementations once standardized and well as demand on the customer side.  Two specific reviews were quite extensive and relevant to the 13 draft version.  Lou Berger who was assigned to do the RtgDir review and Ronald in'tVelt (an implementer) who's review was posted just after wg last call had ended.

Personnel:

Document Shepherd is Justin Dean
Area Director Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The Shepherd has read the draft document (and multiple previous versions).  The shepherd believes that a further revision is required for publication to address issues raised in reviews after WG last call.  The issues raised are not substantive enough to hold the document up within the working group as they do not affect any consensus within the working group.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

A security review would be appropriate.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The Shepherd has one area of hesitation due to the transmission from a stateless to a state-full communication model as well, as the move from UDP to TCP based communication as the document evolved.  Conflicts regarding protocol state due to this evolution is a concern due to possible conflicting bits of text, having reviewed previous documents the shepherd isn't well positioned to see these possible conflicts. Protocol state was discussed within the WG and there is consensus to move the document forward.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) 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?

The WG as a whole understands and agrees with it moving forward. Strongly.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

== Line 275 has weird spacing: '... Shared  o  ...'

  == Line 276 has weird spacing: '... Medium  o...'

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

A RtrDir review has been preformed.  A security review would be appropriate.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document defines 4 new registry spaces and requests a well known port/multicast address.  These registries are clearly identified although initial values are not supplied but are currently listed in tables as TBD.  Reasonable names are provided for the new registries.  The newly created registries have a detailed list of initial valid entries are (albit without numbers assigned) but the document doesn't provide guidance for future assignments although expert review is implied it should be made explicit.  Experimental space reservations are requested within two of the registries but the size of the reserveration request is not presented. 

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

DLEP signals
DLEP data
DLEP status codes
DLEP extensions

Of the author team S. Ratliff and R. Taylor are most active and knowledgable regarding IETF procedures and would be good expert picks.  All members listed as part of the design team would be appropriate experts.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

None.