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

Re: Death to AH (was Re: SA identification)

 In your previous mail you wrote:

   > I think the only strong argument is the authentication of random CNs
   > and this is not really a technical argument.
   
   The issue is not authentication of correspondant nodes;

=> argh! I mean by (but as the authentication is symmetrical this is both
of and by).

   it's one of
   (possibly pseudonymous) authentication of the mobile nodes to the
   correspondant nodes.  This could be accomplished within IPsec using
   self-signed pseudonymous certificates if CN's which accept binding
   updates were prepared to accept them; there's fundamentally no reason
   why something like PBK's couldn't be used with IKE/IPsec.
   
=> self-signed certificates are perhaps a bit too weak (this is a matter
of policy/authorization and mobile IPv6 has some problems with that.
Of course the trivial solution (use real good certificates) is not
deployable).

   I see a more fundamental problem here with piggybacking binding
   updates on to regular traffic..
   
=> there is no possible fundamental problem with an optional feature.
But I agree the piggybacking gains a packet at the cost of far more complex
implementation (so my code never sends piggybacked BUs but accepts them).

   There's a poor interaction between the AH-only-on-binding-update and
   what I'll call opportunistic use of AH..
   
   Several IPsec host implementations (solaris among them) implement a
   concept known as policy latching.. namely, that policy on a wildcard
   port/socket may be "flexible", but once a particular connection is
   established, the policy is "latched" to a particular value so that
   (for instance) once a connection is established with IPsec protection
   you cannot then hijack it with unauthenticated traffic.
   
   So, in the MIP case, you send a BU + TCP SYN, all authenticated with
   ah.  The receiving node's TCP notes that the SYN packet is AH
   protected, and accordingly requires *all subsequent traffic* on that
   connection to be AH-protected.
   
   The problem here is that AH authenticates both the BU option *and* the
   packet as a whole, and it's not possible to tell the intent of the
   sender from the packet headers.
   
=> I understand your concern and the solution is to throw away one
alternative and in this case I believe the best is to drop the TCP SYN
if there is an ambiguity... (ie. as usual the upper layer will retransmit it)
I believe the rationale of this bad idea (piggybacking) is to send BUs
when an outgoing packet is sent (if this is in this is just when...).

BTW with a dedicated security I believe the piggybacking feature for
BUs and BAs will be withdrawn. No regret!

Regards

Francis.Dupont@enst-bretagne.fr
References: