Subject: [lisp] I-D Action: draft-ietf-lisp-threats-04.txt

From: [email-masked]
Date: Mon, 25 Feb 2013 10:02:18 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF.

	Title           : LISP Threats Analysis
	Author(s)       : Damien Saucez
                          Luigi Iannone
                          Olivier Bonaventure
	Filename        : draft-ietf-lisp-threats-04.txt
	Pages           : 34
	Date            : 2013-02-25

Abstract:
   This document analyzes the potential threats against the security of
   the Locator/Identifier Separation Protocol (LISP) if deployed in the
   Internet.  This document proposes a set of recommendations to
   mitigate the identified security risks and keep a security level
   equivalent to what is observed in the Internet today (i.e., without
   LISP).  By following the recommendations of this draft a LISP
   deployment can achieve a security level that is comparable to the
   existing Internet architecture.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-threats

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-lisp-threats-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-threats-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 25 Feb 2013 15:12:52 -0500

The authors have submitted a major revision of this documet.
Please read it (the diff tool will show you have much they have changed.
We need to be confident that the working group is happy with the changes 
the authors hae made.
We will discuss this in orlando.  Email comments before then would be 
appreciated.

Thank you,
Joel

-------- Original Message --------
Subject: I-D Action: draft-ietf-lisp-threats-04.txt
Date: Mon, 25 Feb 2013 10:02:18 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
  This draft is a work item of the Locator/ID Separation Protocol 
Working Group of the IETF.

Abstract:

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 25 Feb 2013 22:55:15 +0000

Hi,

I am reading this document for the first time and had a few
comments to share below.

Thanks - Fred
[email-masked]

1) Section 2.5 ("Tunnel Routers Behind NAT"), this seems to
   show a limitation in that there can be only one xTR behind
   a NAT. I would like to address the case when there may be
   many xTRs behind the NAT - can LISP do that?

2) Section 2.6, I don't understand why it says "MTU/PMTUD
   issues minimized" for the recursive scenario?

3) Section 6.1, number 4, should say "request increase in MTU
   to 1556 *or greater* on service provider connections".
   However, controlling just the first-hop interface MTU
   does not assure MTU mitigations across the entire path.
   Similarly, "care must be taken that ICMP is not being
   filtered" cannot be assured along the entire path. And,
   studies have shown that ICMP filtering does impact MTU
   handling in current operational practices:

   http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf

Additionally, I have a use case that I'm not sure is well addressed by
the document. I would like to address the use case of mobile networks
configured as stub sites that connect to ISPs via a mobile router. Each
mobile router may have multiple ISP connections, and can change its ISP
addresses dynamically as it moves around. Some of the ISP addresses may
be global and others may be private, such as behind a carrier-grade NAT.
Many such mobile routers may be located behind the same NAT.

I want to give each mobile router an EID prefix that it can use to number
interfaces within the mobile network. The mobile network may contain just
one interface, a few interfaces, or it may contain many interfaces.

I now want that the mobile network can remain reachable from the outside
world by the same EID prefix addresses even as the mobile router travels
around dynamically. The mobile router will need an xTR so that its ISPs
will not filter its packets that use EID source addresses. I also want
the mobile router to be able to traffic engineer in both the outgoing
*and* incoming directions. For this, there needs to be some sort of
server sitting outside of any NATs that the mobile router can "register"
itself with. The mobile router should be able to change between different
servers as it moves around, e.g., to reduce path stretch or in the
event of a server failure. The servers in turn associate with proxy
xTRs so that outgoing packets destined to EIDs located in distant
networks can be routed appropriately.

This is the way IRON sets things up. Can it also be done with LISP?

---

From: Lori Jakab <[email-masked]>
Date: Wed, 27 Feb 2013 18:30:10 +0200

Hi Fred,

Thank you very much for the feedback.  See responses in-line below:

>    many xTRs behind the NAT - can LISP do that?

There is specification being worked on that will enable many xTRs behind
NAT.  It will, however require a Re-encapsulating Tunnel Router (RTR) to
proxy all data packets for it to work. See
https://tools.ietf.org/html/draft-ermagan-lisp-nat-traversal

>    issues minimized" for the recursive scenario?

It's a typo, thanks for catching this!

>    to 1556 *or greater* on service provider connections".

Indeed, will fix.

>    http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf

True, we are citing RFC 4459 at the end of section 2.1 with regard to
this issue.  Would it help if we referenced it in this section as well?

> This is the way IRON sets things up. Can it also be done with LISP?

Yes, using the NAT traversal specification I mentioned above.  The
mobile router should be an xTR itself, and will receive a list of RTRs
(what you call servers above) it can use for traversing the NAT (for the
connections where a NAT is detected).  Path stretch optimizations are
certainly possible, they depend on the implementation of the
Map-Server.  Incoming traffic engineering is possible with LISP,
however, outgoing traffic engineering is not LISP specific, it should be
done with existing mechanisms.

Would you like this scenario added to the document?

Best regards,
-Lori

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 Feb 2013 21:56:56 +0000

Hi Lori,

> -----Original Message-----
> From: Lori Jakab [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2013 8:30 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [lisp] comments on 'draft-ietf-lisp-deployment-06'
> 
> Hi Fred,
> 

Thanks - I too noticed this draft after having sent the message.

> It's a typo, thanks for catching this!

OK.

> >    to 1556 *or greater* on service provider connections".

OK. I leave the exact language up to you, but I think we agree
on the point.

> this issue.  Would it help if we referenced it in this section as well?

The "Verify MTU Handling" recommendations only apply to the
first-hop service provider connection. There is no way to
control any further hops beyond that. Maybe just add a
trailing sentence such as: "However, even with these
mitigations path MTU issues are still possible [RFC4459]."

> Yes, using the NAT traversal specification I mentioned above.

OK.

> The mobile router should be an xTR itself,

OK. That matches with the "IRON Client" [RFC6179].

> and will receive a list of RTRs
> (what you call servers above) it can use for traversing the NAT

Right. that matches with the "IRON Server".

> (for the connections where a NAT is detected).

It is also OK to just use the same function even for RLOCs
that are not behind a NAT.

> Path stretch optimizations are certainly possible,

Right - that matches with AERO [RFC6706].

> they depend on the implementation of the Map-Server.

OK.

> Incoming traffic engineering is possible with LISP,

How does the LISP mobile node tell the network how it wants
its inbound traffic to be delivered? IRON Clients provide
their Servers with a set of "handles" that represent their
ISP connections. The Client then informs the server as to how
it would like its inbound traffic to be delivered across
those handles - for example, some flows could be delivered
via the Client's WiFi interface and others delivered via the
Client's 4G interface, etc. Here, a handle is used instead of
an ISP address because the ISP address can change even while
the handle remains the same. 

> done with existing mechanisms.

Right - the same for IRON.

> Would you like this scenario added to the document?

You might want to take a look at "RANGER Scenarios" [RFC6139] for
this and other scenarios which might also be applicable to LISP.
>From what you are saying, it sounds like addressing this scenario
is somewhat of a work-in-progress for LISP, where IRON already
has it pretty much worked out. It might be worth a comparative
study between the two approaches to see which pieces look the
most promising - and, the study could possibly indicate that a
combination of some features from both approaches would make the
most sense. The IRON-related documents are here:

http://www.rfc-editor.org/rfc/rfc5320.txt
http://www.rfc-editor.org/rfc/rfc5558.txt
http://www.rfc-editor.org/rfc/rfc5720.txt
http://www.rfc-editor.org/rfc/rfc6139.txt
http://www.rfc-editor.org/rfc/rfc6179.txt
http://www.rfc-editor.org/rfc/rfc6706.txt
https://datatracker.ietf.org/doc/draft-templin-intarea-seal/
https://datatracker.ietf.org/doc/draft-templin-intarea-vet/
https://datatracker.ietf.org/doc/draft-templin-ironbis/

Thanks - Fred