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

["Taylor, Rick (External)" <[e-mail]>]

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

> -----Original Message-----
> From: Christian Huitema [mailto:[e-mail]]
> Sent: 29 November 2016 03:04
> To: 'Paul Hoffman'; Taylor, Rick (External)
> Cc: 'secdir'; [e-mail]
> Subject: RE: [secdir] SecDir review of draft-ietf-manet-dlep
>
> On Tuesday, November 22, 2016 5:46 AM, Paul Hoffman wrote:
> > On 22 Nov 2016, at 3:34, Taylor, Rick (External) wrote:
> >
> >> 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.
> >
> > 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.

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

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

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.