Subject: [lisp] Confirming Consensus on RLOC probing

From: Sam Hartman <[email-masked]>
Date: Mon, 7 Sep 2009 19:41:29 -0400 (EDT)

Folks, there was a presentation on RLOC reachability at the IETF 75
meeting in Stockholm.  It's my perception from the audio that the
sense of the room was that RLOC probing was something that we want to
specify so we can experiment with it.

I'd like to confirm that consensus on the list.  Because I've seen a
fair bit of discussion of this issue, I'm going to assume that we have
consensus unless I hear major objections by Friday, September 11.

If you need more time to review this issue, please let me know; if you
ask for more time, I definitely expect a review of the issue and the
specific text from you.

If you've read the specific text in Dino's 04 proposal on this issue,
please let the list know.  Comments are of course welcome.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 7 Sep 2009 16:52:25 -0700

> please let the list know.  Comments are of course welcome.

Please note we indicate that this is an optional feature. And we are  
testing it on the LISP test network as we speak.

Dino

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Sep 2009 20:26:02 -0400

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> If you've read the specific text in Dino's 04 proposal on
    Sam> this issue, please let the list know.  Comments are of course
    Sam> welcome.  _______________________________________________
    Sam> lisp mailing list [email-masked]
    Sam> https://www.ietf.org/mailman/listinfo/lisp

I've read the text and certainly have no concerns about it going into
04.  Long term I'm not sure that overloading rloc reachability probes
onto the map reply/request messages is a good idea.

Here are some things I think you may want to do with RLOC probes:

* supply MTU probing information for the new PMTU algorithm
* Establish a nonce to prevent certain spoofing attacks

On the other hand a lot of security models we might adopt involve
proving that someone can send from a given RLOC and wants traffic for
a given EID at that RLOC before we send any significant traffic to
that RLOC.

Mixed in with this is some concerns I have about the complexity of the
map reply and request handling in the current spec.  I think I'd need
to actually work through a state machine for a map cache in an ITR
before I'd have a firm opinion.

Also, the above assumes we have an understanding of our security and MTU related goals, both of which I believe to be false.

So, the net of my comment is that this seems like a fine starting
point but we may end up revising things later.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 7 Sep 2009 19:30:15 -0700

> * supply MTU probing information for the new PMTU algorithm

That won't work. If I send you a probe and say that my MTU is x, you  
might not use the same path to get to me. Plus you need the help of  
intermediate routers to tell you the effective MTU.

Using Path MTU discovery as already specified in its RFC will suffice.

> * Establish a nonce to prevent certain spoofing attacks

It is there. If you use a Map-Request for an RLOC-probe, which is what  
is specified, then a nonce is in the packet.

> a given EID at that RLOC before we send any significant traffic to

If you do this, you increase packet loss.

> before I'd have a firm opinion.

It is really simple Sam. I wonder where you think the complexity is.

> Also, the above assumes we have an understanding of our security and  
> MTU related goals, both of which I believe to be false.

Why do you think that?

Because from your commentary, I think you didn't understand what's  
designed.

Dino

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Sep 2009 22:44:51 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    Dino> That won't work. If I send you a probe and say that my MTU
    Dino> is x, you might not use the same path to get to me. Plus you
    Dino> need the help of intermediate routers to tell you the
    Dino> effective MTU.
Take a look at RFC 4821.  That spec requires that you send packets of
various size and later determine whether they were received.

    Dino> Using Path MTU discovery as already specified in its RFC
    Dino> will suffice.

I can't have that discussion until I understand the LISP deployment
model enough to determine whether I believe the claims about MTU
currently in the spec.
So, for me at least, MTU is blocked on LISP deployment.
    >> On the other hand a lot of security models we might adopt
    >> involve proving that someone can send from a given RLOC and
    >> wants traffic for a given EID at that RLOC before we send any
    >> significant traffic to that RLOC.

    Dino> If you do this, you increase packet loss.

Yep or queue them or use data probes.  However, the IETF has had a lot
of discussion about this issue in the MIP6, multi6, shim6 and HIP
contexts.  We're going to need to wade through all that discussion and
either agree with it or disagree for good reason and sell our
interpretation to the rest of the IETF.  I think we're agreed that we
don't want LISP to make the security of the Internet worse.  I suspect
we'll find we disagree on what the security of the Internet is and on
what counts as worse.

    >> Mixed in with this is some concerns I have about the complexity
    >> of the map reply and request handling in the current spec.  I
    >> think I'd need to actually work through a state machine for a
    >> map cache in an ITR before I'd have a firm opinion.

    Dino> It is really simple Sam. I wonder where you think the
    Dino> complexity is.
Mostly surrounding security--when is it appropriate to trust a map
reply or request, when is it appropriate to use RLOCs vs the mapping
system, when I should trust data received in the map reply portion of
the map request, etc etc.

It's also the case that the requirements for what the ETR and ITR do
are scattered somewhat across -lisp, -ms, and -alt; there are not good
modularity boundaries in how the text is written, so confirming that
the text is self consistent has been difficult for me.  Similarly,
there is a lot of complexity from lisp 1.0, lisp >1.5, cons etc still
in the draft that gets in the way.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 7 Sep 2009 19:53:39 -0700

> various size and later determine whether they were received.

We shouldn't put more mechanism in an optional procedure. Plus, you  
may not want to do make-before-break. So if you want to figure out the  
effective MTU, you drop packets in the meantime.

> Yep or queue them or use data probes.  However, the IETF has had a lot

That is not practical in a hardware implementation.

> the map request, etc etc.

You will see that what we have is elegant and simple and probably  
handles most real security threats. Darrel can share more with you.

> in the draft that gets in the way.

Well, we need to keep some history as to what research we tried so new  
people coming into the work don't cause us to keep repeating ourselves.

Dino

---

From: Jari Arkko <[email-masked]>
Date: Tue, 08 Sep 2009 21:01:59 +0300

I agree.

Jari