Subject: Re: [manet] DLEP-15: Security Considerations

From: RJ Atkinson <[email-masked]>
Date: Mon, 13 Jul 2015 13:06:24 -0400

On Monday 13 July 2015 at 16:45:32 +0000, Rick Taylor wrote,
in part:

> The main reason we have not looked hard at the security aspects of DLEP 
> is that although it uses multi-hop layer-3 protocols (UDP/TCP) DLEP 
> itself is distinctly link-local and most frequently routers and modems 
> will be physically adjacent.
> 
> However, you are right to point out that this is an assumption on our 
> part, and passing IESG review is critical, hence TLS RECOMMENDED seems 
> reasonable.

Rick,

I am not sure what you mean by the last sentence just above.

The candidate text about TLS said (summarizing greatly) that:
  1) All DLEP Implementations MUST implement full TLS support,
     including a mandatory-to-implement cipher-suite.
  2) The IETF RECOMMENDS that DLEP deployments actually use TLS.

The IETF usually makes security mechanisms mandatory-to-implement,
for the practical reason that one can’t have interoperable
implementations without requiring it of implementations.

However, the IETF normally does not levy absolute requirements
to USE security within any particular operational deployment.

The candidate text tried to follow both of those practices,
and specified a readily-available-in-open-source cipher-suite.

> I don't agree that DTLS for UDP should be 'RECOMMENDED', I prefer 'MAY 
> use'.  The reason being that UDP is used for multicast discovery (and 
> I'm not sure how effective DTLS is for multicast without pre-placed 
> keys).  The discovery packets leak no private information and simply 
> point to a TCP endpoint that can be sufficiently secured.

If the authors want to omit DTLS as mandatory-to-implement,
then the authors ought to have explicit text (possibly derived
from the text above) in the Security Considerations explaining 
why they believe DTLS is not helpful, applicable, or whatever.

Doing that will at least show the (future) IETF Security Area 
Reviewer that (a) the issue was considered and also
(b) the reason(s) that DTLS was omitted from the DLEP specification.

Yours,

Ran

---

From: Rick Taylor <[email-masked]>
Date: Mon, 13 Jul 2015 19:44:03 +0000

Collapsing two sets of comments into one.  Sorry for the top-post but my Outlook hates inline comments.

I am currently in favour of TLS, summarized as:

1) TLS RECOMMENDED to implement.
2) TLS OPTIONAL to use, but RECOMMENDED on routable subnets.

With suitable text concerning link-local subnets etc, as mentioned by others.

I don't see the need for DTLS on UDP, but agree that some explicit text needs to be included explaining why (see my previous email).

But that raises a question: how does an implementation that has discovered a DLEP peer know whether to use TLS or not?  Potential solutions are:

1) 2 ports, just like HTTP/HTTPS?
2) Extension Id - "I am willing to do TLS"?
3) Attempt TLS then fall back to not TLS?
4) New Data Item for discovery: 'TLS_Cipher_Suite'?

Opinions please? ( I favour option 4 )

Rick

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of RJ Atkinson
Sent: 13 July 2015 18:06
To: [email-masked]
Subject: Re: [manet] DLEP-15: Security Considerations

On Monday 13 July 2015 at 16:45:32 +0000, Rick Taylor wrote, in part:

> The main reason we have not looked hard at the security aspects of 
> DLEP is that although it uses multi-hop layer-3 protocols (UDP/TCP) 
> DLEP itself is distinctly link-local and most frequently routers and 
> modems will be physically adjacent.
> 

Rick,

The IETF usually makes security mechanisms mandatory-to-implement, for the practical reason that one can’t have interoperable implementations without requiring it of implementations.

However, the IETF normally does not levy absolute requirements to USE security within any particular operational deployment.

The candidate text tried to follow both of those practices, and specified a readily-available-in-open-source cipher-suite.

> point to a TCP endpoint that can be sufficiently secured.

If the authors want to omit DTLS as mandatory-to-implement, then the authors ought to have explicit text (possibly derived from the text above) in the Security Considerations explaining why they believe DTLS is not helpful, applicable, or whatever.

Doing that will at least show the (future) IETF Security Area Reviewer that (a) the issue was considered and also
(b) the reason(s) that DTLS was omitted from the DLEP specification.

Yours,

Ran

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

---

From: Henning Rogge <[email-masked]>
Date: Mon, 13 Jul 2015 21:53:47 +0200

> I don't see the need for DTLS on UDP, but agree that some explicit text needs to be included explaining why (see my previous email).

Would faking a Peer Offer be a problem?

> Opinions please? ( I favour option 4 )

1) would work, but I think IANA might be unhappy with us.
2) doesn't work, because we only learn about the other extensions
after the TCP session is active.
3) sounds like a "fuzzing attack" against non-TLS DLEP implementations
because they will get the (D)TLS data.
4) without DTLS it would be trivial to do a downgrade attack by
removing the cipher suite TLV.

Henning

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 13 Jul 2015 15:58:34 -0400

> On 13  Jul 2015, at 15:44 , Rick Taylor <[email-masked]> wrote:
> 

ASIDE: 
  - Do you believe that DLEP/TCP/IP should work across routable subnets ?

> With suitable text concerning link-local subnets etc, as mentioned by others.

From my own perspective, this “suitable text” would need to have
many “MUST ONLY” and “MUST NOT” items to force that constraint,
as outlined previously.

> I don't see the need for DTLS on UDP, but agree that some explicit text
> needs to be included explaining why (see my previous email).
> 

I don’t think (4) will work with (D)TLS.  (D)TLS includes
TLS version negotiation, TLS cipher-suite agreement, endpoint
authentication, and TLS session key generation all within 
the existing (D)TLS protocol specifications.

About (1), I think that the use of 2 ports for 1 service is
disliked at present, partly due to complexity and partly because
it burns more transport-layer port numbers.  One of the WG Chairs 
or a document author might want to ask for the current recommended 
IETF practice in this area.

My guess is that the current recommended approach might be
to reuse the "STARTTLS” technique specified for use with
IMAP4, POP3, SMTP, XMPP, LDAP, and NNTP.  I’m not certain. 

Anyway, there is a reasonable Wikipedia page on this approach:

	"https://en.wikipedia.org/wiki/STARTTLS”

The “STARTTLS” approach would imply adding new text to DLEP-15++, 
probably at least in Section 1.1 and also in Section 5.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 13 Jul 2015 16:03:06 -0400

> On 13  Jul 2015, at 15:53 , Henning Rogge <[email-masked]> wrote:
> 

Potentially.  

At a bare minimum, it would be a potential denial-of-service attack 
that would consume (possibly scarce) resources on the victim.  It
is worth documenting easily-executed DoS attacks — especially if
one also can document a mitigation that implementers should use.

Yours,

Ran

---

From: Rick Taylor <[email-masked]>
Date: Tue, 14 Jul 2015 09:00:43 +0000

> one also can document a mitigation that implementers should use.

I can see the need for some text in the security section stating that a 
modem receiving multiple repeated Peer_Discovery signals should probably 
limit the amount of listening sockets it creates and perhaps blacklist 
the source of the signals if a valid connection is not used, but adding 
DTLS to the mix doesn't seem to add anything to me.

Rick

---

From: Henning Rogge <[email-masked]>
Date: Tue, 14 Jul 2015 11:28:39 +0200

> DTLS to the mix doesn't seem to add anything to me.

I think (for the radio side) it is even easier.

You get the Peer_Discovery multicast from the router... you answer
with a Peer_Offer UDP... and then forget about the whole thing.

When you get an incoming TCP connection for the server port on the
radio the radio starts building up a session, based on the
Peer_Initialization content.

No need to build up a session when you get the Peer_Discovery.

The router does also only need to allocate resources for a session
when it opens the TCP connection to the radios server port. No session
necessary when sending out Peer_Discovery.

The only danger with (routed/non-linklocal) Peer_Offers I see is that
you might be able to trick the router to open its DLEP session to a
different TCP socket... which might be a way to start a
man-in-the-middle attack.

Henning Rogge

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 14 Jul 2015 09:02:40 -0400

> On 14  Jul 2015, at 05:28 , Henning Rogge <[email-masked]> wrote:
> 

All of the above is good implementation advice that probably ought 
to be copied both (a) into the specific DLEP-15++ subsections on 
       (i) receiving Peer_Discovery via UDP multicast, 
      (ii) receiving Peer_Offer via UDP, 
   & (iii) how the DLEP TCP session is created and initialised,
AND also (b) into the “Security Considerations” section.

> man-in-the-middle attack.

Yes.

It seems to me that this discussion has (inadvertently, perhaps)
raised the question of whether the WG-as-a-whole would like to
constrain DLEP implementations to only use non-routable link-local
IP address types.  I’ll go start a thread on that question in a
moment.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 14 Jul 2015 09:49:27 -0400

> On 14  Jul 2015, at 09:05 , MATTY, Steven <[email-masked]> wrote:
> 
> FWIW, I'm not in favour of mandating TLS or another security layer either.

I understand the sentence above.

> Our environment may quite possibly preclude any such 3rd party
> software from being present and would be a deal-breaker.  

I do not understand the sentence above, because TLS is not 
“3rd party software” any more than one’s operating system 
already might be.

There are many implementations of TLS, so one need not
use OpenSSL.  OpenSSL was mentioned purely here only because 
some implementers here are limiting themselves to open-source.

Virtually all networking equipment suppliers ship a TLS
implementation already integrated with the OS — as do 
virtually all operating system suppliers (specifically 
including multiple high-assurance OSs) — and this has been 
true for at least 15 years.  

An example of a high-assurance (IEC 61508, SIL 3; ISO/IEC
15408 EAL4+) operating system that includes TLS support
is QNX.  Other examples also exist.  I understand that Airbus
might have high-assurance requirements in some of its
applications, but TLS is readily available inside existing
high-assurance OSs.

(NB: In many cases, the TLS implementation is called “SSL” 
in the supplied documentation.  Legacy SSL, such as SSL 3.0,
is known to be insecure.  The IETF standards-track name for
the “fixed” versions of SSL is TLS, hence my use of TLS in
these discussions.)

> RECOMMENDING a link-local address for peer discovery
> and sessions suits me just fine

I am not quite sure what that sentence means...

If we merely “RECOMMEND” link-local, then the IETF Security
Area will correctly point out that use of global routable
IP addressing is legal, and almost certainly will require
that some mandatory-to-implement security mechanism 
(e.g. TLS) be specified so that implementations have a
decent chance of interoperating securely.

On the other hand, if we “REQUIRE” link-local AND PROHIBIT
routable IP addressing, then the IETF Security Area likely
will be OK with omitting a mandatory-to-implement security
mechanism.

> (IPv4 link-local address allocation headaches notwithstanding) :-)

One needs IANA to allocate an IPv4 multicast address anyway,
so the question in my mind is more about IPv4 unicast link-local.

> However, I do appreciate that those in IESG have to think
> about the bigger picture, and not just isolated, closed MANETs…

The IETF repeatedly has been burned by expecting something to be
used locally only (either single site or link-local), omitting
adequate security, and then having to come back and patch some
protocol to include security after a remote attack has appeared.

> Yes, this is a good example of why link-local should be encouraged
> (if not a stronger word)

That gets to my question:
	Would you be OK with "MUST use only link-local addressing”
        and “MUST NOT use routable addressing” ??

Thanks,

Ran

---

From: "MATTY, Steven" <[email-masked]>
Date: Tue, 14 Jul 2015 14:45:02 +0000

>Sent: Tuesday, July 14, 2015 2:49 PM
>To: MANET IETF

Apologies. I was inferring using OpenSSL [or another 3rd Party open-source
TLS implementation] on our current platform, within our *current* OS.
My bad, as indeed there are plenty of other TLS implementations out there.
But you're quite right - the fact we are limited to 3rd party TLS solutions shouldn't
affect the WG's review of DLEP w.r.t. security.

>so the question in my mind is more about IPv4 unicast link-local.

Yes, sorry (again), the IPv4 unicast link-local address was what I was getting at.

>        and “MUST NOT use routable addressing” ??

On the face of it, yes, but I'll also answer that in the other thread once I've thought about
it some more :-)

Regards

Steve

---

From: "MATTY, Steven" <[email-masked]>
Date: Tue, 14 Jul 2015 13:05:39 +0000

>From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
>Sent: Tuesday, July 14, 2015 10:29 AM
>To: Rick Taylor
>Cc: MANET IETF; RJ Atkinson

Yep, +1 to this. The modem just sends a UDP in response to Peer_Discovery
but there is only 1 listening socket at any one time.

FWIW, I'm not in favour of mandating TLS or another security layer either.
Our environment may quite possibly preclude any such 3rd party software
from being present and would be a deal-breaker.  RECOMMENDING a link-local address
for peer discovery and sessions suits me just fine (IPv4 link-local address allocation
headaches notwithstanding) :-)

However, I do appreciate that those in IESG have to think about the bigger picture, and not just
isolated, closed MANETs...

>man-in-the-middle attack.

Yes, this is a good example of why link-local should be encouraged (if not a stronger word)

Regards

Steve

---

From: John Dowdell <[email-masked]>
Date: Wed, 15 Jul 2015 12:10:14 +0100

On 14/07/15 15:45, MATTY, Steven wrote:
>>> On 14  Jul 2015, at 09:05 , MATTY, Steven <[email-masked]>
>>>
So the problem here is that there is (in typical manet land) no way to 
check the validity or revocation status of the certificates because 
there is no path to a central certificate server. This means you have to 
rely on some pre-loaded trust. There is also the problem of what to do 
when the trust expires; radios might be delivered and in-service for 
some years, and now the certificates need to be refreshed every so 
often, an additional scheduled maintenance task with associated vendor 
support activity that costs money to do.

I'm not convinced the threat is there to warrant the expense this is 
going to incur.

John

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 15 Jul 2015 09:09:36 -0400

> On 15  Jul 2015, at 07:10 , John Dowdell <[email-masked]> wrote:
>> But you're quite right - the fact we are limited to 3rd party TLS solutions shouldn’t affect the WG's review of DLEP w.r.t. security.
> 
> So the problem here is that there is (in typical manet land) no way 
> to check the validity or revocation status of the certificates 
> because there is no path to a central certificate server.  This means 
> you have to rely on some pre-loaded trust. There is also the problem 
> of what to do when the trust expires; radios might be delivered and 
> in-service for some years, and now the certificates need to be refreshed 
> every so often, an additional scheduled maintenance task with associated 
> vendor support activity that costs money to do.

John,

Within the constraints that you specify (e.g. inside an L3 MANET,
other aspects of a particular deployment), I agree there are 
non-zero operational costs to deploying TLS.  This is exactly why 
the IETF normally does NOT mandate deployment/use, but instead
normally only mandates implementation of an interoperable security 
mechanism (i.e. so users that choose to deploy/use security will 
have broad interoperability).

That noted, at least one radio I am aware of handles the MANET
aspects at Layer-2, which reduces the operational complexity 
that you outline above.  Further, I know of both deployments 
with L2 MANET and also deployments of L3 MANET where the EXISTING 
operational practice already refreshes the cryptographic configuration 
elements (e.g. TLS-suitable PKIX/X.509v3 certificates) at regular 
intervals.

Last, while one common deployment of DLEP will be in the context
of a MANET, another pretty common deployment of DLEP is likely
to be with relatively fixed topologies (e.g. NOT MANET) using
VSAT terminals attached to buildings.  So the MANET-specific 
issues affect one common use case, but not all common use cases.

Further, a well-designed implementation will permit the device
administrator to provision their own certificates and TLS
configuration parameters - not requiring “vendor support activity”.
The network firewall at my house permits me to do this, for example.
Further, the network firewall at my house does NOT require me
to turn it off or to reboot it just because I have updated the
configured certificates inside it.  

This kind of usability detail is usually a “quality of implementation” 
item beyond the scope of IETF specifications.  We could, however, 
suggest that implementations support authorized device administrator
(re)configuration of certificates and other security parameters 
without requiring vendor maintenance or operational down-time.

> I'm not convinced the threat is there to warrant the expense 
> this is going to incur.

Even if implementation of security mechanisms for DLEP inside 
a DLEP-compliant radio/router is mandated, the user/operator
will have a choice of whether to enable/use/deploy the 
security mechanism — or not enable/use/deploy the mechanism,
based on local policy and local perception of their threat
environment.

So I think I grok your concern, but I also end up with a different
conclusion than yours.  :-)

Yours,

Ran

---

From: Henning Rogge <[email-masked]>
Date: Thu, 16 Jul 2015 21:02:01 +0200

> have broad interoperability).

I still have yet to see a good use-case for a DLEP radio two IP hops
away from the DLEP router.

> issues affect one common use case, but not all common use cases.

and how do these detachment get the traffic when they are multiple IP hops away?

> configured certificates inside it.

It also changes DLEP from a "auto-discovery/zero-conf" protocol to
something much more complicated.

I have yet to see how to use DTLS for the multicast discovery packets.

I am also not convinced we have anyone with experience how adding
(D)TLS to DLEP changes the protocol. Its definitely not a "just use it
and everything is fine".

Henning Rogge

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 17 Jul 2015 15:49:01 -0400

> On 16  Jul 2015, at 15:02 , Henning Rogge <[email-masked]> wrote:
> 

I think the conversation is looping.  That sentence above is
about the data path and packet forwarding.  However, the
security discussion is focused on the DLEP control path.

> I have yet to see how to use DTLS for the multicast discovery packets.

The paragraph that you quoted from me above says TLS, referring
to DLEP unicast.  It does not say (D)TLS or DTLS.

> and everything is fine”.

For the unicast DLEP, it should be “just use it and everything is fine”.

However, please recall that I have posed the question of whether
the WG-as-a-whole would rather place limitations on DLEP’s IP
addressing (e.g. possibly prohibit use of routable/global-scope
unicast addresses with a DLEP implementation).

I see multiple reasonable paths forward.  Making no changes
does not seem reasonable — or the fast path to standards-track
RFC, at least from where I sit.

Yours,

Ran