RE: issues 18, 15, 6 -- return routability

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 protected] 
> [mailto:[email protected]] On Behalf Of Jari Arkko
> Sent: Wednesday, March 30, 2005 9:13 AM
> To: [email protected]
> Subject: [Mobike] 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_d
> esign.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 protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>