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

more...changes to ISAMKP/Oakley




Daniel Harkins writes:
>   I received another unicast email in which the author raised an issue
> regarding the use of the DOI in ISAKMP/Oakley.
> 
>   Right now we have just the IPSec DOI. Eventually (I hope), we'll have
> the SNMPv3 DOI, the BGP DOI, the RIPv2 DOI, etc. Any service that needs
> an authenticated key for whatever purpose can defined a magic number 
> range, claim a DOI value and we're off....
> 
>   With that in mind the issue is one of crossing one's streams so to speak.
> If I initiate an exchange for IPSec I'm gonna set the DOI field of the
> phase 1 offer to the value for the IPSec DOI. Then when we negotiate the
> actual IPSec SAs I do the same. But what if we negotiate "SAs" for the
> BGP DOI. We're doing that under the protection of the ISAKMP SA that was
> created with the IPSec DOI. Problem? I dunno. This has been raised as a
> problem though.
> 
>   So, I'd like to make a proposal for a change. I haven't made the change
> and I won't unless I get some backing. 
> 
>   The ISAKMP/Oakley draft will define a DOI value of 0 as being perfectly
> acceptable for phase 1 offers. In that case the situation is similarly 0.
...

As the author of the unicast email in question I am, of course, in favor
of seeing this change.  I would suggest, on top of this change, adding
an additional document to the group of "near standards track" drafts.
This document would outline an ISAKMP/Oakley DOI, for use in negotiating
Phase 1 ISAKMP/Oakley SA's.  If there is enough support, I'd be more
than happy to write such a document myself.

If this is an acceptable move to the group, I'd like to further suggest
that the IPsec DOI and ISAKMP/Oakley documents be modified to deprecate
the PROTO_ISAKMP number and to suggest that the Phase 1 negotiation of
the ISAKMP/Oakley SA be logically detached from the negotiation of the
IPsec SA.  I have been bothered that IPsec itself has to do the work to
negotiate the ISAKMP SA (which should be logically different modules)
which provided the essential motivation for this suggestion.  I know
that we are not supposed to change bits on the wire, so it seems that
the best we can do is to deprecate the value with the hope that it will
eventually weed itself out.

Comments?

ben



References: