Subject: [manet] DLEP-16: Security Considerations

From: RJ Atkinson <[email-masked]>
Date: Mon, 17 Aug 2015 15:23:00 -0400

All,

DLEP version 16 has improved Security Considerations,
but the current text does not yet quite meet the need.

At present, Section 11 talks about when one SHOULD
use TLS or MAY not use TLS, which is all well and good,
but is not sufficient to have an interoperable DLEP
that provides protection against known off-link threats.

Section 11 makes no requirement on implementations, 
whereas classically, IETF protocols have MUST IMPLEMENT 
security mechanisms, even while the IETF does NOT require
use of those mechanisms.

On the list, a couple of different approaches to risk
mitigation were discussed. The proposed new text below tries 
to meld those approaches and give implementers flexibility,
while still protecting against an off-link attack.

PROPOSED NEW TEXT for Section 11:

  "All DLEP Implementations either (a) MUST implement 
  'Transport Layer Security (TLS)' [RFC-5246] so that TLS 
  is available for use if/when a DLEP user desires to use it, 
  or (b) MUST restrict the valid IPv4 unicast addresses for use 
  with DLEP to the IPv4 link-local addresses (e.g. 169.254/16) 
  and MUST restrict the valid IPv6 unicast address for use 
  with DLEP to the IPv6 link-local addresses.”

REASONING:

The above proposed text says that DLEP implementations that want 
to punt on TLS (apparently some do wish to punt on TLS) are allowed to, 
provided they protect against the offline attack vector by implementing 
restrictions against routable unicast IP addresses being used
with DLEP.

Yours,

Ran

---

From: Rick Taylor <[email-masked]>
Date: Tue, 18 Aug 2015 13:33:41 +0000

Thank you for your suggestion Ran,

There was much face to face discussion between the authors, Lou Berger 
and IESG members (amongst others) that have led us to the same 
conclusion as you.

The updated text (which will be very similar to your suggestion) will 
appear in DLEP-17.

Rick

On 17/08/15 20:23, RJ Atkinson wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 18 Aug 2015 20:22:40 +0200

On Tue, Aug 18, 2015 at 3:33 PM, Rick Taylor <[email-masked]
> wrote:

> and IESG members (amongst others) that have led us to the same

I did not see those discussions in list, but I hope we clarify those issues
into the draft as soon as possible (not more than one month). This draft is
taking time between suggestions and writting those suggestions into the
draft, which I don't know why we have such delay?

AB

---

From: Lou Berger <[email-masked]>
Date: Thu, 20 Aug 2015 11:17:11 -0500

Rick (dlep authors ),

Is there a plan for how/when you expect to address the comments you 
received  (both on and off line) ?

Thanks,
Lou

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Thu, 20 Aug 2015 17:06:57 +0000

Lou, 

We're working on it. Expect a DLEP-17, and a Credit-Windowing-00 draft.

Regards,
Stan

> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Thursday, August 20, 2015 12:17 PM
> To: Rick Taylor <[email-masked]>
> Cc: MANET WG <[email-masked]>
> Subject: [manet] Plans for dlep? (Was Re: DLEP-16: Security Considerations)
> 
> Rick (dlep authors ),
> 
> >> DLEP version 16 has improved Security Considerations, but the current
> >> text does not yet quite meet the need.
> >>
> >> At present, Section 11 talks about when one SHOULD use TLS or MAY not
> >> use TLS, which is all well and good, but is not sufficient to have an
> >> interoperable DLEP that provides protection against known off-link
> >> threats.
> >>
> >> Section 11 makes no requirement on implementations, whereas
> >> classically, IETF protocols have MUST IMPLEMENT security mechanisms,
> >> even while the IETF does NOT require use of those mechanisms.
> >>
> >> On the list, a couple of different approaches to risk mitigation were
> >> discussed. The proposed new text below tries to meld those approaches
> >> and give implementers flexibility, while still protecting against an
> >> off-link attack.
> >>
> >>
> >> The above proposed text says that DLEP implementations that want to
> >> punt on TLS (apparently some do wish to punt on TLS) are allowed to,
> >> provided they protect against the offline attack vector by
> >> implementing restrictions against routable unicast IP addresses being
> >> used with DLEP.
> >>
> >> Yours,
> >>
> >> Ran
> >>

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