[Openswan dev] Re: out_sa in spdb.c

[D. Hugh Redelmeier]

-----BEGIN PGP SIGNED MESSAGE-----

| 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

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBQKHF68FAuQPManGZAQHnWgQAruXWle2sw/kWxBP/nNtS8ywaCkhTzNo7
3UqCa+E8s7/1cdRb9FDrj0wRYcpEqltiOK3kWHNf077qS8FST5F6B85n2dQACup8
PqeFas12gPnLwLLHrWzgNmylvihF0PbD9XsZsf09Z79+44mX+8Yjobsew/3OfmAK
K7C8kNstcl0=
=akhk
-----END PGP SIGNATURE-----