Re: [lisp] Source address spoofing by a node pretending to be an ITR?

["Templin, Fred L" <[e-mail]>]

Hi Damien, 

> -----Original Message-----
> From: Damien Saucez [mailto:[e-mail]] 
> Sent: Thursday, September 15, 2011 12:53 PM
> To: Templin, Fred L
> Cc: [e-mail]
> Subject: Re: [lisp] Source address spoofing by a node 
> pretending to be an ITR?
> 
> Hello Fred,
> 
> On 14 Sep 2011, at 17:18, Templin, Fred L wrote:
> 
> > Hi Damien, 
> > 
> >> -----Original Message-----
> >> From: Damien Saucez [mailto:[e-mail]] 
> >> Sent: Wednesday, September 14, 2011 11:07 AM
> >> To: Templin, Fred L
> >> Cc: [e-mail]
> >> Subject: Re: [lisp] Source address spoofing by a node 
> >> pretending to be an ITR?
> >> 
> >> 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.
> > 
> > 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?
> 
> 
> 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.

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.

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

Right. 

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

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?

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

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
[e-mail]

> Damien Saucez
> 
> > 
> > Thanks - Fred
> > 
> >> Regards,
> >> 
> >> Damien Saucez
> >> 
> >> On 14 Sep 2011, at 10:15, Templin, Fred L wrote:
> >> 
> >>> 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
> >> 
> >>> ity. 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
> >>> [e-mail]
> >>> _______________________________________________
> >>> lisp mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/lisp
> >> 
> 
>