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

["Christian Huitema" <[e-mail]>]

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.

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

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

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