I have reviewed this document.
In general, it is well written and almost ready to go forward. There are a
couple of areas that need further text, however. The main issue is a clear
description of the to-experiment and problematic areas of LISP interworking.
(Making those is also needed in order to get the document approved, based on
experience of taking the other Lisp documents to the IESG.) Another issue is
that I think the security considerations text needs work.
In moder detail:
Technical issue: As with the other documents from the group, Section 1 should
include a high-level explanation of what issues are uncertain, potentially
problematic, or worth experimenting on. For instance, I presume you should say
something about the effects of having to NAT traffic, finding deployment
motivations to set up proxy ITRs, possible inclusion of too much non-aggregated
EID space in the DFZ, effects of the asymmetric PITR routing, and so on.
Please suggest text.
An ITR can also know explicitly that the
destination is non-LISP if the destination IP address matches a
Negative Map Reply found in its Map Cache.
Technical issue: This is normally the case, but the text seems to avoid going
into the details that I think are relevant in this case. The base spec says
There are two primary applications for
Negative Map-Replies. The first is for a Map-Resolver to instruct an
ITR or PITR when a destination is for a LISP site versus a non-LISP
site. And the other is to source quench Map-Requests which are sent
for non-allocated EIDs.
and
The actions defined are used by an ITR or PITR when a
destination EID matches a negative mapping cache entry.
Unassigned values should cause a map-cache entry to be created
and, when packets match this negative cache entry, they will be
dropped. The current assigned values are:
(0) No-Action: The map-cache is kept alive and no packet
encapsulation occurs.
(1) Natively-Forward: The packet is not encapsulated or dropped
but natively forwarded.
(2) Send-Map-Request: The packet invokes sending a Map-Request.
(3) Drop: A packet that matches this map-cache entry is dropped.
An ICMP Unreachable message SHOULD be sent.
That is, first of all there are other situations for which negative map cache
entries are used (but it is probably fine to route to the Internet in those
cases). Secondly, there are some controls on whether native forwarding is the
appropriate action.
Can you add a note about these and/or reformulate the text a bit?
3. In either of the two exceptions mentioned above there could be
Editorial issue: I was unsure what "the two exceptions mentioned above" refer to. Also, your list
starts with "This can be achieved by using one of two mechanisms:", so it is odd to find three
items in the list. I would suggest making this paragraph a regular paragraph and not a numbered item, and
starting it with "In either of the two mechanisms listed above there could be ...".
5. Proxy Ingress Tunnel Routers
Editorial issue: It may be too obvious perhaps, but I think this section should
state up front that highly aggregated EID space advertisement implies an entity
that routes on the behalf of many LISP sites.
240.0.0.0/24. For the purposes of this example, this prefix and no
Editorial issue: Is there a reason why we are using 240 addresses as examples?
I'd prefer using normal example addresses or 10/8 addresses if you need shorter
prefixes...
For the purposes of this example, this prefix and no
covering aggregate is present in the global routing system.
Editorial issue: Shouldn't this be "... neither this prefix or any covering
aggregate are present ...". The way that you have written it now had me confused for
a moment, thinking that this prefix is present but no covering prefix is present. I don't
think that is what you mean.
6 <http://tools.ietf.org/html/draft-ietf-lisp-interworking-02#section-6>.
LISP-NAT
Technical issue: Section 6 should probably point to some BEHAVE WG RFCs on how
the NAT operation should technically work.
An example of this translation follows. For this example, a site has
been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize
LISP-NAT, the site has also been provided the PA EID of
128.200.1.0/24, and uses the first address (128.200.1.1) as the
site's RLOC. The rest of this PA space (128.200.1.2 to
128.200.1.254) is used as a translation pool for this site's hosts
who need to send packets to non-LISP hosts.
Editorial issue: Please use the officially allocated example addresses.
6.4
<http://tools.ietf.org/html/draft-ietf-lisp-interworking-02#section-6.4>.
LISP-NAT and multiple EIDs
When a site has two addresses that a host might use for global
reachability, care must be chosen on which EID is found in DNS. For
example, whether applications such as DNS use the LISP-R EID or the
LISP-NR EID. This problem exists for NAT in general, but the
specific issue described above is unique to LISP. Using PITRs can
mitigate this problem, since the LISP-NR EID can be reached in all
cases.
Technical issue: but if you had a PITR, you would not need LISP-NAT, or am I
missing something?
6.5
<http://tools.ietf.org/html/draft-ietf-lisp-interworking-02#section-6.5>. When
LISP-NAT and PITRs used by the same LISP Site
With LISP-NAT, there are two EIDs possible for a given host, the
LISP-R EID and the LISP-NR EID. When a site has two addresses that a
host might use for global reachability, name-to-address directories
may need to be modified.
This problem, global vs. local addressability, exists for NAT in
general, but the specific issue described above is unique to
location/identity separation schemes. Some of these have suggested
running a separate DNS instance for new types of EIDs. This solves
the problem but introduces complexity for the site. Alternatively,
using PITRs can mitigate this problem, because the LISP-NR EID can be
reached in all cases.
Editorial issue: what's the difference between Sections 6.4 and 6.5? It seems
that they both talk about the problem of two addresses in a name mapping system.
Technical issue: I don't think "introduces complexity for the site" begins to
explain the type of problems caused by having to separate naming systems from each other.
Please expand or otherwise highlight that this approach is problematic.
8 <http://tools.ietf.org/html/draft-ietf-lisp-interworking-02#section-8>.
Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs)
In summary, there are three mechanisms for interworking LISP with
non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT option the
LISP site can manage and control the interworking on its own. In the
PITR case, the site is not required to manage the advertisement of
it's EID prefix into the DFZ, with the cost of potentially adding
stretch to the connections of non-LISP sites sending packets to the
LISP site. The third option is Proxy-ETRs, which are optionally used
by sites relying on PITRs case to mitigate two caveats for LISP sites
sending packets to non-LISP sites. This means Proxy-ETRs are not
usually expected to be deployed by themselves, rather they will be
used to assist LISP-NR sites which are already using PITRs.
Technical issue: This paragraph and Setion 8 in general would greatly from a
discussion of the tradeoffs involved in these three mechanisms. Just one
downside, stretch, is mentioned above. But I think there are others... impacts
to naming systems, asymmetric traffic, etc. Please expand.
9. Security Considerations
Technical issue: This section seems a bit thin. I'd love to see a discussion of
the following additional issues:
Implications to firewalls? Are there any? What about asymmetric routing?
Are there Denial-of-service attacks on PITRs and PETRs?
Are there DNSSEC implications on the naming system implications?
Like any router or LISP ITR, PITRs will have the opportunity to
inspect traffic at the time that they encapsulate. The location of
these devices in the network can have implications for discarding
malicious traffic on behalf of ETRs which request this behavior (via
the drop action bit in Map-Reply packets for an EID or EID prefix).
You should also talk about these devices being trusted to route your traffic to
begin with, and how both non-Lisp and Lisp networks should be careful in not
peering with untrustworthy networks. This is very similar to, say, peering with
someone who says they can reach everything in the Internet but in reality their
quality or security leaves something to be desired.
(Of course, all additions to the security considerations text could be pointers
elsewhere, if the issues have already been noted in other documents.)
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
