Dino,
o End-systems (hosts) only send to addresses which are EIDs. They
don't know addresses are EIDs versus RLOCs but assume packets get
to LISP routers, which in turn, deliver packets to the destination
the end-system has specified.
Is this always true, e.g, when some interworking mechanism between the LISP and
non-LISP parts of the Internet is in use, and one of the peers employs some NAT
traversal techniques? It would seem that there can be cases where the peers
observe RLOC addresses and use them for some purpose.
But they don't know they are RLOC addresses. All end-systems assume is that
addresses they put int destination address fields will make it to the
destination. So if the address is an RLOC, the underlying routing system will
have routes to get the packet to the destination. Otherwise, the packet moves
toward a LISP router that will encapsulate to get the packet to the destination.
That makes sense. Please consider if you want to modify the text somehow;
currently you are saying that hosts only send to EIDs. That is of course
normally the case, but other cases will also happen and the routing should
still work as expected. This is just a comment from me though, not a blocking
issue.
A server host can be the endpoint
of a LISP tunnel as well.
...
o RLOCs are always IP addresses assigned to routers
Isn't this an inconsistency? Or is a server that terminates a tunnel called a
router?
For the sake of this document and keeping it within the charter of the working
group, a router is a LISP router. We do not consider hosts doing LISP as
specified in the LISP-MN document. Which is out of charter for this working
group.
So if a server is acting as a router, then it has RLOCs.
Hosts have EIDs assigned to them (when they are resident in a LISP site), IGP
routers have EIDs assigned to them, and LISP routers have both EIDs and RLOCs
assigned to them.
OK
o When a router originates packets it may use as a source address
either an EID or RLOC.
You should state somewhere what the manageability requirements are for making
this happen, or if hardcoded policies are sufficient (e.g., iBGP vs. eBGP use
of addresses). Does this require additional functionality for RFC 3484 style
source address selection, or can you cope with existing functionality?
It does not. The same requirements for originating IP packets has not changed.
If it is stated that the outgoing interface's address is used as the source
address, then whatever namespace the address belongs to is used.
Note: I'm not asking for any new functionality, just a statement about the
expectations.
No expectations. ;-)
Fine. Can we state that? At least this reader was wondering if a router needed
something special to be handle the selection. I'm of course very glad that the
answer is no.
In order to avoid excessive packet overhead as well as possible
encapsulation loops, this document mandates that a maximum of two
LISP headers can be prepended to a packet.
This seems hard to mandate in any real sense. Perhaps you want to say "recommends"
instead of "mandates"?
We thought long and hard about this and wanted to mandate to indicate the
seriousness of not going overboard with encapsulation. Now I know implementors
can ignore specs, but for the record when it is documented the way we did it is
more clear on the strength of the statement.
OK
2. The LISP ITR must be able to map the EID destination to an RLOC
of one of the ETRs at the destination site. The specific method
used to do this is not described in this example. See
[ALT<http://tools.ietf.org/html/draft-ietf-lisp-15#ref-ALT>] or
[CONS<http://tools.ietf.org/html/draft-ietf-lisp-15#ref-CONS>] for
possible solutions.
3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be
rate-limited.
4. When an alternate mapping system is not in use, the Map-Request
packet is routed through the underlying routing system.
Otherwise, the Map-Request packet is routed on an alternate
logical topology. In either case, when the Map-Request arrives
at one of the ETRs at the destination site, it will process the
packet as a control message.
First, the the "alternate mapping system" appears here for the first time.
Maybe you should indicate it refers to [ALT].
But we have a long list of mapping systems, do you want all of them to be
listed?
Second, parts of step 4 go pretty deep in what the specific mapping methods
are. I'm wondering if this alternative text would fit better:
"4. The Map-Request packet is delivered to the right ETR with the help of the
mapping system. (For instance, in [ALT] this happens via an EID-based alternate routing
topology.) In any case, when the Map-Request arrives …"
Well it does not capture the fact that the Map-Request can be delivered via the
underlying routing system. I will add a refernece to ALT though from your first
comment.
OK
6. The ITR receives the Map-Reply message, parses the message (to
check for format validity) and stores the mapping information
from the packet. This information is stored in the ITR's EID-to-
RLOC mapping cache. Note that the map cache is an on-demand
cache. An ITR will manage its map cache in such a way that
optimizes for its resource constraints.
This is just a comment, but FWIW, I am not super happy about the way the
caching is an integral part of the specifications for LISP. Fundamentally, you
could have used two orthogonal tools for dealing with routing scalability: 1.
have only a subset of routers have to deal with EID routing (the xTRs) and 2.
Which is the way LISP is designed.
use caching for scaling these routers better. If we had done this, then we
would have had a very easy
Which is also the way LISP is designed.
So I am not following you.
answer to those who have criticized the caching approach over the years: it is
optional and up to the implementors to use or not. The first tool would still
have been a valid approach to make the Internet scale better, even if you never
did any caching.
The map-cache is only in the ITRs and PITRs as you described in point 1. And
with added stretch the ITRs and PITRs could have a default cache entry that
encapsulates to a set of ETRs which can hold more cache entries, and so on. If
one chose to deploy LISP in a hierarchical way.
This isn't a very urgent discussion because my comment was just that a comment.
No need for you to change anything in the document. But I am still curious if
you could implement a LISP router that simply held the entire mapping database
and did not use any caching. But lets take the answer to that in some other
thread to save time for moving the document forward...
8. The ETR receives these packets directly (since the destination
address is one of its assigned IP addresses), strips the LISP
header and forwards the packets to the attached destination host.
Spoofing of inner header addresses of LISP encapsulated packets is
possible like with any tunneling mechanism. ITRs MUST verify the
source address of a packet to be an EID that belongs to the site's
EID-prefix range prior to encapsulation. An ETR must only
decapsulate and forward datagrams with an inner header destination
that matches one of its EID-prefix ranges. If, upon receipt and
decapsulation, the destination EID of a datagram does not match one
of the ETR's configured EID-prefixes, the ETR MUST drop the
datragram. If a LISP encapsulated packet arrives at an ETR, it MAY
compare the inner header source EID address and the outer header
source RLOC address with the mapping that exists in the mapping
database. Then when spoofing attacks occur, the outer header source
RLOC address can be used to trace back the attack to the source site,
using existing operational tools.
First, I think Step 8 should be slightly edited to cover the fact that some additional
checks are being made. E.g., "The ETR receives these packets directly (since ...),
checks the validity of the addresses used in the packet, strips the LISP header and
…"
I will add "checks the validity of the addresses" and of course keep the text
that follows Step 8.
Thanks.
Second, I wish you would have specified the source address checks better. Are
there situations where you would NOT want to make a pretty strict test, i.e.,
that source EID maps to source RLOC?
Because this is work still in progress.
I understand that, but accepting tunnel packets without this validation just
seems pretty open to attacks. And this is not just about LISP. In general,
every IETF technique that comes out may have vulnerabilities that cause trouble
not just for that technology but also for other things in the Internet. I'm
worried that this coyld be an attack vector to attack other things in the
Internet in the future. Can we agree on a middle ground, e.g., make the MAY a
SHOULD? I'd be much happier with that...
The next sub-sections illustrate packet formats for the
homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4
combinations SHOULD be supported.
For interoperability, wouldn't it be cleaner to have a MUST here? How would I
otherwise know if I can send an IPv4-in-IPv6 packet to a destination?
I can change to MUST.
Thanks.
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
