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

From: [email-masked] (Noel Chiappa)
Date: Fri, 7 Aug 2009 08:27:36 -0400 (EDT)

> From: Sam Hartman <[email-masked]>

    > Under the current lisp-03 spec, an ETR receiving such a packet is
    > allowed to create a gleaned cache entry for the source EID in the
    > packet, using the outer RLOC .. for communication with that EID.
    > 
    > Nothing in the current spec mandates that the ETR send a confirming
    > map-request, and I believe the default TTL is rather long.

Is that [still] in the spec? (I've seen so many versions of the main spec
document I have a hard time forcing myself to read them any more! :-) If it's
still there, yes, it's an issue.

I thought that that was either i) something associated with other 'versions'
of LISP (or perhaps 'deployment models' is more accurate terminology than
"versions" - I'm talking about things like 'LISP 1', where there is no
mapping system), or ii) something that had been deprecated as a DoS vector
(send someone a bogus packet, and pollute their mapping cache).

If in fact this is still in the spec for the main 'deployment model', there
are several different potential directions to go to fix this. One is to say
'we won't do this optimization' (i.e. won't piggyback that control operation
on user data traffic); another is to make sure it's reliable (i.e.  mandate
checksums on packets which we wish to be 'gleanable'). There are a whole bunch
of variants, though.

For instance, we could say 'a mapping can't be gleaned from a user-data
packet with a zero checksum'; that leaves it up to the sending ITR whether it
wants to bother optimizing that control interaction (which would mean doing
the checksum - of course, you wouldn't want the overhead of doing that on all
packets, so the sending ITR would need logic that's probably more complex
than it's worth to decide when to checksum such packets - e.g. the first N
packets after a mapping is looked up).

Also, such gleaning is still a potential DoS vector, even if the data is not
damaged, so we'd still have to deal with that aspect. Probably have text in
the spec to say that such mappings are temporary optimizations, and have to
be replaced by an authenticated mapping ASAP? (And in no cases should such a
'gleaned' mapping replace one that had been looked up in an authenticated
manner.) Transient bogus mappings do no real harm - the choice would be
between i) no mapping, and ii) a bad mapping.

    > you were trying to find an easy way to dismiss a concern so we could go
    > onto other issues.

Yes and no.

No, in that if there is a problem, I would like to find it - hence my comments
of "Here are the ones I can think of" and "Maybe I'm not very awake today, but
that's all I can come up with off the top of my head". My survey was a quick
one, performed (as indicated by that comment) without checking through the
spec in detail, and was intended to jump-start a technical discussion on this
exact point - are there any piggy-backed control interactions that would be
affected by damaged headers.

Yes, in that since there are very few control interactions piggy-backed on
user data traffic, and those few that there are are generally optimizations,
at a high level that indicates to me that there should not be any great
difficulty in making the protocol work in an environment which has the
potential for damaged headers.

But there is _no way_ I want to see a protocol which has any issues of this
sort (or any other) go out. Sweeping problems under the rug is not a
'feature', it's highly counter-productive.

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 10 Aug 2009 22:31:15 -0400

Hi Noel,

> (send someone a bogus packet, and pollute their mapping cache).

Yes, this is still in the spec.  Of course, the spec also still  
includes the list of
various LISP "versions", and other text that clearly only applies to  
versions that
we are not planning to fully specify.  It would be very helpful if the  
LISP
authors could clean up the spec to specify only the version of LISP we  
are
attempting to document, so that there wouldn't be any ambiguity about  
what
applies to "this version" and what doesn't.

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Aug 2009 10:26:35 -0400

I think you missed my primary point.  Gleaning is not the important
issue.  Gleaning demonstrates that packet corruption is more
complicated than you originally thought.  I provided one example, but
this was by no means the only feature in LISP where I could not see
corruption being an issue.