Subject: Re: [lisp] AD review of draft-ietf-lisp-interworking

From: Darrel Lewis <[email-masked]>
Date: Fri, 3 Feb 2012 10:21:37 -0800

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.

> 
>> 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).

> 
>>    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.

> .

>> 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.

> 
>> 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.

> 
> 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.

> 
> 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.

> 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).

> 
> (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!

-Darrel, on behalf of the other LISP-Interworking authors.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 03 Feb 2012 13:35:55 -0500

I am a bit concerned that the description of the cases does not work.
In particular, if I am reading the text (preserved below) properly, it 
says that the ITR can use the presence of a covering prefix in the 
regular BGP table to tell that a destination is a non-LISP destination.
But in order for interworking to function, all LISP EIDs must fall into 
prefixes which are advertised into the regular BGP routing table by 
PITRs somewhere.  As such, it seems that decision process 1 below would 
be counter-productive, sending all LISP-LISP traffic through PITRs.

Since I know that what I am inferring is not what you intend, we need 
better text please.

Yours,
Joel

---

From: Darrel Lewis <[email-masked]>
Date: Fri, 3 Feb 2012 12:10:54 -0800

On Feb 3, 2012, at 10:35 AM, Joel M. Halpern wrote:

> In particular, if I am reading the text (preserved below) properly, it says that the ITR can use the presence of a covering prefix in the regular BGP table to tell that a destination is a non-LISP destination.
> But in order for interworking to function, all LISP EIDs must fall into prefixes which are advertised into the regular BGP routing table by PITRs somewhere.  As such, it seems that decision process 1 below would be counter-productive, sending all LISP-LISP traffic through PITRs.
> 
> Since I know that what I am inferring is not what you intend, we need better text please.
> 

Good point Joel, I think the text confuses the issue.  At this point the right way for a device to determine if the destination is LISP is to _look into the mapping system_  not the DFZ. How about simply removing the first numbered bullet, and adjusting the text?

I also noticed that I didn't provide in response to Jari on Section 8.  (though i right now I am at a loss for exactly what text to include I will think about it. and reply this weekend.

-D

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 03 Feb 2012 15:14:22 -0500

Removing option 1 would solve my concern very nicely.   Thanks.
Joel

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Feb 2012 16:43:26 +0200

>     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.)

>     These situations are reviewed in section 7, (Proxy-Egress Tunnel Routers).

OK

> Fixed. See above, I believe this is addressed in the suggested text.

OK

> I have changed the documentation prefixes, I think we do not need shorter prefixes in these examples.

Thanks.

>>>     6<http://tools.ietf.org/html/draft-ietf-lisp-interworking-02#section-6>. LISP-NAT
>>>
>>>
>>>
>>>       6.4<http://tools.ietf.org/html/draft-ietf-lisp-interworking-02#section-6.4>. LISP-NAT and multiple EIDs
>>>
>>>
>>>
>>>       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
>>>
>>>
>>>
>>>     8<http://tools.ietf.org/html/draft-ietf-lisp-interworking-02#section-8>. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs)
>>>
>>>
>>>

What you say above would also be good text to add, IMO. That is, lack of an impact is also useful information.

>  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 t…

OK

> 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

>     sites to the Proxy-ETR (thus ensuring the outer IP source address is

Good. Thanks.

> Thanks again for your careful review!

Thanks,

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Feb 2012 16:44:02 +0200

That also works for me.

Jari

---

From: Darrel Lewis <[email-masked]>
Date: Mon, 6 Feb 2012 08:45:38 -0800

> Some duplication above ("of Proxy ....")

Ack.

> (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 l…

I'm fine with this text Jari, consider it changed.

<snip>

> What you say above would also be good text to add, IMO. That is, lack of an impact is also useful information.

Ok thanks for the guidance will suggest text for you here. It seems like we are in agreement.  I will make these changes and post the -03 version.

-Darrel

---

From: Terry Manderson <[email-masked]>
Date: Tue, 7 Feb 2012 15:36:47 -0800

Thanks Dino!

T.

On 7/02/12 2:45 AM, "Darrel Lewis" <[email-masked]> wrote:

>>> Sorry for taking so long to respond to your review.  Please find suggested
>>> text below as well as a proposed -03 draft attached.
>>> 
>>>> 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.
>> "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.)
> 
>>>> Technical issue: This section seems a bit thin. I'd love to see a
>>>> discussion of the following additional issues:
>>>> 
>>> 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.
>> 
> Ok thanks for the guidance will suggest text for you here. It seems like we
> are in agreement.  I will make these changes and post the -03 version.
> 
> -Darrel
> 
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Terry Manderson <[email-masked]>
Date: Tue, 7 Feb 2012 15:39:25 -0800

Sigh..

"Thanks Darrel" dammit. :-(

Long night/early morning.

Sorry.
T.

On 8/02/12 9:36 AM, "Terry" <[email-masked]> wrote:

>>>>    originated by these Proxy Tunnel Routers into the Internet's Default
>>>> Free 
>>>> Zone,

---

From: Darrel Lewis <[email-masked]>
Date: Wed, 8 Feb 2012 05:50:13 -0800

I have updated the draft to address the comments received in this thread, and posted the -03 version.

draft-03 and diffs from 02 attached.

Thanks again for the careful review and constructive comments!

-Darrel