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

Jari Arkko wrote:
> 
> 
> 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

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, 
> you can skip the test

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

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

sounds good.

Vijay