Subject: Re: [secdir] SecDir review of draft-ietf-manet-dlep

From: "Taylor, Rick (External)" <[email-masked]>
Date: Tue, 22 Nov 2016 11:34:19 +0000

Hi Paul,

Thank you for the review.  A couple of quick comments:

Did you review draft-ietf-manet-dlep-15 or draft-ietf-manet-dlep-25 (the latest)?  As we have attempted to address the security comments raised by the WG and AD review.

One area we have worked hard on addressing is mandating use of RFC5082 (Generalized TTL Security) on the link between router and modem (See Section 3.1).  As you correctly state, DLEP does not have any inherent security mechanisms, and recommends link-layer security, such as 802.1X/AE, but we do mandate mechanisms to restrict the protocol to run over a single hop.  As you point out, DLEP is a control-plane protocol and does not carry any user data.

We have updated the security considerations (section 12) since draft-15, please can you see if the new verbiage addresses your valid comments?

Many thanks,

Rick Taylor

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]]
Sent: 16 November 2016 07:02
To: [email-masked]; secdir
Subject: SecDir review of draft-ietf-manet-dlep

Greetings. This is a review of draft-ietf-manet-dlep-15 for the Security Directorate. Please treat these comments as you would any IETF Last Call comments you get.

As I understand it, Dynamic Link Exchange Protocol (DLEP) is a protocol for a router and wireless modem to inform each other about characteristics of the link in order to make better routing decisions.
It runs over UDP and TCP, and is explicitly meant to be only valid on a single L2 hop directly between the modem and router. (Please let me know if I have this wrong!)

There is no security in DLEP. At the end of Section 3, it says:
    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.
Further, there is no mandatory-to-implement L2 security protocol; 802.1X and 802.1AE are mentioned as possibly being used, but neither is required to be implemented.

This, the specified security is pretty weak. It is not clear what advantage an attacker would get by snooping on the DLEP traffic: the values exchanged are pretty easy to determine just by watching the link.
It is also not clear what advantage an attacker would get by impersonating either party or mounting an MITM attack other than degrading the link, which an MITM could do anyways.

This feels like a classic IETF "we don't deal with security and leave it to the layer below us" protocol, which might be acceptable in this case because of the nature of the data being exchanged.

--Paul Hoffman

This mail has originated outside your organization, either from an external partner or the Global Internet.
Keep this in mind if you answer this message.

--
Airbus Defence and Space has taken all possible efforts to ensure this email is free from malicious code; however, never open suspicious emails or attachments or follow unknown hyperlinks.

The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure.

If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system.

Emails to Airbus Defence and Space Limited may be processed, recorded and monitored anywhere in the European Community.

Airbus Defence and Space Limited

Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS.
Registered in England and Wales under company number 02449259.

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 22 Nov 2016 07:46:05 -0800

On 22 Nov 2016, at 3:34, Taylor, Rick (External) wrote:

> Did you review draft-ietf-manet-dlep-15 or draft-ietf-manet-dlep-25 
> (the latest)?  As we have attempted to address the security comments 
> raised by the WG and AD review.

I reviewed -25; sorry for the typo in my report.

> One area we have worked hard on addressing is mandating use of RFC5082 
> (Generalized TTL Security) on the link between router and modem (See 
> Section 3.1).  As you correctly state, DLEP does not have any inherent 
> security mechanisms, and recommends link-layer security, such as 
> 802.1X/AE, but we do mandate mechanisms to restrict the protocol to 
> run over a single hop.  As you point out, DLEP is a control-plane 
> protocol and does not carry any user data.

Noted. However, requiring TTL security doesn't prevent snooping or MITM 
attacks.

--Paul Hoffman

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 28 Nov 2016 17:04:03 -1000

> I reviewed -25; sorry for the typo in my report.

I was asked to review draft-ietf-manet-credit-window-07, whose security
properties are inherited from draft-ietf-manet-dlep-25, so I also reviewed
draft-ietf-manet-dlep-25. Like Paul, I find the security of DLEP pretty
weak. DLEP “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 layer 2 security model is effectively an implementation of “perimeter
security”, and has all the known issues with perimeter security. Two classic
attacks are “finding a way to send packets through the perimeter” and
“subvert a node already installed inside the perimeter”. The draft attempts
to mitigate the first class of attacks by using the mechanism of RFC 5082,
although it does not actually use it correctly. There is no mitigation for
the “subverted node” attack.

>> Section 3.1).  

Not quite. RFC5082 suggests setting the TTL to 255 and checking the value on
the received message. Your draft suggests setting the TTL value to 1, and
checking the received value in the message. You need to fix that.

>>... As you correctly state, DLEP does not have any inherent 

TTL security also does not provide any defense in depth. If the attackers
manage to gain access inside the perimeter, all bets are off. And there is a
history of such attacks, e.g., what if some test node on the secure link is
infected by a virus. Your architecture has zero protection there. Any node
can issue a discovery request, establish a DLEP session, and control the
radio modem. That was OK in the 90's, but I do not believe that's acceptable
now.

-- Christian Huitema

---

From: "Taylor, Rick (External)" <[email-masked]>
Date: Tue, 29 Nov 2016 12:08:40 +0000

Hi All,

Thank you both for your reviews and further comments. I'm not the author of draft-ietf-manet-credit-window-07, but am one of the authors of draft-ietf-manet-dlep-25.  However, as the security of the credit windowing extension relies on the underlying security considerations of DLEP, I feel I can respond.

A few comments inline...

> From: Christian Huitema [mailto:[email-masked]]
> Sent: 29 November 2016 03:04
> To: 'Paul Hoffman'; Taylor, Rick (External)
> Cc: 'secdir'; [email-masked]
> Subject: RE: [secdir] SecDir review of draft-ietf-manet-dlep
>
> draft-ietf-manet-dlep-25. Like Paul, I find the security of DLEP pretty weak.
> DLEP "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 layer 2 security model is effectively an implementation of "perimeter
> security", and has all the known issues with perimeter security. Two classic
> attacks are "finding a way to send packets through the perimeter" and
> "subvert a node already installed inside the perimeter". The draft attempts
> although it does not actually use it correctly. There is no mitigation for the
> "subverted node" attack.

There has been extensive discussion within the WG on this topic, and we do fully understand the concerns.  The security of DLEP has always been a major worry for the authors/WG as we are being pulled in two directions:  The sticking point is the situation where an implementer has the modem and router as two separate modules in a single chassis (or secured perimeter), and wants to avoid the perceived complexity/annoyance of implementing TLS.   The authors have received off-the-record comment from major radio vendors stating that they will not adopt DLEP if it requires TLS.  However, I agree that both your comments are absolutely valid.  The question is how to reconcile the difference?

We are searching for some mechanism that would allow the protocol to:

a) Specify how to secure the session correctly.
b) Secure the session by default.
c) Allow either peer to waive the requirement for security in a way that cannot be maliciously downgraded.

Is a STARTTLS style approach acceptable? Or is an http/https style two port approach preferred?  I'm not asking for the solution, but trying to avoid wasting your and our time.

>
> >> One area we have worked hard on addressing is mandating use of
> >> RFC5082 (Generalized TTL Security) on the link between router and
> >> modem (See Section 3.1).
>

TTL 1 is required for the discovery mechanism (UDP mcast) in an attempt to restrict packets to a single hop (particularly for IPv4), but the TCP connection for the session must use TTL 255 as per RFC5082 (The paragraph above).  We might consider re-ordering the paragraphs if you think it is unclear.

* snip *

Many thanks,

Rick Taylor

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 29 Nov 2016 14:28:38 -1000

On Tuesday, November 29, 2016 2:09 AM, Rick Taylor wrote:

> There has been extensive discussion within the WG on this topic, and we do
> fully understand the concerns.  The security of DLEP has always been a
major 
> worry for the authors/WG as we are being pulled in two directions:  The
sticking 
> point is the situation where an implementer has the modem and router as
two
> separate modules in a single chassis (or secured perimeter), and wants to
avoid
> the perceived complexity/annoyance of implementing TLS.   The authors have

> received off-the-record comment from major radio vendors stating that they
will 
> not adopt DLEP if it requires TLS.  However, I agree that both your
comments are 
> absolutely valid.  The question is how to reconcile the difference?

There may be different deployment scenarios. As is, I would not recommend
deploying DLEP if the Lan provides access to anything else than the router
and the modem. For the other scenarios, you really want to use something
like TLS with appropriate credentials.

> c) Allow either peer to waive the requirement for security in a way that
cannot be maliciously 
> downgraded.
>
> Is a STARTTLS style approach acceptable? Or is an http/https style two
port approach 
> preferred?  I'm not asking for the solution, but trying to avoid wasting
your and our time.

Of course, I have no idea of the operational constraints, but at a high
level you seem to have the same problem as various small appliances and
devices. My gut feeling is that the same solutions apply, e.g., a one time
"pairing" to establish trust between router and modem, and then using TLS
and verifying the appropriate credentials, e.g., some shared secret. You
could make that optional when the perimeter is really tightly controlled.

> TTL 1 is required for the discovery mechanism (UDP mcast) in an attempt to
restrict 
> packets to a single hop (particularly for IPv4), but the TCP connection
for the session
> must use TTL 255 as per RFC5082 (The paragraph above).  We might consider
re-ordering
> the paragraphs if you think it is unclear.

TTL 255 prevents nodes from receiving packets from outside the LAN, TTL 1
prevents nodes from leaking packets outside the LAN. An attacker can format
an UDP packet with a TTL just right, so that it arrives on the LAN with
TTL=1. At a minimum, this allows the attacker to trigger multicast UDP
replies, i.e., a form of DOS attack. Lucky attackers might be able to send a
complex packet and trigger a code fault. That's why "prevent packets from
the outside in" is generally better than "prevent packets from the inside
out" -- multicast routing normally stops transmission outside the LAN
anyhow. 

If you decide to stick to TTL=1 for UDP, then you should definitely make the
text explicit, explain the difference of treatment between TCP and UDP.

-- Christian Huitema