Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15

From: Kyle Rose <[email-masked]>
Date: Mon, 10 Sep 2018 22:13:12 -0400

Apologies for the two-week absence: I've been on vacation (especially from
email) for most of that period.

On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacci <[email-masked]> wrote:

> > The whole point of LISP is to create a routing overlay for the EID
> address space, the RIB of which is managed by a global mapping system, not
> BGP sessions. If control plane traffic managed by BGP (or static routes, or
> whatever networks use once the DFZ RIB is limited to entities in the core)
> continues to flow, that is of small comfort to end users trying to get data
> over the data plane. From the perspective of end users, BGP is being
> replaced routing of the traffic that matters to them.
>
> That really is not true. You need both the overlay and underlay to get
> user traffic to flow.
>

Sure, just like you need link layer connectivity and closed circuits. User
traffic is directly handled by the overlay, which is an added layer of
novel complexity. When you add complexity, you inevitably add room for bugs
and mysterious behavior. Anyway, I'm happy to drop this point for secdir
because this is more of a general architectural observation than something
specifically related to security.

> >  * It does not resolve the trust anchor problem. Instead of proposing a
> PKI, you seem to be proposing a trusted third party authoritative for the
> Hash-EID namespace. (Q.v. section 2, the Hash-EID definition: "Another
> entity”)
>
> The trust anchor is the mapping system. And that is the PKI. And the
> mapping system is distributed.
>

What PKI? That's part of what I'm trying to establish. How do entities
decide to trust each other?

E.g., if entity A has pairwise trust with peer B, but needs an EID mapping
for peer C, it needs some way to establish that the replies it's supposedly
receiving from C are genuine. One popular model enabling you to do that
without employing transitive trust is end-to-end signing chained to a trust
anchor. With TLS as deployed on the web today, the trust anchors are a set
of mostly mutually agreed-upon CA certificates that serve as roots for the
certificates presented by every public web server. There are of course
issues with this model (q.v., certificate transparency, Symantec), but its
behavior is well-established and its properties are understood. What is the
equivalent here?

It sounds like the answer here is mapping system-specific. E.g., from a
quick perusal of the DDT draft, it sounds very DNSSEC-like (which might
suggest a course of action to eliminate the need to develop, deploy, and
maintain a custom security protocol, but that is a different discussion).

Where an interface is described without reference to a specific
implementation, a set of assumptions (e.g., "correct routing relies on the
authenticity of mapping system responses") and associated security
requirements for any conforming mapping system (e.g., "entities making use
of mapping system responses must have some way to authenticate them that
does not rely on transitive trust") need to be stated for the document to
be a complete description of a system component. That is, without first
clearly defining the required properties of any valid implementation of
described interfaces, there's no way to evaluate whether the component
under review will do what it's supposed to.

A good place to put these assumptions and requirements is in the security
considerations section: those statements are not normative for the system
component described by the draft in which they appear, but are effectively
requirements for whatever system component is to implement that interface
in a conforming way. Enumerating them as such (in the document describing
the interface in detail) allows the reader to evaluate the requirements in
light of the system using the interface, while also providing a convenient
checklist for those designing conforming systems.

A set of well-crafted security considerations sections also makes it much
easier for a reviewer to understand the security of the system as a whole
without having to understand the details of every implementation, and to
verify that individual system components under review will have the
appropriate behavior.

I'm going to skip the comments related to draft-farinacci-lisp-ecdsa-auth,
just to limit scope here. We can get back to it once that document has been
adopted and more fully fleshed-out.

> "TLS" does not appear anywhere in the draft of LISP-SEC I reviewed:
>
> Right as I explained DTLS does.
>

Check again. Just to be sure, I've tried several tools and the letters "T",
"L", and "S" do not appear consecutively anywhere in this document. Neither
do "SSL" nor "transport-level security".

> > I would like to see a discussion of whether and how the nature and scale
> of this problem differs from that of the status quo. BGP sessions and RIB
> push have properties that are well-established from decades of experience:
> surely LISP does not have exactly the same properties. The security
> considerations should make clear, for instance, how a loss of control plane
> connectivity differs from the loss of a BGP session, and how this impacts
> visibility and behavior of the data plane.
>
> Please look at the deployment drafts. Please note, you are reviewing a
> document that is focusing on encapsulating packets on an overlay. All the
> other support pieces are broken out, in what the WG felt was logical, in
> sepreate documents.
>

I think this gets back to the point I made at the end of my original
review, which is that this system is difficult to evaluate from a security
perspective in a piecewise manner given the dependencies between the
different layers and the lack of explicitly-enumerated security
requirements for each system component implementing a given interface.

Kyle

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 11 Sep 2018 11:17:57 +0200

Hi Kyle,

good for you having a break, hope you enjoyed your vacation.

Any thoughts about my last email on the subject?

Ciao

L.

> On 11 Sep 2018, at 04:13, Kyle Rose <[email-masked]> wrote:
> 
> Apologies for the two-week absence: I've been on vacation (especially from email) for most of that period.
> 
> On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacci <[email-masked] <mailto:[email-masked]>> wrote:
> > The whole point of LISP is to create a routing overlay for the EID address space, the RIB of which is managed by a global mapping system, not BGP sessions. If control plane traffic managed by BGP (or static routes, or whatever networks use once the DFZ RIB is limited to entities in the core) continues to flow, that is of small comfort to end users trying to get data over the data plane. From the perspective of end users, BGP is being replaced routing of the traffic that matters to them.
> 
> That really is not true. You need both the overlay and underlay to get user traffic to flow.
> 
> Sure, just like you need link layer connectivity and closed circuits. User traffic is directly handled by the overlay, which is an added layer of novel complexity. When you add complexity, you inevitably add room for bugs and mysterious behavior. Anyway, I'm happy to drop this point for secdir because this is more of a general architectural observation than something specifically related to security.
>  
> >  * It does not resolve the trust anchor problem. Instead of proposing a PKI, you seem to be proposing a trusted third party authoritative for the Hash-EID namespace. (Q.v. section 2, the Hash-EID definition: "Another entity”)
> 
> The trust anchor is the mapping system. And that is the PKI. And the mapping system is distributed.
> 
> What PKI? That's part of what I'm trying to establish. How do entities decide to trust each other?
> 
> E.g., if entity A has pairwise trust with peer B, but needs an EID mapping for peer C, it needs some way to establish that the replies it's supposedly receiving from C are genuine. One popular model enabling you to do that without employing transitive trust is end-to-end signing chained to a trust anchor. With TLS as deployed on the web today, the trust anchors are a set of mostly mutually agreed-upon CA certificates that serve as roots for the certificates presented by every public web server. There are of course issues with this model (q.v., certificate transparency, Symantec), but its behavior is well-established and its properties are understood. What is the equivalent here?
> 
> It sounds like the answer here is mapping system-specific. E.g., from a quick perusal of the DDT draft, it sounds very DNSSEC-like (which might suggest a course of action to eliminate the need to develop, deploy, and maintain a custom security protocol, but that is a different discussion).
> 
> Where an interface is described without reference to a specific implementation, a set of assumptions (e.g., "correct routing relies on the authenticity of mapping system responses") and associated security requirements for any conforming mapping system (e.g., "entities making use of mapping system responses must have some way to authenticate them that does not rely on transitive trust") need to be stated for the document to be a complete description of a system component. That is, without first clearly defining the required properties of any valid implementation of described interfaces, there's no way to evaluate whether the component under review will do what it's supposed to.
> 
> A good place to put these assumptions and requirements is in the security considerations section: those statements are not normative for the system component described by the draft in which they appear, but are effectively requirements for whatever system component is to implement that interface in a conforming way. Enumerating them as such (in the document describing the interface in detail) allows the reader to evaluate the requirements in light of the system using the interface, while also providing a convenient checklist for those designing conforming systems.
> 
> A set of well-crafted security considerations sections also makes it much easier for a reviewer to understand the security of the system as a whole without having to understand the details of every implementation, and to verify that individual system components under review will have the appropriate behavior.
> 
> I'm going to skip the comments related to draft-farinacci-lisp-ecdsa-auth, just to limit scope here. We can get back to it once that document has been adopted and more fully fleshed-out.
> 
> Check again. Just to be sure, I've tried several tools and the letters "T", "L", and "S" do not appear consecutively anywhere in this document. Neither do "SSL" nor "transport-level security".
>  
> > I would like to see a discussion of whether and how the nature and scale of this problem differs from that of the status quo. BGP sessions and RIB push have properties that are well-established from decades of experience: surely LISP does not have exactly the same properties. The security considerations should make clear, for instance, how a loss of control plane connectivity differs from the loss of a BGP session, and how this impacts visibility and behavior of the data plane.
> 
> Please look at the deployment drafts. Please note, you are reviewing a document that is focusing on encapsulating packets on an overlay. All the other support pieces are broken out, in what the WG felt was logical, in sepreate documents.
> 
> I think this gets back to the point I made at the end of my original review, which is that this system is difficult to evaluate from a security perspective in a piecewise manner given the dependencies between the different layers and the lack of explicitly-enumerated security requirements for each system component implementing a given interface.
> 
> Kyle

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Sep 2018 08:29:53 -0700

Responding. The draft-ietf-lisp-sec authors need to respond to one of your points below about DTLS.

> On Sep 10, 2018, at 7:13 PM, Kyle Rose <[email-masked]> wrote:
> 

The xTRs has a trust association with the mapping system because they have (1) a business relationship with them and (2) a shared-key that is used to verify Map-Register messages. From that, Map-Registers and Map-Requests are can be signed where public-keys are stored by that trusted mapping system. That is what is documented in draft-farinacci-lisp-ecdsa-auth-03, and soon to be draft-ietf-lisp-ecdsa-auth-00 (hopefully).

> E.g., if entity A has pairwise trust with peer B, but needs an EID mapping for peer C, it needs some way to establish that the replies it's supposedly receiving from C are genuine. One popular model enabling

The mapping system allows all of A-C to trust each other.

> you to do that without employing transitive trust is end-to-end signing chained to a trust anchor. With TLS as deployed on the web today, the trust anchors are a set of mostly mutually agreed-upon CA certificates that serve as roots for the certificates presented by every public web server. There are of course issues with this model (q.v., certificate transparency, Symantec), but its behavior is well-established and its properties are understood. What is the equivalent here?
> 

The designs are done, the references in the various specs are modest because of the state of the documents. We are sorry for it being hard to navigate. But for me, I am for less documents versus more, but the working group wants more modularity in the documentation so hence why all the pieces don’t seem to be connected (but they are by the security design of LISP).

> Check again. Just to be sure, I've tried several tools and the letters "T", "L", and "S" do not appear consecutively anywhere in this document. Neither do "SSL" nor "transport-level security”.

The draft-ietf-lisp-sec authors need to comment.

> I think this gets back to the point I made at the end of my original review, which is that this system is difficult to evaluate from a security perspective in a piecewise manner given the dependenc…

I don’t know how to move forward from here. I think we need help from the lisp-chairs and Deborah.

Dino

---

From: Kyle Rose <[email-masked]>
Date: Tue, 11 Sep 2018 12:40:50 -0400

On Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci <[email-masked]>
wrote:

> > E.g., if entity A has pairwise trust with peer B, but needs an EID
> mapping for peer C, it needs some way to establish that the replies it's
> supposedly receiving from C are genuine. One popular model enabling
>

Explain how with a detailed example, or point me to a detailed explanation
in a specific document. The mechanism is still not entirely clear to me. If
A and C don't have an established business relationship, how does A know
that the responses it's getting for EID mappings owned by C are genuine and
not modified by B? This is a critical property of the system, and so it
needs to be made obvious to the reader.

> The designs are done, the references in the various specs are modest
> because of the state of the documents. We are sorry for it being hard to
> navigate. But for me, I am for less documents versus more, but the working
> group wants more modularity in the documentation so hence why all the
> pieces don’t seem to be connected (but they are by the security design of
> LISP).
>

I agree with, and am not taking issue with, modularity: no one wants a
monolithic design for something this complex. But the interfaces between
the documents, by which I mean the requirements they impose on each other,
must be made explicit. When a system achieves complexity warranting design
modularity, it's simply not sufficient to describe individual system
components without providing a framework for analyzing how they fit
together without having to read and fully understand all of it. All the
information *might* in fact be there, but as an outsider not implementing
LISP, and with finite time to review, asking me to understand the minutiae
of the entire LISP ecosystem in order to understand the security properties
of the overall system is simply not reasonable. I should be able to consume
a high-level architectural overview, containing sufficient detail to
understand the security properties of the overall system, and then use that
to drill into areas of concern more deeply. This is why I want the
high-level security requirements documented somewhere, along with a set of
high-level explanations of how the proposed system components combine to
satisfy them.

Put another way: as someone whose day job it is to read and review design
documents and to offer architectural consulting on everything from from
network architecture and hardware design to build automation and SDLC tools
to dynamic job orchestration and application security, being able to
achieve a high-level mental picture of the critical properties of a design
is an important first step in evaluating a system's fitness for a
particular task. Document authors have a responsibility to make their work
consumable by people who don't already have the full context.

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Tue, 11 Sep 2018 12:48:26 -0400

I agree that the first point is probably not secdir-related, but it is
still something that should be addressed.

To the second point re: RFC 7835 and resource attacks on control vs. data
plane, what I want to see is an analysis for operators of novel attack
vectors that are created by LISP. For instance, the threat mitigation
section says:

q( The control plane is the most critical part of LISP from a security
   viewpoint, and it is worth noticing that the LISP specifications
   already offer an authentication mechanism for mappings registration
   [RFC6833].  This mechanism, combined with LISP-SEC [LISP-SEC],
   strongly mitigates threats in non-trustable environments such as the
   Internet.  Moreover, an authentication data field for Map-Request
   messages and Encapsulated Control messages was allocated [RFC6830].
   This field provides a general authentication mechanism technique for
   the LISP control plane that future specifications may use while
   staying backward compatible.  The exact technique still has to be
   designed and defined.  To maximally mitigate the threats on the
   mapping system, authentication must be used, whenever possible, for
   both Map-Request and Map-Reply messages and for messages exchanged
   internally among elements of the mapping system, such as specified in
   [LISP-SEC] and [LISP-DDT].

   Systematically applying filters and rate limitation, as proposed in
   [RFC6830], will mitigate most of the threats presented in this
   document.  In order to minimize the risk of overloading the control
   plane with actions triggered from data-plane events, such actions
   should be rate limited. )

but this doesn't specifically address the fact that a pull-based control
plane will fail in a different way, and one that is potentially harder to
diagnose, from a push-based one. One area in which it differs is that a
loss of a BGP session followed by a network partition is obvious to all
users trying to move traffic between those two networks, while choking off
control plane traffic in LISP may only affect some endpoints in a
mysterious way.

Kyle

On Tue, Sep 11, 2018 at 5:17 AM, Luigi Iannone <[email-masked]> wrote:

> Check again. Just to be sure, I've tried several tools and the letters
> "T", "L", and "S" do not appear consecutively anywhere in this document.
> Neither do "SSL" nor "transport-level security".
>
>
>> > I would like to see a discussion of whether and how the nature and
>> scale of this problem differs from that of the status quo. BGP sessions and
>> RIB push have properties that are well-established from decades of
>> experience: surely LISP does not have exactly the same properties. The
>> security considerations should make clear, for instance, how a loss of
>> control plane connectivity differs from the loss of a BGP session, and how
>> this impacts visibility and behavior of the data plane.
>>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Sep 2018 09:56:49 -0700

On Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci <[email-masked]> wrote:
> Explain how with a detailed example, or point me to a detailed explanation in a specific document. The mechanism is still not entirely clear to me. If A and C don't have an established business relationship, how does A know that the responses it's getting for EID mappings owned by C are genuine and not modified by B? This is a critical property of the system, and so it needs to be made obvious to the reader.

(1) A, B, and C register their mappings to the mapping system. They have a trust relationship with each of their respective map-servers.
(2) Those map-servers, who participate in the same mapping system and know about each other via LISP-DDT delegations, can sign referrals to tell map-resolvers that A uses to look up mappings for B and C can trust the map-servers of B and C.
(3) The map-servers can proxy-reply with the mappings for B and C to A. Or B and C can Map-Reply specifically with signed Map-Replies according to draft-ietf-lisp-sec.

Do I need to say more?

> I agree with, and am not taking issue with, modularity: no one wants a monolithic design for something

I was talking about the docments being modular (but the design is obviously so as well).

> this complex. But the interfaces between the documents, by which I mean the requirements they impose on each other, must be made explicit. When a system achieves complexity warranting design modularity, it’s

And they should be by how the reference each other. If you think there is text that makes assumpiton without a reference to the particular draft, then we can add it. 

> simply not sufficient to describe individual system components without providing a framework for analyzing how they fit together without having to read and fully understand all of it. All the information *might* in fact be there, but as an outsider not implementing LISP, and with finite time to review, asking me to understand the minutiae of the entire LISP ecosystem in order to understand the security properties of the overall system is simply not reasonable. I should be able to consume a high-level architectural overview, containing sufficient detail to understand the security properties of the overall system, and then use that to drill into areas of concern more deeply. This is why I want the high-level security requirements documented somewhere, along with a set of high-level explanations of how the proposed system components combine to satisfy them.

Yes, understand. The LISP design, especially the security design, as evolved over 10 years. So having continuity over that long period of time with work items as well as people has been challenging. And with the IETF process to boot, it was more difficult. I’m sure you understand this.

The best I can offer is, that you tell us where you are confused at a point in the text and we add text to clarify it. But the problem we have is that the IETF process will not allow us to reference documents that are more inmmature than the document referencing it.

> Put another way: as someone whose day job it is to read and review design documents and to offer architectural consulting on everything from from network architecture and hardware design to build automation and SDLC tools to dynamic job orchestration and application security, being able to achieve a high-level mental picture of the critical properties of a design is an important first step in evaluating a system's fitness for a particular task. Document authors have a responsibility to make their work consumable by people who don't already have the full context.

Well, we have, and each generation of people that come along want more changes and more consumability We are doing the best we can given the existing parameters, for a decade.  ;-)

So I suggest, you look at something and say “I think this is a bug”, or “I see something missing here, is there a design and does it need a reference”. I don’t know, that’s the most practical way I can see moving forward.

I think we are going to have the same issues/recommendations for Mirja’s comments as well.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Sep 2018 10:11:25 -0700

> but this doesn't specifically address the fact that a pull-based control plane will fail in a different way, and one that is potentially harder to diagnose, from a push-based one. One area in which it differs is that a loss of a BGP session followed by a network partition is obvious to all users trying to move traffic between those two networks, while choking off control plane traffic in LISP may only affect some endpoints in a mysterious way.

IMO, a feature and not a bug. And arguably harder to diagnose makes it more secure.

Dino

---

From: Kyle Rose <[email-masked]>
Date: Tue, 11 Sep 2018 13:30:40 -0400

> IMO, a feature and not a bug. And arguably harder to diagnose makes it

Possibly. But being better or worse isn't my point, so much that it's
*different* in a material way from a security perspective. Those deltas are
where something proposing to supplant the prevailing mechanism for DFZ
routing needs to be clear to operators.

Kyle

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Sep 2018 10:36:28 -0700

We are not supplanting the mechanism for routing. There is a layer above routing that can (1) pull like DNS, and/or (2) push like BGP to realize an overlay.

Dino

> On Sep 11, 2018, at 10:30 AM, Kyle Rose <[email-masked]> wrote:
> 
> Possibly. But being better or worse isn't my point, so much that it's *different* in a material way from a security perspective. Those deltas are where something proposing to supplant the prevailing mechanism for DFZ routing needs to be clear to operators. 
> 
> Kyle
>

---

From: Kyle Rose <[email-masked]>
Date: Tue, 11 Sep 2018 14:28:57 -0400

On Tue, Sep 11, 2018 at 12:56 PM, Dino Farinacci <[email-masked]>
wrote:

> > Explain how with a detailed example, or point me to a detailed
> explanation in a specific document. The mechanism is still not entirely
> clear to me. If A and C don't have an established business relationship,
> how does A know that the responses it's getting for EID mappings owned by C
> are genuine and not modified by B? This is a critical property of the
> system, and so it needs to be made obvious to the reader.
>
> (1) A, B, and C register their mappings to the mapping system. They have a
> trust relationship with each of their respective map-servers.
> (2) Those map-servers, who participate in the same mapping system and know
> about each other via LISP-DDT delegations, can sign referrals to tell
> map-resolvers that A uses to look up mappings for B and C can trust the
> map-servers of B and C.
> (3) The map-servers can proxy-reply with the mappings for B and C to A. Or
> B and C can Map-Reply specifically with signed Map-Replies according to
> draft-ietf-lisp-sec.
>
> Do I need to say more?
>

This is definitely clearer. The trust relationships appear to be:

 * A network trusts a particular map server to be authoritative for the
entire EID/RLOC mapping.
 * The map servers trust the LISP-DDT root: they use LISP-DDT to publish
and resolve EID/RLOC mappings, and can directly authenticate those mappings
because they are signed in a hierarchical fashion (like DNSSEC).

The first is a transitive trust relationship, but this is probably
acceptable because it's only one hop (I'm trusting someone else to verify a
piece of data that has been authenticated end-to-end) and there is a direct
business relationship between the two entities.

The second, if I have the general idea correct, is very much like DNSSEC or
the web CA system in that a compromise of a node in the signature
tree/forest leads to a loss of authenticity for that entire subtree. This
is not disqualifying: clearly, many standardized systems have this
property. But it's important to state it explicitly so we can at the very
least make the properties clear to operators, and potentially recommend
and/or develop mitigations.

> > this complex. But the interfaces between the documents, by which I mean
> the requirements they impose on each other, must be made explicit. When a
> system achieves complexity warranting design modularity, it’s
>
> And they should be by how the reference each other. If you think there is
> text that makes assumpiton without a reference to the particular draft,
> then we can add it.
>

What I might recommend is either an augmentation of, or a new document
analogous to (and informationally referencing),
draft-ietf-lisp-introduction that covers the expected security properties
of the overall design and the requirements for each of the subcomponents in
a way that someone can understand without referring to any document other
than the high-level architecture itself. draft-ietf-lisp-introduction is
actually quite good at getting the general point of LISP across to someone
new; I want to see something similar for LISP's security model. I think
that's going to be better than inserting clarifying text here or there.
I've actually read enough of this stuff at this point that I'm not sure I
can enumerate exactly what's missing where. The threat model document could
potentially be folded into that, but it has to start by painting a picture
of the security that someone new to LISP can quickly understand.

Kyle

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Sep 2018 11:39:35 -0700

>  * A network trusts a particular map server to be authoritative for the entire EID/RLOC mapping.

Yes, a map-server is delegated part of the EID-prefix space for any more specifics prefixes registered to it. That is what the parent of the LISP-DDT sends referrals for.

>  * The map servers trust the LISP-DDT root: they use LISP-DDT to publish and resolve EID/RLOC mappings, and can directly authenticate those mappings because they are signed in a hierarchical fashion (like DNSSEC).

Yes. A delegated hierarchy where the parent provides the public-key in referrals so when the child signs its referrals, it can be verified (by the map-resolver).

> The first is a transitive trust relationship, but this is probably acceptable because it's only one hop (I'm trusting someone else to verify a piece of data that has been authenticated end-to-end) and there is a direct business relationship between the two entities.

Right.

> The second, if I have the general idea correct, is very much like DNSSEC or the web CA system in that a compromise of a node in the signature tree/forest leads to a loss of authenticity for that entire

Yep, correct.

> subtree. This is not disqualifying: clearly, many standardized systems have this property. But it's important to state it explicitly so we can at the very least make the properties clear to operators, and potentially recommend and/or develop mitigations.

Right, that is in the LISP-DDT spec on how map-servers should behave when they run LISP-DDT. Remember that 6833bis is how the xTRs use the mapping system to talk to map-resolvers and map-servers (as well as xTR to xTR for probing and map-replying, etc).

> And they should be by how the reference each other. If you think there is text that makes assumpiton without a reference to the particular draft, then we can add it. 

Do you think (need opinions from the chair), that if we put a document tree in draft-ietf-lisp-introduction, would that be helpful? The only drawback is that we may get a circular dependency. But could avoid it by having:

(1) Have lisp-intro point to 6830bis and 6833bis.
(2) Have 6830bis and 6833bis point to 6830/6833
(3) And none of the 4 documents point to lisp-intro (obviously RFC6830 and RFC6833 do not) but the new bis shoud not.

But that is not good for the reader, because if someone picks up 6830bis and realizes they do not want that level of detail, they don’t know by reading it to go to draft-ietf-lisp-introduction.

> What I might recommend is either an augmentation of, or a new document analogous to (and informationally referencing), draft-ietf-lisp-introduction that covers the expected security properties of the overall design and the requirements for each of the subcomponents in a way that someone can understand without referring to any document other than the high-level architecture itself. draft-ietf-lisp-introduction is actually quite good at getting the general point of LISP across to someone new; I want to see something similar for LISP's security model. I think that's going to be better than inserting clarifying text here or there. I've actually read enough of this stuff at this point that I'm not sure I can enumerate exactly what's missing where. The threat model document could potentially be folded into that, but it has to start by painting a picture of the security that someone new to LISP can quickly understand.

I’ll yield to the WG to respond to this.

Dino

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 11 Sep 2018 21:55:53 +0000

Thanks much Kyle for your comments and Dino for resolving!

Cutting to the end where Dino asked for help-

-----Original Message-----
From: Dino Farinacci <[email-masked]> 
Sent: Tuesday, September 11, 2018 2:40 PM
To: Kyle Rose <[email-masked]>
Cc: IETF SecDir <[email-masked]>; [email-masked]; IETF Discussion Mailing List <[email-masked]>; [email-masked] list <[email-masked]>; Benjamin Kaduk <[email-masked]>; Mirja Kühlewind <[email-masked]>
Subject: Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15

Dino

[deborah] 

It's difficult to do *one* overview document on an evolving technology, especially if the intention is to provide reference to other documents which are also evolving. Lisp-intro is already having its problems and it is not published yet.

As Mark Nottingham noted in his "How to Read an RFC" blog, when reading RFCs, for better or worse and the resulting frustration, it is "necessary to read not only the relevant text but also anything that it references":
https://www.ietf.org/blog/how-read-rfc/

I'd suggest a wiki would be a better tool to capture this "overview" informational material. Not only can the format be easier on the eye, it can be a shared effort and timely updated. Similar to Benoit's work on his YANG tree dependencies, it would be helpful if a working group provided a working group tree of documents and it could even reference other working group documents.

---

From: Kyle Rose <[email-masked]>
Date: Fri, 14 Sep 2018 12:29:38 -0400

My response is that while I suspect based on the conversation between
myself and Dino that LISP's security model probably adequately protects
mapping system integrity, my confidence in that judgment is low because the
information I need for a security review I can't find in the drafts without
reading every LISP-related document in detail, a time commitment I simply
can't justify. It's possible there's someone else in the security
directorate who knows more about the details of LISP and so would be able
to much more easily answer some of these questions with confidence; if so,
I would recommend that you ask them to take a look. I'm unwilling to say
"LGTM" simply because I can't find a problem in the time I've allocated.

Kyle

On Tue, Sep 11, 2018 at 5:55 PM, BRUNGARD, DEBORAH A <[email-masked]> wrote:

> Cc: IETF SecDir <[email-masked]>; [email-masked];
> IETF Discussion Mailing List <[email-masked]>; [email-masked] list <
> [email-masked]>; Benjamin Kaduk <[email-masked]>; Mirja Kühlewind <
> [email-masked]>
> It's difficult to do *one* overview document on an evolving technology,
> especially if the intention is to provide reference to other documents
> which are also evolving. Lisp-intro is already having its problems and it
> is not published yet.
>
> As Mark Nottingham noted in his "How to Read an RFC" blog, when reading
> RFCs, for better or worse and the resulting frustration, it is "necessary
> to read not only the relevant text but also anything that it references":
> I'd suggest a wiki would be a better tool to capture this "overview"
> informational material. Not only can the format be easier on the eye, it
> can be a shared effort and timely updated. Similar to Benoit's work on his
> YANG tree dependencies, it would be helpful if a working group provided a
> working group tree of documents and it could even reference other working
> group documents.
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Sep 2018 09:59:49 -0700

The SAAG has helped the LISP WG with RFC8061 (data-plane). And Brian Weiss and Dan Harkins were authors/reviewers.

As for the control-plane, draft-ietf-lisp-sec has been around and implmented by cisco (in 3 implementations). RFC8111 (LISP-DDT) has been around as well for a while, a pilot network deployed using it, and cisco has an implementation of LISP-DDT-SEC. Draft draft-farinacci-lisp-ecdsa is relatively new, necessary for IoT deployments. I have done an implementation of it. I don’t know if that helps but focusing on those 3 documents can clearly explain (in detail) the security mechanisms in place.

Your comment is noted about not seeing TLS or DTLS in draft-ietf-lisp-sec but we had always intended it to be in there. I’m not sure (I thought it was in) if it was removed for some reason. The authors can comment about that.

Dino

> On Sep 14, 2018, at 9:29 AM, Kyle Rose <[email-masked]> wrote:
> 
> My response is that while I suspect based on the conversation between myself and Dino that LISP's security model probably adequately protects mapping system integrity, my confidence in that judgment is low because the information I need for a security review I can't find in the drafts without reading every LISP-related document in detail, a time commitment I simply can't justify. It's possible there's someone else in the security directorate who knows more about the details of LISP and so would be able to much more easily answer some of these questions with confidence; if so, I would recommend that you ask them to take a look. I'm unwilling to say "LGTM" simply because I can't find a problem in the time I've allocated.
> 
> Kyle
> 
>