Subject: Re: [lisp] uRPF as a possible solution

From: [email-masked] (Noel Chiappa)
Date: Tue, 26 Jul 2011 11:38:05 -0400 (EDT)

> From: Patrick Frejborg <[email-masked]>

    > The ITR at the residence ... receives a packet from the local network,
    > there is no entry in the cache for the destination and thus it consults
    > the MS. 

Technically (unless by "MS" you meant 'Mapping System', but the acronym MS is
usually expanded to 'Map-Server'), it consults its Map-Resolver ('MR'), and
the MR (through means opaque to the average client, but at the moment its
the ALT) consults the MS on the ITR's behalf.

    > The rITR receives a reply from MS, creates the cache entry and adds
    > the LISP header to the packet 

An ITR _can_ buffer packets until the mapping arrives, but not necessarily:
other options are i) forward them through a PITR, or ii) drop them.

    > the packet is routed to the ITR of the content site (cITR), No cache
    > entry exists

Unless a mapping has been gleaned (which I personally think ought to be done
at cETRs, otherwise the cITR will have to go through a resolution cycle -
although there are a number of ways this could happen [and I don't recall
what the spec does at the moment],, e.g. when the rITR has to do the lookup,
it can make sure the matching mapping is intalled at the destination).

    > a reply is received, a cache entry is created at the cITR and the
    > returning packet gets encapsulated 

Same comment as above about the rITR.

    > For returning packets there is no need to do DNS lookups but if I have
    > understood LISP correctly the cITR needs to do MS lookups so that
    > returning packets gets routed back to the residences. If the cITR uses
    > only one MS server there will be intensive traffic between the cITR and
    > the MS server

As mentioned above, I favour some sort of 'piggybacking' (an class of
optimization used in a number of places in LISP) to prevent this by
'pre-loading' the mapping into the cITR's cache, although I'm more concerned
about delay/etc than the server load (although that of course is an issue
too, but only in some circumstances, like the one you outline, whereas delay
is always an issue).

    > The major difference with today's architecture is that there is no need
    > to do a lookup in DNS for returning traffic

Correct - this is the big architectural difference, hence my desire to get
rid of the mapping lookup in the reverse direction. (I had a great way to do
this in a secured way in CONS, but alas we aren't using CONS.)

    > If the cITR cache doesn't scale enough and I would prefer to add a
    > second cITR .. How do I ensure that the returning packets are routed to
    > the correct cITRs?

This is a great question/engineering issue, and one that has been extensively
discussed in the past. There is no great, easy, solution. Even if one can
provide the 'return' mapping to the ingress cETR (above), what happens if
that's not the same box as the cITR? One either i) has to work out a way to
make sure it is the same box (not trivial), or ii) pass the mapping to the
box that will be the cITR (not trivial), or iii) give up on optimizing out
the lookup cycle in the return direction (not acceptable, IMO). In other
words, the engineering details of large sites remain to be fully worked.

	Noel

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 28 Jul 2011 10:32:18 +0300

On Tue, Jul 26, 2011 at 6:38 PM, Noel Chiappa <[email-masked]> wrote:

>    > For returning packets there is no need to do DNS lookups but if I have
>    > understood LISP correctly the cITR needs to do MS lookups so that
>    > returning packets gets routed back to the residences. If the cITR uses
>    > only one MS server there will be intensive traffic between the cITR and
>    > the MS server
>

I agree with you, it would be nice to be able to pre-load the database
to the cITR, the delay is the bigger issue since for the returning
traffic is "one to many sites" lookup and hence the cache mechanism
might not be as efficient as in DNS. But taking that approach, the
mapping system would look more like BGP than DNS.

>
>    > The major difference with today's architecture is that there is no need
>    > to do a lookup in DNS for returning traffic
>
>    > If the cITR cache doesn't scale enough and I would prefer to add a
>    > second cITR .. How do I ensure that the returning packets are routed to
>    > the correct cITRs?
>

Think we have to live the lookup cycle in the return direction so that
uRPF can be used to prevent DoS and cache trash. But it might cause
delays for returning packets due to an event - this "ticket sale"
event can be created by a botnet admin if he has enough clients behind
rITRs and directed towards any content site. Thus the lookup cycle for
returning traffic is not only an issue for larger content sites but
also for all business critical content sites (today multi-homed
content sites).
The risk of lookup cycle delay can be mitigated if the server stack is
upgraded, if that would be possible then the content site admin has a
choice.

Patrick

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 28 Jul 2011 11:42:45 -0400

> rITRs and directed towards any content site. Thus the lookup cycle for

I would like everyone to keep in mind that the "botnet clients" or
malicious traffic does not need to originate from LISP sites.  A
motivated attacker will send crafted packets directly to the Internet
with a LISP outer-header and false source address in the inner-header.
 I am not sure it is even relevant if the malicious site(s) are
subject to BCP-38/uRPF/etc by their service provider.

> also for all business critical content sites (today multi-homed

I think we are all on the same page now.  I'm glad the discussion has
moved from one where it was thought that only super-huge content sites
would need to address this scaling problem, to folks agreeing that
every mission-critical site must do so.

-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts