issues 18, 15, 6 -- return routability

Hello folks,

We had an excellent discussion about most of the open MOBIKE
issues in Minneapolis. The chairs would now like to run through
the issues on the list, get even those not in the meeting involved,
and attempt to come to a conclusion on each issue.

Meeting slides are at
http://www.vpnc.org/ietf-mobike/Minneapolis-05/ietf62_mobike_design.ppt

We are starting with issues 18, 15, 6 in this e-mail. I'll summarize the
meeting results on these issues, and state what the current
working assumption appears to be. We 'd like determine what the
final consensus is in two weeks, on April 13th, so please post
your opinions as soon as possible so that we have time to
complete the discussion. As usual, we'd like to
get positive confirmation of a result rather than interpreting
silence as agreement. So even if you don't have a problem with
what is being proposed, it would be good to send an e-mail
to the list saying that you are OK with the a particular
a solution.

So, issues 18, 15, and 6 are all related to if, when and how to do
return routability tests. These are the primary defense mechanism
against so called third party flooding attacks, where (perhaps
a legitimate) party in the communication directs a stream of payload
packets towards a victim. Note that flooding attacks are always possible,
if not otherwise then by sending packets to the victim directly.
The only remaining question is whether you can get some
amplification out of this, e.g., by redirecting a stream that
dies slowly when acks are not coming back. We don't need
to do any better than what existing Internet already offers;
we just need to ensure that we don't make the problem worse.

We have already decided issue 6, which
was about what kind of tests to use. The decision was to use
a cookie-based approach, where the responding party can not
fake the response unless he sees the original request. We are
not re-opening that discussion.

Issues 18 and 15 remain open. Issue 18 is about whether to
include the tests at all, and issue 15 is about when to do them.
The proposal that was discussed in IETF-62 was that it would
be mandatory for a responding party to respond to an RR
test (of course!), and that the initiation of an RR test would be
configuration driven with default being "on". We had a discussion
of whether to include also some indication of addresses in the
certificates in this decision, and there seemed to be opinions on
both sides. In any case, the standing proposal seems to be

  - Do the tests if configuration tells you to
  - Default is on
  - If the specific IP address can be found in the peer's certificate, 
you can skip the test

Issue 18 is about when to do the tests, before or after you
have moved the payload traffic stream. Again there seemed
to be opinions on both sides. Before is more secure, after
is faster. OTOH, in situations where you have well-behaving
peers, as in most VPNs the efficiency may not be an issue
if you turned this feature off to begin with. The proposal on the slides
was

  - Do the tests before moving the payload stream.

Let us know if these proposals work for you or if a different
approach is needed.

--Jari