Re: [Ipsec-tools-devel] NAT-T transport mode and per-port policy broken again

[<ar...@na...>]

Hi,

Paul Wernau <Paul.Wernau@Sun.COM> writes:

> I was trying to run some tests from CVS HEAD on Linux (Ubuntu 9.04
> 64-bit) and was running into problems with per-port policy and NAT-T in
> transport mode again.
>
> The NAT-T port 4500 was getting copied in for the negotiation instead of
> what the policy said.
>
> I had to set them explicitly in pfkey.c, as attached.  I am sure this
> patch is naive and missing something given the code below it but it
> points out the problem.
>
> Shouldn't we always be using the security policy src and dst (sp_src,
> sp_dst) in this situation, since they contain the ports from the policy?
>
> Thanks,
> Paul
> --- pfkey.c.orig	2009-07-31 12:06:46.000000000 -0400
> +++ pfkey.c	2009-07-31 12:05:46.000000000 -0400
> @@ -1821,10 +1821,12 @@
>  		dst = (struct sockaddr *) &sp_out->req->saidx.dst;
>  	} else {
>  		/* Otherwise use requested addresses */
>  		src = sp_src;
>  		dst = sp_dst;
> +		sa_src = src;
> +		sa_dst = dst;
>  	}
>  	if (sp_out->local && sp_out->remote) {
>  		/* hints available, let's use them */
>  		sa_src = src;
>  		sa_dst = dst;

I won't say I can help wrt NAT-T logic as I am not an expert on the
feature, but I can comment on what that part of the code is trying to 
do, address-wise.

It deals with three kind of sockaddr: src, sp_src and sa_src (and
their *dst counterparts):

 o src/dst represent IKE addresses, i.e. the source and destination
   addresses used by the daemon for the negotiation 
 o sa_src/sa_dst represents the source and destination addresses for the
   negotiated SA *when* they need to be different from the IKE addresses.
 o sp_src/sp_dst represent the addresses from the SP as received from
   the kernel during the acquire.

For transport mode, the sockaddr provided by the ACQUIRE are used as
source and destination for the IKE exchange. This is the 'else' block
that you modify in your patch. The associated 'if' part of that block
logically uses the endpoints of the tunnel as source and destination for
the IKE negotiation when a tunnel mode SP is being negotiated.

The only very specific case when there is a need for sa_src and sa_dst
to be set to a value different than the addresses is when the
negotiation will be done between two addresses of both peers but in
order to setup a set of SA that will use other addresses of those
peers. Mobile IPv6 security protection bootstrapping requires that
*very* specific kind of trick (Care-of Address of the MN used for the
nego of SA that reference the Home-Address).

In the end, I think your modification may make things work for your
NAT-T configuration but possibly due to some side effect. Is it possible
that you managed to trigger the following code in quick_i1send()
(isakmp_quick.c): 

  id = (struct ipsecdoi_id_b *)iph2->id->v;
  id_p = (struct ipsecdoi_id_b *)iph2->id_p->v;
  if (id->proto_id == 0 &&
      id_p->proto_id == 0 &&
      iph2->ph1->rmconf->support_proxy == 0 &&
      iph2->sa_src == NULL && iph2->sa_dst == NULL &&
      ipsecdoi_transportmode(iph2->proposal)) {
  	idci = idcr = 0;
  } else
  	idci = idcr = 1;

Anyway, I think I will let Yvan or Timo handle that NAT-T issue and find
the appropriate fix.

a+