Subject: [manet] Stephen Farrell's No Objection on draft-ietf-manet-dlep-26: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 15 Dec 2016 06:39:38 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-manet-dlep-26: No Objection

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/

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

---

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

Hi Stephen,

Thanks for the comments, some answers inline...

> signals from routers with which the modem does not have a

Peer Discovery is a UDP-based mechanism that is designed to run before
a TCP-based session is established, much like UPnP or mDNS.

> change the security model.

DLEP only defines the conversation between a local router/modem pair.
 How or what a modem sends over the air to another modem is
intentionally out of scope.

> (and TLS, which seems to not be some people's favourite;-)

To be frank - we never considered a cookie as a security mechanism.
 Personally I considered an attacker capable of successfully injecting
octets into an existing TCP stream would probably be able to hijack a
cookie mechanism.

However, I am not a security expert, and if this is a viable
alternative to TLS (which is unpopular with implementers, and has open
questions over certification) then it is definitely something that
should be considered.

> IANA allocates for you from 13.14/15?

From a DLEP perspective, no destination address or subnet is
prohibitted.  Obviously a user can configure their network stupidly and
then it wont work, but from a functional perspective, DLEP doesn't
care.  And it doesn't add any further restriction on addresses beyond
the regular IPv4/6 rules.

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

Prefix 0 was left in to allow announcement of a default route.

> more work to be usable. Maybe recommend PSK?

None of the authors are self-confessed security experts, and we do need
advice here.

Thanks,

Rick

---

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

Hiya,

> a TCP-based session is established, much like UPnP or mDNS.

Sure, but my question stands doesn't it? As written
a modem could decide to drop the current connection
or ignore the signal. Don't you need to say?

> intentionally out of scope.

That's why I don't get why the text sorta muddies the
waters with the above quoted text.

> questions over certification) then it is definitely something that

I'd need to think about the combination of 1-hop and offpath
but there may be cases where it's useful e.g. to stop someone
else on the same LAN from hijacking an existing session.

Cookie mechanisms are not really an alternative to TLS though,
more a useful thing if one doesn't have TLS, if you see the
difference I mean.

Cheers,
S.

---

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

> or ignore the signal. Don't you need to say?

Sorry Stephen, I misunderstood your question.

If the modem supports multiple simultaneous DLEP sessions with
different routers, then it may start another parallel DLEP session.  If
it doesn't then it probably shouldn't terminate any existing session,
but that's an implementation decision.

The bottom line is that we purposefully haven't addressed the multiple
simultaneous sessions per DLEP peer issue in this draft, as it isn't
clear to the WG how exactly it would work in a sensible way.  However,
text such as the paragraph above could be added to Section 5.1 if you
think it aids clarity?

> waters with the above quoted text.

The purpose of that text was to explain to an implementer what was
required by DLEP to make the whole address thing work, without telling
the implementer how they had to do it (or secure it).

> more a useful thing if one doesn't have TLS, if you see the

I think cookies should be discussed, given that they haven't been yet.

I think some of this is being discussed in the other thread in this
list covering Alexey's discuss, so I will leave this alone.

Cheers,

Rick