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

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

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

    > concerned about using UDP with zero checksums in IPv6, because there
    > would be no checksum protection for the IPv6 header fields (src/dest
    > port and next header).

I guess I don't see that there's a big problem here, if the _outer_ IPv6
header is damaged. The inner packet (either v4, or v6) will still have its
checksum(s) to protect it.

I'm trying to understand what all the possible failure modes are if the outer
header is damaged. Here are the ones I can think of:

- The packet may arrive at the wrong destination, which should either i) not
recognize it (because it's not an ETR - I don't recall if LISP uses
registered ports, if not at some point we should apply for some), or 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).

- 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.

Maybe I'm not very awake today, but that's all I can come up with off the top
of my head? Other errors (e.g. bashing the hop count) may cause the packet to
be discarded in transit, but that can happen anyway.

In general, the reliance on explict control traffic (which is protected from
error by checksums - "The UDP Checksum is computed and set to non-zero for
Map-Request and Map-Reply messages") for most functions should help with
robustness.

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.

	Noel

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 6 Aug 2009 22:05:29 -0400

> checksum(s) to protect it.

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.

However, I do not think that this changes your argument too much.

Regards
Marshall

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Sam Hartman <[email-masked]>
Date: Fri, 07 Aug 2009 07:35:52 -0400

Speaking as an individual for the moment:

>>>>> "Noel" == Noel Chiappa <[email-masked]> writes:
    Noel> - The packet may arrive with a damaged source address. This
    Noel> may cause a bogus 'partner ITR' entry to be created
    Noel> (e.g. for the echo nonce entry), but I can't think of any
    Noel> real problems that will happen in this case.

I'm sending this message, mainly to indicate that the problem of outer
header corruption is one that requires real technical thought and that
has non-obvious consequences.

It may well be that we can design a LISP for which the possibility of
outer header corruption is acceptable and for which we can convince
ourselves of this fact.

However it's fairly easy for me to illustrate this requires actual
work and thought.

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 (the corrupted source IP address) 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.

Ignore for the moment that by the time we get done discussing
security, the behavior may be somewhat different:-)

It is clearly the case with today's LISP spec that a single corrupted
packet is permitted to disrupt communications between two lisp nodes
for a significant period of time.

This illustrates that it is very easy to design a protocol for which
this sort of corruption is easy.  Thus, I believe that the kind of
analysis Margaret is asking for needs to be performed carefully and
fully.  I for one will disregard any message claiming that outer
header corruption is not a problem if it includes the words "obvious,"
"easy," is generally dismissive of the problem, or is not thoroughly
detailed.

I want to stress that your message was a great technical contribution:
you were trying to find an easy way to dismiss a concern so we could
go onto other issues.  My problem is that after spending an hour or
so looking at the current LISP spec with regard to this issue, I've
come to the conclusion that there is no such easy mechanism.

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 8 Aug 2009 17:29:42 -0700

> has non-obvious consequences.

Are you worried the header is going to be corrupt and the link layer  
will not catch it?

> outer header corruption is acceptable and for which we can convince

Are we talking about security or bit-errors? Let's be real clear here.

> map-request, and I believe the default TTL is rather long.

Yes the spec does say that.

> security, the behavior may be somewhat different:-)

So the only way this would happen is if there was a bit-error from the  
last-hop that forwarded the packet to the ETR router. Is that what yo  
want to focus the discussion on?

> for a significant period of time.

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

Dino

---

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

Hi Noel,

> registered ports, if not at some point we should apply for some), or  

LISP currently lists an explicit port number in the draft.  Hopefully  
that
will turn into an IANA request.  Or, if the port is already registered  
to LISP,
it should become a reference to the IANA allocation.
> 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?
> 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?

For example, if EID 128.127.2.105 sends a packet that gets encapsulated
by the ITR to include a source RLOC of 12.0.0.1, but the source RLOC
gets corrupted to 15.0.0.1, the receiving xTR will set-up a mapping that
indicates that EID 128127.2.105 is reached via RLOC 15.0.0.1 and will
send the packet on to its proper destination.  However, when the
destination end node tries to respond, the response will go to EID
128.127.2.105 at RLOC 15.0.0.1, and it will be discarded.   Also, no
other node behind the destination xTR would be able to reach EID
128127.2.105 until the incorrect mapping is cleared or corrected.

There is some mention in the spec about verifying automatic mappings
with the mapping system, but there are no specifics about how/when/if
this will be done.

Thoughts?

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.

> be discarded in transit, but that can happen anyway.

Discarded packets are uninteresting, as all the checksum would do is  
cause
the packets to be discarded.  So, either way, some packets will be  
discarded,
or simply lost for other reasons.

There is one other case that I think we should be clear about:

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.

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

> Map-Request and Map-Reply messages") for most functions should help  

I agree.  It would be _much_ more of a concern if these packets used  
zero
checksums.
> to make sure they aren't affectable by damaged headers. So far that  

When you say this has been no problem, do you mean in the experimental
LISP network?  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?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 10 Aug 2009 23:17:48 -0400

> Are you worried the header is going to be corrupt and the link layer  

Research has shown that data corruption is far more likely to occur  
inside network equipment (e.g. from bus errors in routers and  
switches) than on the data link.  The data link CRC won't catch that  
problem, since it is recalculated at each hop.

> Are we talking about security or bit-errors? Let's be real clear here.

Both.   We should make sure that LISP does not fail catastrophically  
in the presence of unintentional or intentional packet corruption.
> Yes the spec does say that.

Really.  How soon is it required to do the confirmation?  And what is  
it expected to do with packets destined to the source EID in the  
meantime?  Could you quote the section of the spec that says this,  
because that is not how I read it...
>
> So the only way this would happen is if there was a bit-error from  
> the last-hop that forwarded the packet to the ETR router. Is that  
> what yo want to focus the discussion on?

Actually, an error inside any router or switch in the path could cause  
the headers that are received at the ETR to be corrupted.

> 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.

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Aug 2009 08:55:12 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    >> 
    >> 
    >> I'm sending this message, mainly to indicate that the problem
    >> of outer header corruption is one that requires real technical
    >> thought and that has non-obvious consequences.

    Dino> Are you worried the header is going to be corrupt and the
    Dino> link layer will not catch it?
I'm using the same model of corruption that the IETF seems to have
consensus behind; Margaret forwarded you links to research papers that
put forward a model.  This model seems to have reasonably wide
acceptance in the transport and internet area of the IETF.  If you
have other research papers you want to put forward with a different
model then that would be very interesting and would definitely help
inform the discussion.

    >> It may well be that we can design a LISP for which the
    >> possibility of outer header corruption is acceptable and for
    >> which we can convince ourselves of this fact.

    Dino> Are we talking about security or bit-errors? Let's be real
    Dino> clear here.

At this point I'm talking about bit errors.  I've been thinking some
about security although I've not said anything on the list about
security.  However in this thread I'm talking about bit errors.