Re: [Ipsec-tools-devel] ISAKMP IDs screwed up?

[<uri...@op...>]

> And I'll add such cleanup to the TODO list as soon as we'll set up
> this TODO list (another discussion in progress :-).
> 
> ["trivial" (but still need some work :-) part]

Finished. Patch submitted in the previous email. It works fine with Win XP client over double NAT. So I'm satisfied with the solution as is.

> Well, it may be quite stupid to do the "easy" part if other people
> won't ever do the "hard" part, but on the other hand, if the "easy"
> part is easy to do, we can do it and hope it will motivate other
> people to do other parts...

The "easy" part has to be done regardless, in order for the entire thing to work. So the smart thing to do is to finish the easy part, and then either attack the hard part, or wait until somebody else does it.

As one of the "easy" things that I haven't done - please consider adding pasring of NAT-OA payload and filling the  "Struct ph2natt *natt" in the iph2.  We'll see how to proced from there.

> I myself don't care about NAT-T / transport mode, but I'm still trying
> to help you as I can :-)

:-)  Great!   I've finished NAT-T/Transport for Racoon in Responder role.
 
> The idea is to at least remember there are other possibilities, 
> and to
> make choices that will not generate problems when other people will
> want to implement other possibilities.

I'm sure my solution won't cause problems - because I explicitly limited it to the case it deals with [by if() and #ifdef].

> As I said just upper, I'm ok with this kind of works, as soon as it
> does not involves solutions which makes problems later, when other
> guys will work on other situations.

:-) Understand. 
 
> > > If we are starting to support NAT-OA / NAT-T in transport 
> mode, we
> > > should do it for all situations, including situations where we 
> do NOT
> > > have generated policies.
> When I am talking about "generated policies", it means "policies
> generated by racoon, with the generate_policy option".

Well, the real problems with the existing Racoon code are:

1. It aborts processing upon seeing NAT-OA payload instead of either parsing it correctly or just ignoring. My solution ignores this payload, but continues processing.

2. It generates wrong policies for NAT-ed Transport. My solution changes one address and teo ports for this case.
 
All the other parts (such as sending NAT_OA, in order for Linux to be a client in NAT-ed Transport) are still to be done.

> In fact, with transport mode/ NAT on the way, you NEVER have to know
> peer's private IP address, except for checksums stuff.

Precisely. And that applies only to ISAKMP Phase1, I think.
 
> So your SPD entry with peer's public IP address is right !

> Regarding this information, we should probably change the code for
> policy generation to: "for remote traffic endpoint, use ph2 Ids for
> Tunnel mode, use peer's public address for Transport mode".

Yes, I think so.
 
> If you have an "imperfect patch" that will probably "just" need to be
> ehanced when people will need a better solution, I think it's ok.

I believe that's what I just posted. Actually, let me post it again.  :-)


> [Initiator]
> 
> > I don't know if initiator can have "generate_policy on". I tihnk he
> > can't.
> 
> It would at least be strange for initiator to use generate_policy
> option, and if I rememeber well, the code only works for responder
> side.

And for initiator - the only thing it needs (AFAICS) is sending [NAT-OAi, NAT-OAr] with ISAKMP_QUICK messages.

No big deal.