Password changing from behind a NAT

[Ken Hornstein]

>We do not consider this a solution because of the reflection problems.

So, I had to look at this to understand the risks here.

There's a replay cache on the server.  Assuming the client doesn't reuse
a session key (unlikely, I think), there shouldn't be any risk for the
server's response to be reflected back to the server.  So the only risk
here I can see is the client's request reflected back to itself.  

The first two bytes of the expected response are the error code; the
rest is a plain-text error message.  The worst I can imagine here is
that if the requested password was reflected back to the client, the
client would interpret it as a strange error code and error message,
and would think that the password change failed, when it really
succeeded.  That's a risk I'm personally willing to live with.

>My recommendation would be to implement directional address support on
>the server all the time, and to cause clients to send directional
>addresses if they notice they are using a private address and talking
>to something on a public address.  Long term, we can always use
>directional addresses, but that creates interop problems now.

Doesn't really do anything for deployed clients now, though, which
is my real problem.

--Ken