In the "stateless" case, having the LISP ITR return
packet-too-bigs with degenerate MTUs (i.e., MTUs less
than 1500) is going to leave source hosts with an
unsatisfactory experience that they would not incur
without an ITR/ETR in the middle.
Ah, then that motivates to upgrade MTUs.
In the stateful case, LISP relies on a brittle mechanism
that has known vulnerabilities (e.g., [RFC2923]) and can
easily be spoofed by off-path attackers.
Are you saying MTU Discovery is flawed?
RANGER/SEAL fixes both of these problems and much more.
With a lot more machinery and state. Let's not start this conversation
again.
Fine qualifications noted (I think). About the LISP
locator reachability bits, that seems like a lot of
overhead to carry on each and every packet, and it
4 bytes per packet? Sorry, I don't think so.
also seems to assume symmetric paths. RANGER assumes
unidirectional tunnels and path asymmetry, i.e., if
Site 1's packets use ITR A and go through ETR B at
Site 2, the return traffic could actually come through
Site 2's ITR C. In the LISP locator reachability case,
how does C know anything about the reachability of A?
It can send a Map-Request. But active-active on ingress and egress
will be the norm.
Although RANGER could send locator reachability bits
in control messages as an optimization, its primary
mechanism is through having the ITR probe the forward
path to the ITR. Probing is by setting an "ack request"
bit on every Nth data packet (+/- some delta if
randomization is desired) and then observing whether
a steady stream of ACKs comes back.
This doesn't work because if you are going to claim liveness through a
protocol, you have to send control packets all the time from M ITRs to
N ETRs. If you claim liveness, you have to do this before you send
packets. So putting the probe in data packets is not sufficient.
And if you send probes all the time from M ITRs to N ETRs, you have a
huge scaling problem.
LISP also doesn't seem to take into account that a multi-
homed site can partition, such that locator reachability
does not necessarily imply end system reachability via
specific locators. Nor does it provide a means for an ETR
(A) to inform the ITR of a better ETR (B) when paths get
stretched. RANGER has a means to accommodate this.
Can you state some disadvantages of RANGER? There is no such thing as
a free lunch, so your design has to make tradeoffs, but you seem to
never state them.
If we want to solve this problem, we could do this today by having a
host switch it's TCP connection to another A record. This doesn't
happen today because people deal with packet loss, since it doesn't
last long *and* rerouting actually works quite well.
Van Jacobson always made this comment and I'll never forget it, "The
fact that the Internet drops packets is it's greatest feature".
What else can either an xTR or TCP host do when sending ICMP
Unreachables are off by default in most modern routers, or they are
filtered by firewalls, and route aggregation hides failures close to
packet sources.
RANGER can listen for ICMP unreachables coming from network
middleboxes that it can verify as on-path by checking the
Non-starter, you will not get ICMP unreachables, period. So if you
solely depend on it, the solution is a non-starter.
SEAL_ID. In a RANGER world, network middleboxes would be
encouraged to turn the ICMPs back on because site border
xTRs will have a means to detect spoofing (i.e., the SEAL_ID).
But, this is an optimization only; nothing in RANGER depends
on getting the ICMPs from middleboxes.
You have to turn it on in all transit routers. You will get objection
to this. It will never happen and if you think it could possibly
happen, it will take forever.
Dino
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
