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

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

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

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

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.

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

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.

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

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