On 03.02.2012 20:21, Darrel Lewis wrote:
Jari,
Sorry for taking so long to respond to your review. Please find suggested text
below as well as a proposed -03 draft attached.
On Jan 2, 2012, at 1:27 AM, Jari Arkko wrote:
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.
I suggest adding the following paragraph to the end of the Introduction
(Section 1).
Several areas concerning the Interworking of LISP and non-LISP sites remain
open
for further study. These areas include an examination the impact of
LISP-NAT on
internet traffic and applications, understanding the deployment motivations
for
the deployment and operation of Proxy Tunnel Routers, the impact of EID
routes
originated by these Proxy Tunnel Routers into the Internet's Default Free
Zone,
and the effects of Proxy Tunnel Routers on internet traffic and
applications.
of Proxy Tunnel Routers on internet traffic and applications. This
analysis will
explain what role Proxy Tunnel Routers and NAT will play in the expected
ongoing
presence of both LISP and non-LISP sites in the Internet.
Some duplication above ("of Proxy ....")
I like the beginning part, but I would replace the last sentence with:
"Until these issues are fully understood, it is possible that the interworking
mechanisms described in this document are hard to deploy, or may have unintended
consequences to applications."
(I think that is a true statement. And I'm not trying to be negative, but from
processing the other docs in the IESG, it is clear that we cannot get the
documents approved without safety warnings like this.)
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?
Yes this is a good suggestion. Interworking pre-dated negative map-replies so
the text hear isn't as clear as it should be. How about:
In case 3, LISP site to Non-LISP site, a LISP site can (in most
cases) send packets to a non-LISP site because the non-LISP site
prefixes are routable. The non-LISP site need not do anything new to
receive packets. The only action the LISP site needs to take is
to know when not to LISP-encapsulate packets. This can be achieved
by using one of two mechanisms:
1. At the ITR in the source site, if the destination of an IP packet
is found to match a prefix from the BGP routing table, then the
site is directly reachable by the BGP core as it exists and
operates today.
2. An ITR knows explicitly that the destination is non-LISP if the
destination IP address of an IP packet matches a (negative)
Map-Cache entry which has the action 'Natively-Forward'.
There are some situations where (un-encapsulated) packets originated by a
LISP site may not get forwarded successfully to a non-LISP site.
These situations are reviewed in section 7, (Proxy-Egress Tunnel Routers).
OK
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 …"
Fixed. See above, I believe this is addressed in the suggested text.
OK
.
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…
I have changed the documentation prefixes, I think we do not need shorter
prefixes in these examples.
Thanks.
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.
Yes good catch, fixed.
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.
Ok I will added
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.
Fixed.
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?
I agree (which you below) that Section 6.4 is redundant with 6.5, since 6.5 is
more clearer and more complete and I suggest keeping it and removing the above.
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.
I agree that the problems here deserve further highlighting. I suggest adding
the following changes to section 6.5.
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.
I
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?
I don't now of any implications to firewalls, asymmetric routing is problematic
for any multi-homed site and its my belief that LISP-Interworking has no impact
on this beyond what LISP introduces with multihoming. That is, if you
multi-home today (with LISP or BGP) you get the possibility of asymmetric
flows. Interworking's schemes, by themselves, don't seem to me to change that.
However, if you can suggest some specific examples to guide this discussion
I'll be happy to produce some text, I just can't think of anything right now.
What you say above would also be good text to add, IMO. That is, lack of an
impact is also useful information.
Are there Denial-of-service attacks on PITRs and PETRs?
From the perspective of general Interworking, this is no different than ITRs
or ETRs, as far as I can see. The LISP Deployment draft might benefit from
some discussion here (due to placement in the network topology etc). Based on
your note below I will add a reference to the base spec for this.
OK
Are there DNSSEC implications on the naming system implications?
None that I can see, since with LISP-NAT both LISP-R and LISP-NR addresses
'belong' to the same site. (but again if you have some specific guidance here
I am open to suggestions).
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.
Ok adding some text here. Note that the Deployment draft goes into some more
detail about Originating EID-Routes and the impact of SIDR on PITRs.
OK
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.
yes good point, and this is unique to interworking (though I can see an analogy
to selecting a mapping service provider)
How about this text for the security considerations section:
Like any router or LISP ITR, Proxy ITRs 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).
This is an area that would benefit from further experimentation and
analysis.
Proxy-ITRs and Proxy-ETRs will likely be operated by organizations
other than those of the end site receiving or sending traffic. Care
should be taken, then, in selecting a Proxy-ITR/Proxy-ETR provider
to insure the quality of service meets the site's expectations.
Proxy-ITRs and Proxy ETRs share many of the same security issues
discussed of ITRs and ETRs. For further information, see the
security considerations section of [LISP].
As with traditional NAT, LISP-NAT will obscure the actual host
LISP-NR EID behind the LISP-R addresses used as the NAT pool.
When LISP sites send packets to non-LISP sites (these non-LISP sites
rely on PITRs to enable Interworking), packets will have the Site's
EID as its source IP address. These EIDs may not be recognized by
their Internet Service Provider's Unicast Reverse Path Forwarding
(uRPF) rules enabled on the Provider Edge Router. Several options
are available to the service provider. For example they could enable
a less strict version of uRPF, where they only look for the existence
of the EID prefix in the routing table. Another, more secure, option
is to add a static route for the customer on the PE router, but not
redistribute this route into the provider's routing table. Finally,
Proxy-ETRs can enable LISP sites to bypass this uRPF check by
encapsulating all of their egressing traffic destined to non-LISP
sites to the Proxy-ETR (thus ensuring the outer IP source address is
the site's RLOC).
Good. Thanks.
(Of course, all additions to the security considerations text could be pointers
elsewhere, if the issues have already been noted in other documents.)
Right I can point to [LISP] for the cases where Proxy-ITRs and Proxy-ETRs are
similar to ITRs and ETRs.
Thanks again for your careful review!
Thanks,
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
