I will repeat myself.
Can we PLEASE not get into debating how we would solve the weakness in
the protocol as documented.
The question focus on is whether the protocol as specified has the
behavior described, and if so does it result in the weakness described.
If it does, that should be described in the threats document.
if not, then it should not be so described.
The presence, absence, validity, or possibility of solutions in other
documents, operational practices, or people's heads, are not the topic
for the WG at this time.
PLEASE stay on topic, or we will never get our current work done.
Which means that peoples wonderful ideas on how to do more or better
will never get publsihed.
Yours,
Joel
On 6/12/14, 11:24 AM, Dino Farinacci wrote:
Could you describe precisely the attack you have in mind? The only
think I can see is relying on the birthday paradox but that is a
completely different story.
If an attacker is on-path it could see the nonce's (assuming that the LISP
header is not encrypted, regardless of whether the data packet is encrypted).
This could be an issue if the attacker is physically on-path.
The source EID is encrypted so it can only see a cleartext source RLOC and
can't associated it with anything.
When we merge lisp-cryto logic with echo-noncing, one has to determine if an
xTR should participate in echo-noncing if the payload is not decrypted
properly. That is, if I get a echoed nonce back from an attacker for a nonce I
know I have sent and set the E-bit, and I cannot decrypt the payload that comes
from the attacker, then I don't believe any NEW reachability information about
the RLOC.
This could also be an issue for attackers which are physically off-path if
gleaning is used, since an attacker could use a gleaning attack to temporarily
insert itself on-path, which in turn would allow it to see the nonce.
So by now we know there are many issues with gleaning. So we should document
them and say they shouldn't be used for the general global Internet use-case.
Dino
Ross
-----Original Message-----
From: lisp [mailto:[email protected]] On Behalf Of Damien Saucez
Sent: Thursday, June 12, 2014 8:08 AM
To: Ronald Bonica
Cc: LISP mailing list list
Subject: Re: [lisp] Restarting last call on LISP threats
Hello,
I am not sure I understand exactly what you are proposing. How can a
LISP router decide that a RLOC is done by simply receiving an ICMP
packet from an attacker (except with LSB that is discussed in Sec
4.3.2.1. )? All the other techniques are triggered by the LISP
router and are protected by the nonce.
Could you describe precisely the attack you have in mind? The only
think I can see is relying on the birthday paradox but that is a
completely different story.
Damien Saucez
On 10 Jun 2014, at 21:37, Ronald Bonica <[email protected]> wrote:
Dino,
Exactly! So, assume the following:
- LISP is deployed on the global Internet
- An RLOC is mapped to some number of EID prefixes
- For a subset of those EID prefixes, the above mentioned RLOC is preferred
- An ITR receives a hint indicating that the RLOC is down (either through a
LISP data packet or an ICMP message)
The ITR will verify RLOC reachability (possibly by polling the RLOC). But until
the ITR has receives a response to its poll, how should it behave? Should it
continue sending traffic though the above mentioned RLOC? Or should it begin to
send traffic through another RLOC, if one exists? I don't see a normative
recommendation.
However, both behaviors have their drawbacks and could be vectors for attack.
Ron
-----Original Message-----
From: Dino Farinacci [mailto:[email protected]]
Sent: Tuesday, June 10, 2014 1:23 PM
To: Ronald Bonica
Cc: LISP mailing list list
Subject: Re: [lisp] Restarting last call on LISP threats
As I keep saying Ron, you need to verify anything you intend to glean. The
spec says the gleaning is "a hint" and not gospel.
Dino
On Jun 10, 2014, at 10:06 AM, Ronald Bonica <[email protected]> wrote:
Hi Dino,
Given that the LISP data packet or ICMP packet may be from an attacker, is
it even safe to glean that? I think not.
Ron
-----Original Message-----
From: Dino Farinacci [mailto:[email protected]]
Sent: Tuesday, June 10, 2014 1:04 PM
To: Ronald Bonica
Cc: LISP mailing list list
Subject: Re: [lisp] Restarting last call on LISP threats
On Jun 10, 2014, at 9:57 AM, Ronald Bonica <[email protected]> wrote:
Earlier in this thread, we agreed that when LISP is deployed on the
global
Internet, mapping information cannot be gleaned safely from incoming
LISP data packets. Following that train of thought, when LISP is
deployed on the global Internet, is it safe to glean routing locator
reachability information from incoming LISP data packets as described
in RFC 6830, Section 6.3, bullet 1. If not, I think that we need to mention
this in the threats document.
What you can glean is that the source RLOC is up, but you cannot
glean your path to it is reachable.
Given that ICMP packets are easily spoofed, when LISP is deployed on
the
global Internet, is it safe to glean routing locator reachability
information from incoming ICMP packets as described in RFC 6830,
Section 6.3, bullet 2 and bullet 4. If not, I think that we need to
mention this in the threats document.
What you can glean is that the source RLOC is up, but you cannot
glean your path to it is reachable.
Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
