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

Re: Which comes first?



Dan,

 > Well since PF_KEYv2 is not an IPSec draft and the authors of PF_KEYv2 chose
 > to define their own monolithic, one-dimensional number space instead of
 > using IPSec-approved DOI values (and including a DOI-type field in the 
 > sadb_sa struct to multiplex things like IPSec and RIPv2 in exactly the same 
 > manner that ISAKMP can) and since they chose to impose unnecessary 
 > restrictions on the behavior of ISAKMP/Oakley I'd like to know why PF_KEYv2 
 > implementations (still haven't seen one yet) should have _any_ impact on 
 > IPSec documents.

Agreed that PF_KEYv2 is not a working group item and that its
particulars should not be discussed here until it is, or (more likely
since this group is supposed to wind down) in some other group.

I only wanted to point out that implementations of ESP may not take a
single blob of keying material from KM, even if the effect "on the
wire" is that way from your viewpoint.  I was just using PF_KEYv2 as an
example and didn't mean to start a discussion about it in particular,
it could have been any implementation.  Sorry.

(As far as PF_KEYv2 implementations, I have one and would be
all-too-happy to build PF_KEYv2-using code against it.  I can't show you the
kernel source, thats proprietary.  From Michael's note it appears that he can
show you an example PF_KEYv2 implementation and he works at your
company.  :-)   BTW, I too would like to see some mods to PF_KEYv2 to fit
other IPSEC stuff better.)

 > If you're talking about where to slice-and-dice I can honestly tell you 
 > that mine is the One True Religion and yours is heretical. If you're
 > talking about where the text should go then since ESP does both auth and
 > encrypt it would make sense to inform the implementor right there about
 > what goes first without having to context switch to another document-- it's
 > hard enough jumping from document to document as it is. Nothing in that text 
 > suggests that slicing-and-dicing must be done in any particular place. It 

I was concerned primarily about the text location and implementation
flexibility.

Putting the text into the ESP doc is acceptable to me, I can see where its
handy for informing the implementor and I fully desire your
interpretation in the last sentence above.  I take it that you don't
have any objection to my "single injection of keying material"
qualification to make that interpretation clearer to me and probably
others?  Other text could clarify it as well, perhaps better.

 > 
 > Yes, Ted, this is what all interoperable implementations have been doing.

If "interoperable" excludes manual keying as I suspect you mean, then I
can't disagree with my current implementation and testing experience.
And I can't speak for others.  However, I have interoperated ESP via
manual keying, injecting separate MD5 & DES keys, with an ANX-active
vendor who could do both manual keying and ISAKMP/Oakley.  And I'll
have an opportunity to do more next week at the ANX IPSEC workshop.
And I expect to have ISAKMP/OAKLEY using my implementation be interoperable
as well in the near future.

Since we're specifying protocols, not interfaces, I don't see anything
wrong with leaving implementation flexibility to those parties coding
both their own ISAKMP and ESP implementations (where they *can*
slice/dice wherever they want to) rather than saying (paraphrased,
which was *my* interpretation of Karen's text) "an ESP implementation
will split auth/encrypt keys from keying material in this manner since
ESP always gets material in a single blob".  If my clarification request is
heresy, so be it...
                        
                         
   -- Marc --