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

["Ratliff, Stanley" <[e-mail]>]

Christian/Paul, 

Thanks for your time and effort to review DLEP. I have a question inline. 

> -----Original Message-----
> From: Christian Huitema [mailto:[e-mail]]
> Sent: Tuesday, November 29, 2016 7:29 PM
> To: 'Taylor, Rick (External)' <[e-mail]>; 'Paul Hoffman'
> <[e-mail]>
> Cc: 'secdir' <[e-mail]>; [e-mail]
> Subject: RE: [secdir] SecDir review of draft-ietf-manet-dlep
> 
> 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.
> 

Yes, this is a reasonable scenario. Can you point me to a document that describes this one-time "paring", and then uses TLS? That seems like a solution we could leverage. 

The main issue, as Rick mentions, is that we (the authors) have received significant push-back from some radio vendors about implementing TLS in existing gear. DLEP has applicability 
in both the commercial and government-use spaces. Specifically in the government-use case, there is concern about requiring TLS functionality when both the radio(s) and the router 
are placed into a "physically secure environment" - for instance, into an armored vehicle, that already contains a high-grade Information Assurance device (like a HAIPE encryptor). In 
that type of environment, the requirement to use TLS is somewhat redundant. 

However, the protocol is useful in the commercial environment as well, and in those cases (as Rick has already said), we completely agree that proper security mechanisms should be 
implemented. We heard earlier in the discussion of the protocol that SecDir would essentially give us "MUST implement/MAY use" direction with regard to TLS - would it be acceptable 
to state the requirement as "SHOULD implement/MAY use", provided that use of TLS is strongly recommended, unless the deployment environment is physically secure? 

Regards,
Stan 


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

============================================================================================================================================
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.