Subject: [RAM] thoughts on draft-farinacci-lisp-00

From: Jari Arkko <[email-masked]>
Date: Mon, 29 Jan 2007 18:47:44 +0200

Hi,

I read the draft and was quite happy with
it in terms of something that is intended to
be a base for experiments. A couple of
observations and questions, however:

> LISP
As an old Lisp hacker, I like the name of your
proposal :-) Now, if you can also name the
addresses as CARs and identifiers as CDRs
(or maybe that's CIRs)...

>    The operator community has requested that the IETF take a practical
>    approach to solving the scaling problems associated with global
>    routing state growth.  This document offers a simple solution which
>    is intended for use in a pilot program to gain experience in working
>    on this problem.
>
>    The authors hope that publishing this specification will allow the
>    rapid implementation of multiple vendor prototypes and deployment on
>    a small scale.  Doing this will help the community:
>
>    o  ...
>   
I very much agree with the approach of testing practical
solutions and getting experience on what the hard
issues really are. Thank you for writing up your
prototyping/experimenting plans; we should have
more drafts that take this approach.
> load-splitting across its members.
Is load-splitting a requirement from a traffic
engineering perspective? What is the impact
from the point of view of the same TCP
session ending up going over multiple
paths? Note that most of the end-host
multihoming work has punted this
question by stating that load-balancing
is out of scope.

Or is there something that you can
do to avoid the problem with TCP, such as
requiring that traffic from the same EID
source/destination pair can never be split
across paths?

>  3.  In LISP 1, the packet is routed through the Internet as it is
>      today.  In LISP 1.5, the packet is routed on a different topology
>      which may have EID prefixes distributed and advertised in an
>      aggregatable fashion.  In either case, the packet arrives at the
>      ETR. 
I like this, because it means that applications
that are unaware that they are dealing with
EIDs can leak them to other hosts, and those
hosts will still be use the EIDs, because they
are routable.

However, presumably this means that for
LISP 1, there is no change in the size
of the routing table needed in the global
Internet. Every site has to be able to be
reachable with EIDs.

(Conversely, in LISP 3 & 4, you would
have the application referral problem.)
> RLOC unreachability is
> detected by the receipt of ICMP Host Unreachable messages.  When an
> RLOC has been determined unreachable, it is not used for active
> traffic; this is the same as if it is listed in a Mapping Reply with
> priority 255.
I'm a bit uncomfortable with relying solely on
ICMP for this function. What happens if something
filters it away, will you be able to recover?

Also, the failure/reachability part probably needs more
work in general. When do you switch back from a situation
where the RLOC has been determined as unreachable?
>    LISP is designed to be very hardware-based forwarding friendly.  By
>    doing tunnel header prepending [RFC1955] and stripping instead of re-
>    writing addresses, existing hardware can support the forwarding model
>    with little or no modification.  Where modifications are required,
>    they should be limited to re-programming existing hardware rather
>    than requiring expensive design changes to hard-coded algorithms in
>    silicon.
>   

Sounds good.
> EID-prefix-to-Locator mappings need to be explicitly configured.
Can you expand on what this means? So, for instance, in
the first hop router case, what would we have to
configure? The EID prefix advertised in the local network --
but wouldn't we have to configure a prefix anyway?
Or the mapping between the router's RLOC and this
prefix? But even that might be obvious, assuming
that the Lisp feature is turned on and that you have
one prefix in the local network and one RLOC from
higher up...

>    o  Experiment with provider-independent assignment of EIDs 
Any thoughts on what this would be? Either for the
experiment or for a full-blown solution later? That
is, what space would be allocating the EIDs from?
Would they be syntactically distinguishable from
regular addresses?

>    ICMP EID-to-RLOC Reply messages are authoritative to the same extent
>    DNS Replies are.  LISP is no less secure than DNS and at this time we
>    do not intend to add any additional security mechanisms to the
>    proposal.
>   
I am not sure the comparison to DNS is correct.

A different comparison would be to look at what
attackers in different locations (on path, off
path, peers) can do and whether there is something
that changes in this proposal.

If Request - Reply is defined so that only the Reply
has an effect and that suitable Reply contents
cannot be guessed by off-path attackers, then I
think we have roughly what we already have
for Internet security: on-path attackers will be
able to cause problems, but there is some
weak protection against off-path attackers.
This is mostly good enough, I think.

But I suspect there are details that the draft
did not go into. For instance, wouldn't there
be a need for a router to tell its peer that
the router's own addresses have changed? How
would that be implemented with only Request and
Reply?
>    2.  The default router is configured as an ITR.  It prepends a LISP
>        header to the packet, with one of it's RLOCs as the source IP
>        address and uses the destination EID from the original packet
>        header as the destination IP address.
How does the ITR know that it can use LISP
towards this destination? Is it syntactically
obvious from the destination EID, is it configured,
or is it dynamically learned?
>    o  Experiment with mobility to determine if both acceptable
>       convergence and session survivability properties can be scalably
>       implemented to support both individual device roaming and site
>       service provider changes.
>   
The draft does not have a lot of other text on mobility.
I suspect there are details to be worked out... for instance,
would this be able to provide a rendezvous function
for simultaneously moving hosts? And it seems to
preclude talking to legacy hosts while moving.

And here are also some editorial comments while
I'm at it:
>    When a data packet triggers a Reply to be sent, the RLOC associated
>    with the EID-prefix matched by the EID in the original packet
>    destination IP address field will be returned.  
Did you mean "the RLOCs associated ...."? Presumably there
must be multiple RLOCs per EID or EID prefix.

>    [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
>               (HIP) Architecture", RFC 4423, May 2006.
>   
Why was this listed as a normative reference? Were you
using something from this RFC?

Jari

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram