Inline....
> -----Original Message-----
> From: Dino Farinacci [mailto:[email protected]]
> Sent: Wednesday, March 20, 2013 2:15 PM
> To: Ronald Bonica
> Cc: Damien Saucez; LISP mailing list list
> Subject: Re: [lisp] Need comments on LISP Threats Analysis
>
> > Do you agree that Options 1, 2 and 3 are all bad ideas?
>
> I can't with a binary answer.
>
> Without verification (option 1) is the way most implementations will
> go. Just like we don't do source checks on every router by default
> today.
Just to be sure that I am understanding your words...
An implementation (e.g., IOS version x.y.z) may support multiple options. A
specific XTR will select one or more implemented options by configuration.
Do I have that right?
>
> Option 2 is definitely useful if the map-cache entry is already there.
> Should one create one by doing a lookup. Well that is a lot of work and
> would have scaling implications if not rate-limited properly from a
> message rate as well as a cache size perspective.
I should have been more specific about expressing Option 2. I should have read:
2) Query the map-cache. If an entry exists and it indicates that the RLOC is
authorized to originate traffic sourced by the EID, pass the packet. If an
entry exists and it indicates that the RLOC is not authorized to originate
traffic sourced by the EID, discard the packet.
2a) if no entry exists, pass the packet, without sending a map-request
2b) if no entry exists, discard the packet without sending a map-request
Option 2b is the non-starter. Option 2a is only a slight improvement over #1
because, in the attack that I describe, the map-entry is not very likely to be
present. Option
>
> > Also, before I ask a dumb question, can you point me at something
> that I can read that describes how the entry in Option 4 is used? If
> not, could you provide some detail?
>
> There is nothing to read. It was a newer idea. Not all good (and bad
> ideas) are written down but could be hidden in code. :-)
:-)
>
> Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
