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:
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
On Sep 20, 2011, at 17:21 , Templin, Fred L wrote:
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 protected]]
*Sent:* Tuesday, September 20, 2011 12:31 AM
*To:* Templin, Fred L
*Cc:* Damien Saucez; [email protected] <mailto:[email protected]>
*Subject:* Re: [lisp] Source address spoofing by a node pretending
to be an ITR?
Hi Fred,
On Sep 19, 2011, at 23:22 , Templin, Fred L wrote:
[snip]
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?
Can you explain why?
I would say the contrary. If an attacker cannot spoof RLOC it
means that the DFZ is more robust - right?
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.
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?
That is the purpose of the deployment document.
http://tools.ietf.org/html/draft-ietf-lisp-deployment-01
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 protected] <mailto:[email protected]>
Luigi
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
