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

Re: Adding revised identities to IKEv2



 In your previous mail you wrote:

=> I've just reread the pki draft so I propose to use the term
"peer source address" for the address you said it is validated
by the signature... a point I disagree about.

   >=> the cookie is built by the other peer so the only effect is the
   >addresses must remain the same between all packets of a phase,
   >a check which is currently done even between phases.
   >Can you explain how cookies can forbid an attacker to change en route
   >or as the peer to put a rogue address in all messages?
   
   If the cookie is a part of the signed contents, then changing IP address
   of a packet during IKE exchange will invalidate the signature and will
   be detected.
   
=> yes, this is the function of the cookie. But the cookie doesn't
provide any protection against a rogue address in all packets of
an IKE exchange.

   Of course "invisible" denial of service is always possible... I don't know
   whether anything can be done to defend against it.
   
=> if the address is changed en route, it is enough to include it
in something covered by the signature. If the peer itself cannot be
trusted another mechanism is needed.

   Later on, IP addresses used are those stored in SA, so if a cryptographically
   "valid"packet comes from a "wrong" IP address, it's local policy matter what
   to do with it...
   
=> with a proper flexibility about addresses, this will make the "wrong" IP
address "right"... Note this only solves half of the problem of mobility
or multi-homing because SAs are negociated by pairs and the SA in the other
way will get the new address only with explicit signaling (I can develop
this point if someone is interested).

   A peer can put any IP address it wishes (of course), but why would it
   do it - it's already free to advertise any address it chooses.
   
=> I fully agree about outer addresses in IPsec SAs (even I know
a lot of implementations which drop packets with an unexpected
source address). But about the peer source address in IKE, things
are less obvious:
 - end-to-end protection (safety against some DoS attacks using
   IKE to redirect traffic) or not (NAT-traversal capability)
 - same address during a whole exchange (with the consequence
   that one-one exchange should be transformed in longer (i.e.,
   using more messages) exchange to get a return routability
   check... Not a new idea, remember the optional-cookie-when-
   under-attack)
 - capability according to a policy to change addresses between
   two exchanges (IKE-SPI is here for that!)
 - a new readdress exchange, etc.

Regards

Francis.Dupont@enst-bretagne.fr