[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: peer address protection and NAT Traversal

 In your previous mail you wrote:

   > So what I'd like to propose is that IPsec SAs *not* try to survive
   > mid-connection NAT renumberings. That an IP address and UDP port be
   Mobile IP people may not like this very much at all.
=> this was discussed privately between some mobile IP people
and we concluded this is too unsafe. But something is still needed
(an explicit mechanism).

   > I'm out of my depth here. What do existing implementations do? Do they
   > support mid-connection renumbering or are they subject to the DOS
   > Is there a known better fix?
   We support recovery from floated NAT entries and this is what we do.
    We use a three-way handshake to exchange the information required for
   NAT traversal. This significantly reduces the potential threat mentioned
   by Francis, but does not completely eliminate it. 
=> three-way handshake == return routability check, i.e., you check the
peer can receive packets to its claimed address?

   A better solution IMHO would be:
    To 100% protect against the attack mentioned by Francis if NAT vendors
   put a mechanism by which those behind the NATs can query the NAT WAN
   interface address. Then the devices behind NAT can compare this address
   with the perceived address by the remote sites (echoed back securely)
   and completely neutralize these attacks. This is true only if there is
   one NAT in-between and I think it is true for majority of cases. 
=> first we'd like to get a passive NAT traversal feature (no midcom),
second I am afraid the one NAT constraint is too strong (i.e., it works
only in some countries).

     In lieu of this, one can make multiple queries to several sites and
   check them for consistency. This is a heuristic approach and only
   reduces the threat, but does not eliminate it.
=> I don't believe we should reduce the threat by expensive mechanisms.
My proposal is to give the choice between to be immune and to get
NAT traversal support. So we need a swicth in configurations,
a way (a new notification?) to required peer address protection
(already provided by NAT-DETECTION-{SOURCE,DESTINATION}-IP) and
an error (another notification) when NAT is detected but not supported.