Re: [RTG-DIR] draft-ietf-lisp-06.txt

[Ron Bonica <[e-mail]>]

Hi Vince,

Responses inline....

Vince Fuller wrote:
> Hello Ron-
> 
> Thanks for the feedback. The LISP authors appreciate the opportunity to
> improve the qualify of our documents.
> 
> I'll respond to each of the comments in turn.
> 
>> Major Issues:
>>
>> o Architectural Issues
>>
>> - Tunnel Liveness - The document says little about what happens when a
>> tunnel connecting iTR to eTR fails? Does temporary black-holing result?
>> What is the restoration mechanism?
> 
> Please re-read section 6.3, titled titled "Routing Locator Reachability"
> which covers maintenance of ITR to ETR state.

I can think of situations in which none of the mechanisms described in
6.3 would kick in in a timely manner. For example, assume that there is
a five-hop path between the iTR and eTR. The path is working just fine,
until somebody configures an ACL on hop 3 that silently discards packets.

Which protection kicks in and how long does it take?
> 
> While LISP does perform encapsulation and is thus conceptually a tunneling
> protocol (hence the terms "Ingress Tunnel Router" and "Egress Tunnel Router",
> there is no explicit tunnel state so your question should perhaps be re-
> phrased as "what happens when an ITR loses connectivity to an ETR RLOC?".

I think that I understand what happens when the iTR realizes that it has
lost connectivity to the eTR. My question is, does the iTR reliably
realize this in a timely manner.


> 
>> - UDP Checksum - When an iTR formats the LISP UDP header, it sets the
>> UDP checksum to zero. This is in violation of RFC 768.
> 
> RFC 768 does not prohibit zero IP UDP checksums, which are in common use by 
> a number of protocols (NFS comes to mind), so this comment would seem to be
> in error. There are open issues with zero UDP checksums for ipv6, but not
> only are those issues beyond the scope of RFC 768 (which predates ipv6 by
> many years) but they also affect a number of other protocols other than LISP
> (AMT et al) and are being discussed in a larger context (MBONED, et al.
> 
> Please see Joel Halpern's recent message on this topic fo the [e-mail]
> mailing list.

I stand corrected and would like to repeat Joel's question regarding UDP
checksums and IPv6.

> 
>> - The document should say something about cases in which NATs and middle
>> boxes are deployed between iTR and ETR. Will those boxes continue to work?
> 
> This is an implementation and configuration issue and is beyond the scope
> of this protocol description. Testing on our pilot network has verified that
> LISP works through NAT boxes, though how that is configured is implementation-
> specific.
> 
> This topic will also be the topic of a forthcoming LISP Deployment document
> that has been discussed on the [e-mail]. The Interworking draft also
> has some descriptive text regarding NAT and LISP.

If another document is coming, I can accept that.
> 
>> o Caching Issues
>>
>> - The caching policy is not well specified. Therefore, I am worried that
>> the cache might become an easy target for DoS attacks. Consider the
>> following scenario:
>>
>> An opponent discovers the EIDs of 100 hosts behind an ITR. The opponent
>> then sends a steady stream of 50 pps to each of those 100 hosts. Each of
>> those packets has a unique, valid and spoofed source address. Each
>> packet also causes its recipient to send an ICMP port unreachable
>> message to the spoofed source. The ITR cache may be overrun.
> 
> This is an implementation issue that is beyond the scope of this protocol
> specification. Other common protocols, including ARP and DNS, have similar
> vulnerabilities and Well-known rate-limiting and other mechanisms exist for
> ameliorating the damage caused by such cache-pollution attacks. LISP
> implementations would be advised to incorporate such mechanisms.

I don't think that this response is acceptable. The scaling requirements
of the lisp cache are very different from those of ARP and DNS. So are
the consequences of cache overrun.

In order to demonstrate that this experiment doesn't present a risk to
the Internet, I would discuss this topic in more depth.
> 
>> o Migration issues Considerations
>>
>> - During the migration period, when an ITR receives a packet, it must
>> determine whether that packet's destination address is an EID or an
>> RLOC. The document isn't clear about how the ITR does this. One
>> possibility is to encode that information in the IP address. Another is
>> to query the network to find out. While the first solution may work for
>> IPv6, it won't work well for IPv4. The second solution presents
>> performance problems regardless of IP version.
> 
> This is an interworking issue and is beyond the scope of this protocol
> implementation.
> 
> Please refer to the LISP Map Server specification for discussion of how
> an ITR determines whether a destination IP address is an EID or a legacy,
> non-LISP address. The LISP+ALT specification also documents how the EID-to-
> RLOC database is used to make this determination and the LISP Interworking
> covers, in detail, the mechanisms for LISP and non-LISP sites to
> communicate.

ok

> 
>> - LISP's goals are best achieved when the entire Internet is surrounded
>> by xTRs (i.e., at the end of migration). However, it is impossible to
>> know when that state has been achieved. The document should say
>> something about when an operator has completed its migration effort and
>> what benefit it can expect to reap at that time.
> 
> This comment would seem to be beyond the scope of this protocol specification.
> Not only does LISP offer a long-term strategy for reducing the growth of
> global Internet routing state but it also offers short-term benefits for
> early adopters, including simplar site multihoming that also offers new
> traffic engineering capabilities.
> 
> Migration would also seem to be a central topic of a future LISP Deployment
> document. 

OK. If another document is coming, that's fine.
> 
>> Minor Issues
>>
>> - Terminology section defines many terms that are already commonly
>> understood.
> 
> Given how much confusion has persisted on the RRG and [e-mail]
> mailing lists about such "commonly understood" terms as "Endpoint ID"
> and "Locator", the LISP authors decided to err on the side of redundancy
> in defining terms.
> 
>> Nits:
>>
>>
>>   == You're using the IETF Trust Provisions' Section 6.b License Notice from
>>      12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
>>      http://trustee.ietf.org/license-info/)
> 
> This should be automatically fixed when the xml2rfc template is updated.
> 
>>   ** The document seems to lack an IANA Considerations section.
> 
> I don't believe this document is asking for any new IANA assignments since
> LISP already has the protocol identifiers (UDP port numbers) that it needs.
> 
>>   ** There are 5 instances of lines with non-RFC2606-compliant FQDNs in
>> the document.
> 
> Can you please list the specific errors so that we can fix them?

I have no idea what the errors were. This list was generated by the
automated tool.


> 
>>   == There are 10 instances of lines with private range IPv4 addresses
>> in the document.  If these are generic example addresses, they should be
>> changed to use any of the ranges defined in RFC3330 (or successor):
>> 192.0.2.x, 198.51.100.x or 203.0.113.x.
> 
> Unfortunately, RFC3330 space is too small to use for some of the examples
> contained in the LISP documents (LISP+ALT suffers from this nit as well).
> For this reason, we have chosen to use RFC1918 space in our examples.
> 
>>   Miscellaneous warnings:
>>
>> ----------------------------------------------------------------------------
>>
>>   == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
>>      or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
>>      use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
>>      mean).
> 
> Can you please list the specific errors so that we can fix them?
>>      Found 'MUST not' in this paragraph:
>>
>>      LCM:   The format is one of the control message formats described
>>      in this section.  At this time, only Map-Request messages and PIM
>>      Join-Prune messages [MLISP] are allowed to be encapsulated.
>>      Encapsulating
>>      other types of LISP control messages are for further study.  When
>>      Map-Requests are sent for RLOC-probing purposes (i.e the P-bit is set),
>>      they MUST not be sent inside Encapsulated Control Messages.
> 
> We will fix this, thanks.
> 
>>   Checking references for intended status: Experimental
>>
>> ----------------------------------------------------------------------------
>>
>>   ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
>>
>>   == Outdated reference: A later version (-02) exists of draft-jen-apt-01
>>
>>   == Outdated reference: A later version (-05) exists of
>>      draft-meyer-lisp-cons-03
>>
>>   -- Unexpected draft version: The latest known version of
>>      draft-ietf-lisp-interworking is -00, but you're referring to -01.
>>
>>   == Outdated reference: A later version (-02) exists of
>>      draft-farinacci-lisp-lig-01
>>
>>   == Outdated reference: A later version (-01) exists of
>>      draft-meyer-lisp-mn-00
>>
>>   == Outdated reference: A later version (-04) exists of
>> draft-ietf-lisp-ms-03
>>
>>   -- No information found for draft-mathy-lisp-dht - is the name correct?
>>
>>   == Outdated reference: A later version (-08) exists of
>>      draft-lear-lisp-nerd-04
>>
>>   == Outdated reference: A later version (-02) exists of
>>      draft-iannone-openlisp-implementation-01
>>
>>   == Outdated reference: A later version (-05) exists of
>>      draft-narten-radir-problem-statement-00
>>
>>   == Outdated reference: A later version (-09) exists of
>>      draft-ietf-mip4-rfc3344bis-05
>>
>>   == Outdated reference: draft-ietf-pim-rpf-vector has been published as RFC
>>      5496
>>
>>   -- No information found for draft-handley-p2ppush-unpublished-2007726 - is
>>      the name correct?
>>
>>   == Outdated reference: draft-ietf-shim6-proto has been published as
>> RFC 5533
> 
> We will fix the outdated references, thanks.
> 
> 	--Vince
> 
>