[Openswan dev] Re: out_sa in spdb.c

D. Hugh Redelmeier hugh at mimosa.com
Wed May 12 03:36:14 CEST 2004


| From: Michael Richardson <mcr at sandelman.ottawa.on.ca>

| DHR, I have been looking at the algo patches to spdb.c, in the out_sa()
| function.

I've not looked at the algo patches.

I'm looking at the last FreeS/WAN cvs (that I have).

|  But that's not the query I have.

| The code does:
|     for (pcn = 0; pcn < sadb->prop_conj_cnt; pcn++)
|     {
| 	for (pn = 0; pn < pc->prop_cnt; pn++)
| 	{
| 		/* determine macro pieces of proposal */
| 		for(tn = 0; tn != p->trans_cnt; tn++) 
| 		{
| 			/* generate transforms */
| 		}
| 	}
|     }
| Now, we can have multiple conjuctive (OR) proposals. I.e. we can propose
| ESP || AH, for instance. So the outer loop makes sense. For IKE SAs
| there is only one choice anyway.

My comments are not as clear as I'd like.

IKE specifies:

	An SA payload contains a sequence of Proposal Payloads.

	Each Proposal is given a Proposal Number.

	The Proposals are numbered monotonically (non-decreasing).

	Several proposals in a row can have the same number!

	Proposals with the same number are conjoined:  All apply
	together (think ESP + AH + IPCOMP).

	Proposals with distinct numbers are alternatives.

| However, what is the second (pn) loop for?

pcn is the Proposal Number and as such indexes among conjunctions.

pn is the index within a conjunction.

Have a look at the tables supplied.  The tables are laid out bottom-up
because of the way C scoping works.  Actually, look at an earlier
version, before AH was ditched (FreeS/WAN 2.05).

| Pluto doesn't permit multiple IKE or ESP proposals. Multiple transforms
| within the proposal, but not multiple proposals. And the references to
| IKE documents that forbid this seem quite sensible.

The structure of the SA Payload for negotiating an IKE SA is much
simpler than the structure of the SA Payload for an IPsec SA.  You
could think of the one for IKE as being degenerate.  out_sa works for 
both kinds.

| So the question is, what is the pn loop for? It seems that we can never
| have more than one proposal anyway, and pc->prop_cnt is never > 1 in
| the policies in spdb.c that I can see. 
| Is it just dead logic, or is there some hidden purpose that I'm missing?

Not dead logic.  But some isn't exercised with existing table entries.

I no longer have access to the CVS, so I cannot say what happened
when.  But in FreeS/WAN 1.6, in certain cases there were alternatives
(ESP with no encryption was an alternative to bare AH).

This would also be a mechanism to allow for optional compression
(which we decided not to do yet).

Hugh Redelmeier
hugh at mimosa.com  voice: +1 416 482-8253

Version: 2.6.3ia
Charset: noconv


More information about the Dev mailing list