Subject: [lisp] EIDs MUST NOT be used as LISP RLOCs.

From: Robin Whittle <[email-masked]>
Date: Wed, 25 Mar 2009 15:08:55 +1100

Just quoting the Good Book:

  http://tools.ietf.org/html/draft-farinacci-lisp-12#page-8

Please see my previous message:

  Consensus?  EID and RLOC use of the same address = separate
  namespace debate

    - Robin

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Mar 2009 08:02:43 -0700

Dino,

There are still MTU oddities in the latest LISP draft
that the team somehow seems reluctant to face up to.

First, there are no circumstances under which the ITR
may discard any packet with DF=0, i.e., even for packets
as large as 64KB. Instead, the ITR should pick a fragment
size (e.g., 1400B) and perform inner IPv4 fragmentation
on packets that are larger than this size before
encapsulating each fragment as an individual LISP packet.
The final destination gets to reassemble these.

Second, there are two problems with the stateful case.
First, there is no guarantee that the ICMPs sent by
middleboxes will make it to the ITR. Second, the attack
surface for spoofed ICMPs is the entire Internet.

To address this, we can enlist the ETR's aid in reporting
any IPv4 fragmentation that occurs on the path from the
ITR, and these reports will be encapsulated as LISP
packets sent back to the ITR and hence not susceptible
to ICMP filters on the path. The attack surface is also
reduced to on-path only.

I have already shown how this can be accommodated through
a slight rearrangement of the LISP header with no extra
overhead, and with the added benefit of providing extra
locator reachability bits. But, just for you, I am also
going to _RELAX THE REQUIREMENT FOR THE ETR TO DO ANY
REASSEMBLY_.

Yes, that's right - all the ETR will have to do is return
fragmentation reports; any outer IP fragmented packets
received by the ETR are dropped. This approach lets the
ITR discover a size S for which it will drop any packets
with DF=0 larger than S and return an ICMP packet too
big to the original source _without wasting any tunnel
resources_, i.e., even if S < 1500. If it turns out that
S is excessively small (e.g., S < 1280 for IPv6) then
there is truly a degenerate link somewhere within the
tunnel and someone should send a polite e-mail kindly
requesting that it be fixed.

So, what do you want to do about this? Leave the current
LISP text as it is and hope for the best? Or pick up a
lightweight mechanism that just might put the issue to
bed once and for all?

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Mar 2009 08:06:15 -0700

Slight correction:

> -----Original Message-----
> From: Templin, Fred L
> Sent: Wednesday, March 25, 2009 8:03 AM
> To: Dino Farinacci; [email-masked]
> Subject: [lisp] MTU handling in LISP
> 
> Dino,
> 

This should of course read "DF=1".

Fred

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp