Subject: [manet] Alexey Melnikov's Discuss on draft-ietf-manet-dlep-26: (with DISCUSS and COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 12 Dec 2016 09:22:29 -0800

Alexey Melnikov has entered the following ballot position for
draft-ietf-manet-dlep-26: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/

----------------------------------------------------------------------
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?

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

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 12 Dec 2016 21:24:16 -0500

Alexey,

Responses inline.

> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/

Yes, that is an error. We will correct that.

> Question: how can multiple destinations be specified?

The sentence "If metrics are supplied with the Message (e.g.,
Resources)..." should be deleted from the text. There is no way to specify
multiple destinations with the 'Destination Update' message - that text
would apply to the 'Peer Update' message, where (for example) a modem is
updating a metric on what the document calls a "modem-wide" basis.

> which is something which might not apply to DLEP deployments?

In terms of exactly how an implementation would validate credentials, we
have no guidance. You correctly note that techniques like hostname
validation might not apply to mobile ad-hoc (DLEP) deployments. Indeed, the
whole issue of credentials, and how to process them, is an interesting
challenge in MANET environments.

No, our intent was to say that a transaction cannot timeout within the
context of a TCP session. If the session is terminated, then the DLEP state
machine should be reset (which includes knowledge of transactions
in-flight).

> definitely reword this ;-).

Fair point. You understood correctly - the intent is for the Session
Termination Message to echo the Status Item that causes the session to
terminate. We will re-word.

> This probably means "MUST attempted to be sent", because the TCP

Yes. We will re-word this.

> this might not be obvious from the text as written.

Yes, "silently ignoring" a data item would be, potentially, a way to
"correctly process". DLEP specifies a list of Data Items that can be passed
between a modem and a router. However, we purposefully don't specify
exactly how each of those Data Items would (or should, or even could) be
used - the WG consensus was that level of specification would amount to
"boiling the ocean". For example, if a modem sends a "Latency" data item to
a router, and the receiving router doesn't understand (or need, or even
care) about Latency, then the router shouldn't see that as an error.

> wouldn't bother. I suggest either deleting the last sentence or

Again, a fair point. We will re-word.

Regards,
Stan

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 13 Dec 2016 10:11:45 +0000

Hi Stan,

All your answers look good to me. But I think credential validation might need a bit more thought/discussion in the WG. Maybe you can specify how preconfigured IP or MAC addresses can be checked in X.509 certificates? (Just an idea, not necessarily saying that it is the right or the only way of doing this)

Best Regards,
Alexey

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Dec 2016 09:59:13 +0100

> All your answers look good to me. But I think credential validation might need a bit more thought/discussion in the WG. Maybe you can specify how preconfigured IP or MAC addresses can be checked in…

I raised the point of the certificate problem ages ago as an argument
to DROP TLS from DLEP completely.

Henning Rogge

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 15 Dec 2016 09:23:36 +0000

Hi,

> On 15 Dec 2016, at 08:59, Henning Rogge <[email-masked]> wrote:
> 

Even unauthenticated TLS is better than no TLS, so I would rather the document continues to recommend it.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Dec 2016 10:21:40 +0100

> Even unauthenticated TLS is better than no TLS, so I would rather the document continues to recommend it.

What kind of security does unauthenticated TLS provide against an
attacker that sits on your local LAN segment? Its not that DLEP carry
any "secret" data...

I have spoken with a few radio vendors and from what I got none of
them considers to implement TLS. Nobody sees any advantage of it, but
everyone sees a huge cost. Cost in terms of performance (Flow control
is delay dependent), cost in terms of complexity, costs in terms of
interoperability.

Henning Rogge

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 15 Dec 2016 14:58:37 +0000

On Thu, Dec 15, 2016, at 09:21 AM, Henning Rogge wrote:
> attacker that sits on your local LAN segment?

I am not really concerned about that, but I am concerned about VPN or
virtualized environment where router is across the globe from the modem.

> Its not that DLEP carry

That is the question really. If the date is exposed outside of LAN, does
it contain no sensitive information?

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Dec 2016 15:02:49 +0000

> it contain no sensitive information?

If someone can tell a router that AA.BB/16 is connected "here"
then that'd I guess cause the router to send packets to that
interface that'd otherwise go out the default. Seems like that
could be the basis for some attacks, wouldn't it?

S.

---

From: Rick Taylor <[email-masked]>
Date: Thu, 15 Dec 2016 15:15:27 +0000

On Thu, 2016-12-15 at 14:58 +0000, Alexey Melnikov wrote:
> > > > > All your answers look good to me. But I think credential
> > > > > validation might need a bit more thought/discussion in the
> > > > > WG. Maybe you can specify how preconfigured IP or MAC
> > > > > addresses can be checked in X.509 certificates? (Just an
> > > > > idea, not necessarily saying that it is the right or the only
> > > > > way of doing this)

This was why we put in the text in the security considerations stating
that those environments need all security provided by whatever Layer-2
tunnelling protocols are used.  However, we had several discuss's
suggesting that this wasn't enough...

---

From: Rick Taylor <[email-masked]>
Date: Thu, 15 Dec 2016 15:16:09 +0000

> could be the basis for some attacks, wouldn't it?

Agreed, network topology information is sensitive enough to warrant
some kind of protection.

Rick

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Dec 2016 19:01:33 +0100

> could be the basis for some attacks, wouldn't it?

Which would be totally fine (security wise) by dedicated cable of
802.1x/801.1ae, right?

Henning