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

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Mar 2010 16:37:44 -0400

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review. The purpose
of the review is to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-lisp-06.txt
Reviewer: Ron Bonica
Review Date: 3/15/2010
IETF LC End Date: TBD
Intended Status: EXPERIMENTAL

Summary:

I have significant concerns about this document and recommend that the
Routing ADs discuss these issues further with the authors.

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?

- UDP Checksum - When an iTR formats the LISP UDP header, it sets the
UDP checksum to zero. This is in violation of RFC 768.

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

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.

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.

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

Minor Issues

- Terminology section defines many terms that are already commonly
understood.

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

 ----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.

  ** There are 5 instances of lines with non-RFC2606-compliant FQDNs in
the document.

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

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

     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.

  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

     Summary: 3 errors (**), 14 warnings (==), 3 comments (--).

     Run idnits with the --verbose option for more detailed information
about
     the items above.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Mar 2010 19:48:42 -0400

I wanted to highlight one issue, and see what folks think the right path 
is for it.

> Hello,
...
> o Architectural Issues
...
> UDP checksum to zero. This is in violation of RFC 768.
...

That is not a violation of RFC 768.  For IPv4, a 0 UDP checksum is a 
long established practice, and widely documented and used.

However, there is an issue for IPv6.  The IPv6 specifications changed 
the rules for UDP, as a corollary of removing the IP header checksum. 
In IPv6, UDP is required to always have a valid checksum.

This creates a significant problem for ANY high volume tunneling 
protocol.  Not just LISP.
Assumption: If you have a high volume tunnel, you want to allow ECMP (or 
LAG) logic to properly handle traffic within the tunnel.
But, ECMP / LAG logic in current deployment, for IPv6 uses the src/dst 
IPv6 address, the protocol, and the port numbers.
This means that for a high volume tunnel, you need port numbers in a 
protocol that the ECMP logic will accept.  Only TCP and UDP currently 
meet that constraint.

Constraint:  Many high end routers can not calculate a valid UDP 
checksum over the entire content of the body of the packet, which is 
what is required by the IPv6 RFCs.

This puts us in a VERY difficult spot.
We can pretend that there are no high volume tunnels in the internet. 
(This would seem inappropriate for an experiment interested in scaling 
properties, even if the experiment itself may not achieve the bandwidths 
needed for this to be a major issue.)
We can violate the RFC.
We can try to change the RFC (but the transport area is VERY reluctant 
to relax this rule.)

In the long run, I believe that the right answer is to encourage vendors 
  to include the IPv6 flow label in their ECMP (or LAG) hash.
However, I do not see how we can hold up experimental work going on now 
waiting for that eventual future.

I do anticipate a fight with transport about this.
But it should be clearly understood that this particular issue has MUCH 
larger scope than just LISP.

Yours,
Joel M. Halpern

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Mar 2010 19:59:22 -0400

Joel,

Good catch! Thanks for catching my error!

                          Ron

Joel M. Halpern wrote:
> the rules for UDP, as a corollary of removing the IP header checksum. In
> IPv6, UDP is required to always have a valid checksum.
>

---

From: <[email-masked]>
Date: Tue, 16 Mar 2010 10:09:52 +0100

Joel M. Halpern :
> [...]
> [...] it should be clearly understood that this particular issue has
> MUCH larger scope than just LISP.

The very same UDPv6 checksum issue is being faced by the AMT protocol in
the mboned working group (draft-ietf-mboned-auto-multicast).  See eg.
the thread starting at
http://www.ietf.org/mail-archive/web/mboned/current/msg00904.html . They
seem optimistic that the current rule on v6 UDP would get relaxed.

-Thomas

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Mar 2010 07:18:00 -0400

Yes, the AMT folks ran into a different version of the same problem.
I am not fully conversant with their concerns, but as I understand it, 
ECMP treatment in routers is not the primary driver for them.  As such, 
they are considering solutions like UDP-lite.  This would work fairly 
quickly for end systems, and like the use of flow-spec would be 
sufficient in the routers once it was deployed.  But getting from here 
to there seems to be an obstacle.  (For those who have not followed 
every possible debate in our community, UDP-lite is an alternative 
carried protocol that mostly looks like UDP.  However, only checksums 
the IP header and the UDP header, which is far more impplementable at 
high rates or in routers.)

Yours,
Joel

---

From: Vince Fuller <[email-masked]>
Date: Mon, 22 Mar 2010 22:17:06 -0700

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.

> 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 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 [email-masked]
mailing list.

> 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 [email-masked]. The Interworking draft also
has some descriptive text regarding NAT and LISP.

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

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

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

> - Terminology section defines many terms that are already commonly

Given how much confusion has persisted on the RRG and [email-masked]
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.

>      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

Can you please list the specific errors so that we can fix them?

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

>   == 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?
>      they MUST not be sent inside Encapsulated Control Messages.

We will fix this, thanks.

>   Checking references for intended status: Experimental

We will fix the outdated references, thanks.

	--Vince

---

From: Ron Bonica <[email-masked]>
Date: Fri, 26 Mar 2010 17:39:09 -0400

Hi Vince,

Responses inline....

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

> Please see Joel Halpern's recent message on this topic fo the [email-masked]

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

> has some descriptive text regarding NAT and LISP.

If another document is coming, I can accept that.
> 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.
> covers, in detail, the mechanisms for LISP and non-LISP sites to

ok

> Migration would also seem to be a central topic of a future LISP Deployment

OK. If another document is coming, that's fine.
> 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.