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

From: [email-masked] (Noel Chiappa)
Date: Thu, 6 Aug 2009 22:38:36 -0400 (EDT)

> From: Marshall Eubanks <[email-masked]>

    > This is more than just LISP. Any relaxation of the IPv6 header checksum
    > will be an update of RFC2460 and will be applicable to more uses than
    > just LISP.

My message was about the technical issues. I personally am utterly
uninterested in the overly-bureacratic standards-process red-tape hoops.

If you have technical insight to offer on the topic covered in that message -
i.e. the consequences of undetected damage to the outer internetwork layer
header - I would, however, be most interested in that.

	Noel

---

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

> Probably have text in the spec to say that such mappings are temporary
    > optimizations, and have to be replaced by an authenticated mapping
    > ASAP? ... 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, until the 'official'
mapping comes through from the enquiry, that's probably still a worthwhile
optimization, because i) no 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.

	Noel

---

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

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

    >> ii) unwrap it and discover that that EID is not at that ETR (which is
    >> a failure that can happen for other reasons, so has to be handled).

    > Will an error be sent back to the originating ITR when this happens, so
    > that it knows that it should try to update its mapping cache?

I'm not sure if the behaviour for that case is specified yet (too lazy to
look at the latest rev of the draft :-).

I would definitely think an error message should be sent back from the ETR to
the ITR. The ITR should, of course, make sure that any such error message is
facially valid (i.e. that it has a mapping for that EID to that ETR), before
taking any action on it.

And that action should _not_ include dropping that ETR from the mapping,
because that would introduce a DoS attack vector, since we still can't
guarantee to have eradicated packets with bogus source addresses from the
network as a whole. (And in any event, depending on that would be bad, as if
someone clever figured out how to introduce them anyway, all security
mechanisms built on that assumption would fail...)

Having the bad ETR try and forward the packet is probably a waste of time; it
will probably have to do a lookup cycle, and the results would only be useful
for 1.4 RTTs, until the source ITR updates its mapping. But perhaps
experience will show us otherwise...?

    >> The packet may arrive with a damaged source address. This may cause a
    >> bogus 'partner ITR' entry to be created (e.g. for the echo nonce
    >> entry), but I can't think of any real problems that will happen in
    >> this case.

    > Ummm... Wouldn't this cause end-nodes behind the destination ETR to be
    > unable to initiate connections to the original source EID until the
    > incorrect mapping is corrected?

When I wrote that, I had forgotten about gleaning. As the later discussion on
that topic (starting with my long reply to Sam's original long message) makes
clear, that's probably not a major problem; as far as I can see we just have
to be careful to document (and follow :-) the correct behaviour (never
override a requested mapping, request a mapping to 'back up' any gleaned
mappings as soon as you get the gleaned mapping, etc).

    > If this is a real issue, it is also a potential security problem, as
    > there is nothing preventing a node from sending a packet containing an
    > invalid EID/RLOC source pair, explicitly to create an incorrect mapping
    > entry.

Yes (hence the "never override a requested mapping").

In general, scanning the spec carefully for DoS attack vectors is something
else that needs to be done. We have paid a fair amount of attention to
security, and many holes have been plugged, but there is always another one,
of course....

    > If the destination address is corrupted and the packet arrives at a
    > non-LISP node, that node will send back an ICMP "port unreachable"
    > message. We should make sure that the LISP node that receives the ICMP
    > error will handle it correctly -- in this case, just discard it.

Yes.

    > In general, the LISP spec seems to lack information about how to
    > handle, and when to generate, ICMP errors.

Good point.

    >> There are a _few_ functions which are piggybacked on user data
    >> traffic, and as alluded to in a prior message, we do have to be
    >> careful in designing them, to make sure they aren't affectable by
    >> damaged headers. So far that has been no problem.

    > When you say this has been no problem, do you mean in the experimental
    > LISP network?

No, in the design process, as in 'no major problem to make sure that the
protocol works in the presence of the occasional damaged, but undetected,
packet'. E.g. with nonces, if every so often the return or reply value is
bashed, or the bit is set the wrong way, things still work.

    > I'd be interested to know more about how that network is configured, so
    > that I could understand if it is likely to be representative of
    > real-world deployment in terms of these types of problems. Is there a
    > site that describes that network in detail?

I know relatively little about the test network (although there's been a lot
done over the last couple of years). There is this site:

  http://www.lisp4.net/

but other than that, someone else will have to provide any information about
it you are interested in.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 11 Aug 2009 10:41:16 -0400 (EDT)

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

    > I think you missed my primary point. .. Gleaning demonstrates that
    > packet corruption is more complicated than you originally thought. I
    > provided one example

As I previously indicated, I agree that we do need to carefully audit the
protocol for places where header damage (either LISP header, or IP header) on
user-data packets could be an issue. (Just as we need to carefully audit it
for DoS vectors.)

As I also previously indicated, I had previously identified 'damage to
unprotected headers' as an issue, and at the point that I did so, had done a
cursory scan of the protocol (in my mind) to try and find problems (although
I excepted the reachability bits, and didn't think them through in detail,
because they might be replaced by versioning), and hadn't found any
show-stoppers.

I missed gleaning because I didn't realize it was still part of the spec.
There may be others that I missed, also. That sort of careful sweep is not my
forte, so I hope someone else will be looking at this?

    > this was by no means the only feature in LISP where I could not see
    > corruption being an issue.

Can you provide details on what other cases/places concerned you?

	Noel