Re: [lisp] Map-Versioning

[Dino Farinacci <[e-mail]>]

Sam, let me phrase what we have been discussing another way. We have  
the following subject matters:

(1) How to update ITRs which have old map-caches when a database  
mapping for a LISP site changes.

(2) Should we put an 8-bit flags field in the data encapsulation header.

(3) Are there anymore MTU issues.

(4) Can the loc-reach-bits in the data encapsulation header can  
compromised.

I believe the status for each is:

(1) You can use SMRs for map-cache updates according to the existing  
spec or you can use draft-iannone-lisp-mapping-versioning-00.txt,  
referred to as "map-versioning". The later requires header format  
changes and Luigi gave 3 options in his IETF presentation.

(2) We have *some* consensus gain on this. However, the E-bit for  
doing nonce-echoing has not been fully flushed out. So we should wait  
for changes IMO.

(3) I looked through all of Fred Templin's emails and his suggested  
text and made clarifying changes to draft-ietf-lisp-01.txt. So I think  
this issue is closed. We have 2 mechanisms to deal with MTU issues  
with encapsulation. One is stateless and the other is stateful which  
was offered by Luigi and team. They are simple mechanisms that use  
existing standards (Fragmentation and PMTU Discovery).

(4) We have documented in the latest spec (went in many revisions ago)  
that the loc-reach-bits are a hint and used for a certain class of  
failures (close to the destination LISP site) and that the loc-reach- 
bits need verification by round-trip exchange between the receiver  
(that wants to take action on the loc-reach-bit change) and the sender  
of the loc-reach-bits.

Dino

On Jun 2, 2009, at 7:40 AM, Sam Hartman wrote:

> Your slides jump right into describing the solution with map
> versioning, which really isn't such a great place to start a
> discussion of it.
>
> That discussion should start with the problem.
>
> If I understand the mail between you and Dino correctly, there are two
> concerns you have.
>
> 1) An attacker can manipulate the reachability bits and either create
> a DOS or cause traffic to take a path that gives the attacker some
> advantage.
>
> 2) Certain update situations could get the ITR and ETR out of sync
> about what the reachability bits map to and this could cause a problem
> for traffic.
>
> Is that the problem you're trying to solve?
>
> Dino's answer seems to be that:
>
> 1) If you care about these attacks you can verify the reachability
> bits.  Presumably we (the WG) will need to consider what mandatory
> guidance to give on this issue if we don't adopt map versioning.
>
> 2) There exist algorithms for adding/removing a locator in which the
> changes to the reachability bits are non-ambiguous.  Presumably if we
> don't adopt map versioning we'll need to make sure that the spec
> mandates such an update procedure.
>
> Have I got things right as far as I've gone?
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp