Subject: Re: [lisp] Outer header damage [Re: Flow label redux]

From: [email-masked] (Noel Chiappa)
Date: Tue, 11 Aug 2009 09:22:24 -0400 (EDT)

{Hey, all, my mailbox was offline for a couple of days. Catching up now... So
if it seems like I've missed a message, that would be why.}

    > From: Margaret Wasserman <[email-masked]>

    > what is it expected to do with packets destined to the source EID in
    > the meantime?

In a short follow-up message to my long reply to Sam's long one pointing out
this problem initially, I pointed out:

    >> Transient bogus mappings do no real harm - the choice would
    >> be between i) no mapping, and ii) a bad mapping.

    > PS: This thought applies to mappings gleaned from damaged packets, too.

    > If every so often one gets a bad mapping in the cache [from gleaning],
    > until the 'official' mapping comes through from the enquiry, [in spite
    > of that, gleaning]'s probably still a worthwhile optimization, because
    > i) no [additional] harm will have been done by the occasional bad
    > mapping, and ii) in all the other instances, one's better off than
    > waiting for the authenticated mapping to arrive.

Was there a mistake somewhere in that line of reasoning?

    >> There is nothing in the spec that says *this is permitted*.

    > However, it does say that the use of "gleaned" mappings is allowed, and
    > places no specific limitations on their use.

Can we distinguish between problems where i) the solution is relatively
straightforward, and it more a case of 'make a note to document this in the
next rev of the spec', and ii) where is a more serious technical issue, one
which is not trivial?

It does seem to me that this particular 'damaged header' issue falls into the
former category. (Although I agree with what I perceive Sam's position to be,
that we have to carefully audit the spec to make sure that any kind of damage
to un-protected headers will not cause a problem.)

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 11 Aug 2009 11:18:09 -0400

> Was there a mistake somewhere in that line of reasoning?

I'm thinking about this...

I don't think there is a mistake in your reasoning if we only consider  
accidental corruption.

There are security issues with "gleaned" mappings that may result in  
their removal from the specification.  If that doesn't happen, then we  
need (IMO) to be very specific about how the gleaned mappings can be  
used and how/when they will be checked with the mapping system, etc.

I agree with what you said about careful analysis of the specification  
to determine the impacts of corrupted outer headers.

Margaret