Subject: [Mobike] issues 18, 15, 6 -- return routability

From: Jari Arkko <[email-masked]>
Date: Wed, 30 Mar 2005 17:12:41 +0300

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

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Wed, 30 Mar 2005 15:19:13 -0500

Hi Jari,

I think the RR test should be done before the loss of connectivity.  

Before would quickly accomplish the goal of proving that the peer actually
owns the IP address.  If you wait until after the loss of connectivity,
you'd have to source the RR using every interface you had configured, since
you wouldn't be sure if your interface was actually working properly (or if
it is the peer's interface that malfunctioned).  This would exponentially
increase the number of messages per interface.

Stephane. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Wednesday, March 30, 2005 9:13 AM
> To: [email-masked]
> Subject: [Mobike] issues 18, 15, 6 -- return routability
> 
> 
> Hello folks,
> 
> 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
> 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.
> 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.
> 
> 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
> 
>   - If the specific IP address can be found in the peer's 
> certificate, you can skip the test
> 
> 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
>

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 30 Mar 2005 15:59:01 -0800

>   - If the specific IP address can be found in the peer's certificate, 
I am okay with the first two. I must have missed the discussion on the
address found in the peer's certificate.. What address ? Can you give
some more details ?

>   - Do the tests before moving the payload stream.
Sounds good.

-mohan

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 30 Mar 2005 18:31:58 -0800

>  - Do the tests if configuration tells you to

the configuration could be in many different ways, right? for
example, even if the configuration on a VPN gateway is to
perform the test, the configuration could further say, perform
the text only when the traffic to a particular address exceeds
a certain volume? basically I see the configuration as internal
to the node. It could say
   - just perform the test for everyone, everytime
   - exclude this list of nodes for return routability tests
   - perform the test if the traffic exceeds a certain volume
   - and so on....

do we want all of the above to be allowed, or just a simple
perform the test/don't perform the test?

>  - Default is on

okay.

>  - If the specific IP address can be found in the peer's certificate, 

how do dynamic addresses get into the certificate? I think
I missed the discussion. maybe, I should look in the archives.

>  - Do the tests before moving the payload stream.

sounds good.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Thu, 31 Mar 2005 07:48:23 +0300

> perform the test/don't perform the test?

Yes. I guess what we are saying that you must at least
have an on/off config knob... but a particular implementation
could have a fancier scheme. I agree that its largely
internal, and hard to standarize what the "fancier" stuff
is.

> I missed the discussion. maybe, I should look in the archives.
They don't. You could only do this between stationary gateways.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 31 Mar 2005 07:53:51 +0300

Hi Stephane,

>increase the number of messages per interface.
I think you interpreted the "before/after" distinction slightly
differently that what had originally thought. I was asking
whether we do the test before the traffic stream is moved,
you are asking whether to do the test before the nodes
move. Both are valid questions, but I was assuming that
nodes just happen to move, and that we don't necessarily
always know that this happens before its already done.
Of course, a MOBIKE node that knows its address is going
to go bad soon can and should start using a new address.
But I don't think we can guarantee this is known in all cases.

(But if we know we are going to move, we don't need to
RR every address, just the one that we are going to use.
RR isn't need to test reachability, my understanding is
that some kind of probing would take place prior to that.
For instance, when a client moves, it should probably probe
connectivity to the SGW in order to make sure its new address
works and in order to punch a hole to the NAT mappings. Then
it can tell SGW that this is the new address, and the SGW
can perform an RR test to verify that the new address was indeed
what was claimed.)

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 31 Mar 2005 07:56:33 +0300

>address found in the peer's certificate.. What address ? Can you give
This is what the design draft said:

   o  The addresses a peer is using are part of a certificate.
      [RFC3554] introduced this approach.  If the other peer is, for
      example, a security gateway with a limited set of fixed IP
      addresses, then the security gateway may have a certificate with
      all the IP addresses in the certificate.

(But the use of certificates in this manner seemed to be a
bit controversial in the meeting, and this list discussion seems
to ask questions about it too. We might also consider the
certificate stuff as part of Vijay's "advanced configuration",
i.e., possible but implementation dependent behaviour.)

--Jari