Subject: [lisp] Last Call: <draft-ietf-lisp-ms-11.txt> (LISP Map Server) to Experimental RFC

From: The IESG <[email-masked]>
Date: Wed, 14 Sep 2011 07:29:29 -0700

The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP Map Server'
  <draft-ietf-lisp-ms-11.txt> as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-09-28. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This draft describes the LISP Map Server (LISP-MS), a computing
   system which provides a simplified LISP protocol interface as a
   "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC)
   mapping database and associated virtual network of LISP protocol
   elements.

   The purpose of the Map Server is to reduce implementation and
   operational complexity of LISP Ingress Tunnel Routers (ITRs) and
   Egress Tunnel Routers (ETRs), the devices that implement the "edge"
   of the LISP infrastructure and which connect directly to LISP-capable
   Internet end sites.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-lisp-ms/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-lisp-ms/

No IPR declarations have been submitted directly on this I-D.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 14 Sep 2011 10:15:42 -0700

I have a question about source address spoofing by a
node in the Internet pretending to be an ITR. The
document says that the ETR: "MAY compare the inner
header source EID address and the outer header source
RLOC address with the mapping that exists in the
mapping database". But a few questions arise from that.

First, what if the ETR does not observe the MAY, and
simply lets anonymous nodes pretend to be ITRs that
send inner packets with spoofed EID source addresses?
Those packets could result in a target node in the
ETR's site sending replies to a victim node in the
Internet. Is it OK to just let that happen?

Second, what if the ETR does observe the MAY, but
the ITR's RLOC source addresses change dynamically;
perhaps due to mobility. Would the ETR be able to
keep up with all of the RLOC address changes in real
time?

Third, I'm also wondering whether it is just end nodes
that could pretend to be ITRs, or whether there is also
a concern for middleboxes that can examine LISP exchanges
and then pretend to be ITRs based on what they observe?

I'm not trying to poke holes in the proposal; I'm just
trying to understand if the LISP ITR/ETR relationship
increases the attack surface for source address spoofing
beyond the current state of affairs for the non-LISP
Internet. Thanks in advance for any insights.
 
Fred
[email-masked]

---

From: Damien Saucez <[email-masked]>
Date: Wed, 14 Sep 2011 11:07:11 -0700

Fred,

You are totally right, obviously if you increase the number  of
source addressees in a packet you increase the spoofing risk.

In the threats draft, two different spoofing techniques are presented
(EID Spoofing and RLOC Spoofing). We then show the different
attacks that can be conducted with such spoofing.

One "funny" attack is by spoofing at the same time the EID and
the RLOC.

Without cryptography, there is no perfect solution to avoid
spoofing. Your example with dynamic RLOC is interesting.
If everything goes well, you should never have a TTL
longer than the RLOC lease time. However, in the case
the RLOC changes before the expiration, you will need
SMR or version change implying the retrieval of the new
mapping. But in this particular case, you also have a
security threat that is a DoS…

Regards,

Damien Saucez

On 14 Sep 2011, at 10:15, Templin, Fred L wrote:

> perhaps due to

> ity. Would the ETR be able to
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 14 Sep 2011 14:18:37 -0700

Hi Damien, 

> -----Original Message-----
> From: Damien Saucez [mailto:[email-masked]] 
> Sent: Wednesday, September 14, 2011 11:07 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [lisp] Source address spoofing by a node 
> pretending to be an ITR?
> 
> Fred,
> 

Thanks for pointing out the threats document. In
Section 4, it says: "We do not consider that LISP
has to cope with [on-path] attackers.". Can you
say more about that - for example, are you saying
that on-path attacks will never happen, or that
they can happen but are harmless and therfore not
a matter for concern?

I personally would prefer to not have to worry about
on-path attacks, but I'm not sure that they can simply
be ignored and pretend that they won't happen. But,
perhaps a case can be made that on-path attacks are
no more a matter for concern for LISP than they are
for the non-LISP public Internet? In any case, I'd be
interested to know the rationale behind the Section 4
text.

> security threat that is a DoS...

Do you see a clear way past these and other threats?
Will it be the case that LISP and its ilk will be
hard to secure and thus difficult to deploy?

Thanks - Fred

---

From: Rani Assaf <[email-masked]>
Date: Wed, 14 Sep 2011 22:39:21 +0200 (CEST)

Hi,

----- Original Message -----
> send inner packets with spoofed EID source addresses?

You have a worst attack: what happens to an ETR that uses
the RLOC status bits and someone forge data packets from another
ITR toward this ETR and plays with those bits?

Best,
Rani

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 15 Sep 2011 22:41:08 +0200

Hi,

> ITR toward this ETR and plays with those bits?

Both the LISP main document and the lisp-threats document already pointed out this. They state that a change in the Loc-Status-Bit should be confirmed with a Map-Request/Map-Reply exchange.

Luigi

---

From: Damien Saucez <[email-masked]>
Date: Thu, 15 Sep 2011 15:53:18 -0400

Hello Fred,

> they can happen but are harmless and therfore not

No, these attacks exist, can be very harmful but unfortunately, except with
some cryptography, I do not see how we can protect the system against
on-path attackers.
> interested to know the rationale behind the Section 4

As far as I know the current Internet is not protected against
on-path attackers. To protect against them you either need ipsec,
SSL or even application specific tricks. 

The hidden idea behind the threat draft is "if we do not manage to
make a system more secured than the current Internet, at least we
must have a system that is not less secure."

> hard to secure and thus difficult to deploy?

I think that by taking care of how LISP is deployed and how
the features are used, it is possible to achieve the same level
of security than today. Doing more is possible, but I am not sure
that people are ready to have to deal with cryptography. For
example, if you want to protect against spoofing, you can sign
the packets (or part of) but then you need a way to know the key
used to sign.

Do you really want to go to that direction?

Damien Saucez

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Sep 2011 14:22:49 -0700

Hi Damien, 

> Sent: Thursday, September 15, 2011 12:53 PM
> To: Templin, Fred L
> Cc: [email-masked]

As far as I can tell, an on-path attacker can mount
a spoofing attack and be exempt from ingress filtering.
I think the same condition is true both in the current
day non-LISP Internet and in the (future) LISP Internet,
however LISP also needs to deal with both RLOC and EID
spoofing.

> SSL or even application specific tricks.

Right. 

> must have a system that is not less secure."

That's why I said: "But, perhaps a case can be made that
on-path attacks are no more a matter for concern for LISP
than they are for the non-LISP public Internet?".

Still, if an off-path attacker can spoof the EID source
address even if it cannot spoof the RLOC source address,
the end result is a system that is less secure than the
current Internet - right?

> Do you really want to go to that direction?

Do I really want to go in the direction of requiring
cryptography? I can't answer that unless you first
tell me the intended domain of applicability. I don't
think I have yet seen a use case analysis of the
various scenarios where LISP xTRs and mapping systems
would be deployed and used. There seems to be an
unspoken assumption of deployment "in the public
Internet", but what about Enterprise networks?
What about MANETs? What about aviation networks?
What about tactical military networks? What about
cellular networks? What about home networks?

My team has already taken a look at those and other
use cases, and we have shown our approach to be
broadly applicable:

http://www.rfc-editor.org/rfc/rfc6139.txt

We have also arguably already won the acronym
arms-race with IRON, RANGER, VET, SEAL and AERO.

Thanks - Fred

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 20 Sep 2011 09:30:38 +0200

Hi Fred,

On Sep 19, 2011, at 23:22 , Templin, Fred L wrote:

[snip]
> current Internet - right?

Can you explain why? 

I would say the contrary. If an attacker cannot spoof RLOC it means that the DFZ is more robust - right?

> cellular networks? What about home networks?

That is the purpose of the deployment document.

http://tools.ietf.org/html/draft-ietf-lisp-deployment-01

Luigi

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Sep 2011 08:21:38 -0700

Luigi,

I really, really hate trying to annotate things when people turn them
into html instead of leaving them as plaintext. But since you insist:

________________________________
From: Luigi Iannone [mailto:[email-masked]]
Sent: Tuesday, September 20, 2011 12:31 AM
To: Templin, Fred L
Cc: Damien Saucez; [email-masked]
Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR?

Hi Fred,

[snip]

Can you explain why?

Ingress filtering can prevent the spoofing of an RLOC, but not necessarily
the spoofing of an EID. If a middlebox produces packets that have correct
RLOCs but incorrect EIDs, and if the ETR accepts them, then a reflection
attack is enabled.

>From a brief look, that document appears to have quite a ways to
go until it considers a wider variety of use cases such as we have
addressed in RANGERS. The document also seems to carefully
step around the MTU issue, as if it were a booby trap to be always
on guard for. IRON (with SEAL) *solves* the MTU issue so that
there is no longer any need to worry about it. Until LISP truly
addresses the MTU issue (including accounting for the common
case of operators misconfiguring link MTUs) all LISP-related
documents will have to carefully dance around it.

Fred
[email-masked]<mailto:[email-masked]>

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 20 Sep 2011 19:06:14 +0200

Hi Fred, 

thanks for the effort….

About your middle box example, why this example is different any other reflection attack?

The middle box must be somewhere in the network so that its traffic is not filtered due to the use of a specific source RLOC.

But in that case you do not need LISP to carry out a reflection attack. Hence LISP does not introduce any security hole.

Or I misunderstand something?

Luigi

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 20 Sep 2011 13:25:21 -0400

I believe his point is that
1) We have a bunch of efforts to prevent spoofed source IP addresses 
(RLOCs) in the net today.  No tehy don't work perfectly, but we are 
working on improving them.  Assume for discussion they work.
2) In the pwesence of LISP, under a variety of circumstances, it is 
possible to get a packet with an apparently valid source RLOC (ITR IP 
address) but a false Source EID.
3) If this message is one which provokes a response, it can become an 
attack on the spoofed inner EID.  In particular, if the responses are 
noticeably large than the requests, it becomes an amplifying reflection 
attack.

I believe we already have some text noting this.  It is an unfortunate 
consequence of the system.  There are mechanisms that can be used to 
ameliorate this, and I would hope that part of the experiment will be to 
determine the relative costs and benefits of these mechanisms.

Yours,
Joel

On 9/20/2011 1:06 PM, Luigi Iannone wrote:
> The middle box must be somewhere in the network so that its traffic is
> not filtered due to the use of a specific source RLOC.
>
> But in that case you do not need LISP to carry out a reflection attack.
> Hence LISP does not introduce any security hole.
>
>>     *From:* Luigi Iannone [mailto:[email-masked]]
>>     *Sent:* Tuesday, September 20, 2011 12:31 AM
>>     *To:* Templin, Fred L
>>     *Cc:* Damien Saucez; [email-masked] <mailto:[email-masked]>
>>     *Subject:* Re: [lisp] Source address spoofing by a node pretending
>>     to be an ITR?
>>
>>     Hi Fred,
>>
>>     I would say the contrary. If an attacker cannot spoof RLOC it
>>     means that the DFZ is more robust - right?
>>
>> on guard for . IRON (with SEAL) *solves* the MTU issue so that
>> [email-masked] <mailto:[email-masked]>
>>
>>
>>     Luigi
>>
>
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Sep 2011 11:07:07 -0700

Hi Joel,

> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Tuesday, September 20, 2011 10:25 AM
> To: Luigi Iannone
> Cc: Templin, Fred L; [email-masked]

That's correct. And, depending on the links on the
path to the target a successful attack could truly
clog some arteries.

> determine the relative costs and benefits of these mechanisms.

OK. The IRON family already has a solution which may
or may not be adaptable for LISP. The IRON family also
has a solution for MTU, which again may of may not be
adaptable for LISP.

Thanks - Fred

> > thanks for the effort....
> >
> > About your middle box example, why this example is 
> different any other
> > reflection attack?
> >

---

From: Loránd Jakab <[email-masked]>
Date: Wed, 21 Sep 2011 16:49:52 +0200

Hi Fred,

On 09/20/11 17:21, Templin, Fred L wrote:
> addressed in RANGERS.

We know of other interesting use cases for LISP, but so far only
documented the ones related to DFZ size, to stay on the WG charter.

> The document also seems to carefully

The main spec discusses two possible solutions to MTU issues in Section
5.4. I think we need more experimentation with LISP to discuss it at
more detail in a deployment document (we do call attention to it at the
end of Section 2.1).

Best regards,
Lorand Jakab

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Sep 2011 14:22:14 -0700

Hi Lorand, 

> From: Loránd Jakab [mailto:[email-masked]] 
> Sent: Wednesday, September 21, 2011 7:50 AM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]

OK. It would be interesting to note the areas of
overlap and mutual exclusion between the LISP and
IRON domains of applicability.

> more detail in a deployment document (we do call attention to 

And also in Sections 2.2, 2.3, 2.4 and 2.6. That is
quite a bit of deliberation about MTU, and I think
goes to show the degree of uncertainty in the main
document's approach even before an experiment is
conducted.

So what makes more sense? To go forward with a
"slacker's" approach that is riddled with doubts
which might not even be satisfied through extensive
experimentation, or to adopt a lightweight mechanism
from IRON/SEAL that stands a good chance of erasing
all doubts? 

Thanks - Fred

---

From: Terry Manderson <[email-masked]>
Date: Wed, 21 Sep 2011 16:36:28 -0700

Hi Fred,

Working group co-chair safari jacket on.

> document's approach even before an experiment is

Surely that is why the LISP documents are moving forward as experimental. I
don't think anyone is deluded to think that all of the answers are provided,
and if they are - send them my way in Taipei for a chat. However in my read
of the documents every time I thought "What about ...?" there existed some
words to identify it as an issue for investigation or consideration during
experimental deployment.
Uncertainty is, I think, justifiable here.. To take an absolute stance that
any implementation is free from hazards is known well in the IETF as folly
(aside: yet many repeat the lesson).

> "slacker's" approach that is riddled with doubts

?? really? 

I appreciate that you have a strong opinion, although please omit subjective
nouns from your posts. I fail to see how that adds to the technical
discussion.

> from IRON/SEAL that stands a good chance of erasing

Cheers
Terry

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Sep 2011 18:30:03 -0700

> from IRON/SEAL that stands a good chance of erasing

There are no doubts or uncertainty. The text is written to satisfy all commenters, that is a compromise.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 22 Sep 2011 10:18:48 +0200

Hi,

On Sep 20, 2011, at 19:25 , Joel M. Halpern wrote:

> 1) We have a bunch of efforts to prevent spoofed source IP addresses (RLOCs) in the net today.  No tehy don't work perfectly, but we are working on improving them.  Assume for discussion they work.
> 2) In the pwesence of LISP, under a variety of circumstances, it is possible to get a packet with an apparently valid source RLOC (ITR IP address) but a false Source EID.
> 3) If this message is one which provokes a response, it can become an attack on the spoofed inner EID.  In particular, if the responses are noticeably large than the requests, it becomes an amplifying reflection attack.
> 

Yes I got the point. We have text in the threats draft for this.

However, my point was that similar attacks can be carried out without LISP, so I think that on this side LISP is not opening any new security threat.

Luigi

> I believe we already have some text noting this.  It is an unfortunate consequence of the system.  There are mechanisms that can be used to ameliorate this, and I would hope that part of the experiment will be to determine the relative costs and benefits of these mechanisms.
> 
> Yours,
> Joel
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Sep 2011 07:02:32 -0700

Terry,

> From: Terry Manderson [mailto:[email-masked]] 
> Sent: Wednesday, September 21, 2011 4:36 PM
> To: Templin, Fred L; Loránd Jakab
> Cc: [email-masked]; [email-masked]

If you want to censure me that's one thing, but
please don't put on articles of clothing that you
do not own. You have a hat. You do not have a big
game hunting license.

Fred
[email-masked],

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Sep 2011 07:05:42 -0700

Hi Luigi, 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Luigi Iannone
> Sent: Thursday, September 22, 2011 1:19 AM
> To: [email-masked]
> > 1) We have a bunch of efforts to prevent spoofed source IP 
> addresses (RLOCs) in the net today.  No tehy don't work 
> perfectly, but we are working on improving them.  Assume for 
> discussion they work.
> > 2) In the pwesence of LISP, under a variety of 
> circumstances, it is possible to get a packet with an 
> apparently valid source RLOC (ITR IP address) but a false Source EID.
> > 3) If this message is one which provokes a response, it can 
> become an attack on the spoofed inner EID.  In particular, if 
> the responses are noticeably large than the requests, it 
> becomes an amplifying reflection attack.
> > 
> 
> However, my point was that similar attacks can be carried out 
> without LISP, so I think that on this side LISP is not 
> opening any new security threat.

Yes it is; it allows off-path attackers to circumvent
ingress filtering of the inner address even if they
cannot circumvent ingress filtering of the outer address.

Fred

> Luigi
> 
> > I believe we already have some text noting this.  It is an 
> unfortunate consequence of the system.  There are mechanisms 
> that can be used to ameliorate this, and I would hope that 
> part of the experiment will be to determine the relative 
> costs and benefits of these mechanisms.
> > 
> > Yours,
> > Joel
> >