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

[Vince Fuller <[e-mail]>]

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.

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

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

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

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

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

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

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

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