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

Re: ISAKMP questions

Patrik,

> Dear sirs,
> We have recently decided to use ISAKMP for some of our
> key management. Some problems will raise the need for
> "patches" of the ISAKMP or using functions to solve
> something they were not designed to solve.
> Please excuse me if this has been discussed in some
> other forum as I'm new to this field. If these questions
> have been answered before, please direct me to the answers.
> 
> 1) Dynamic IPs
> 	There is no support in ISAKMP for Dynamic IP
> 	addresses. This is vital for our application
> 	which has mobile PC-clients.
> 	I would like to solve this with additional SA
> 	attributes. Do you have any other ideas how to
> 	approach this problem?

Correct. ISAKMP expects the user/client to have an IP address. I would
expect that DHCP (or a similar protocol) would be executed to get a
dynamic IP address assignment and then, once I have my IP address I
would use ISAKMP to establish the security attributes for
communication with a peer/server.

> 2) Complex SA parameters
> 	SA-attributes handled by ISAKMP are always atomary.
> 	We need an SA attribute of a table form which
> 	contents can be added/removed after the initial
> 	negotiation.
> 	I would like to solve this with additional
> 	Notify message types (ADD/DELETE). Do you have 
> 	any other ideas how to approach this problem?

The SA attributes handled by ISAKMP are defined by the DOI document. In
the case of IPSEC, the SA attributes are handled by the IPSEC DOI I-D.
If someone wants to define a different DOI, then they would also need
to define the SA attributes that are negotiated as part of that DOI.
ISAKMP is not responsible for the definition of the SA attributes, just
the negotiation to establish the SAs which will use the SA attributes.

As for changing the Notify Message Types to add additional
functionality for ADD-ing and DELETE-ing SA attributes, I'll leave that
to the IPSEC WG for discussion.

> 3) It is not clear if additions to the internet DOI
>    violates the DOI specification and a new DOI is
>    needed.
>    Extra SA-attributes are needed. Does this imply a new DOI?
>    Extra exchanges are needed. Does this imply a new DOI?

Using the current structure of documents (ISAKMP, ISAKMP/Oakley, and
IPSEC DOI), additional SA attributes and exchanges would constitute the
creation of a new DOI. However, things are still pretty fluid so ... if
you have requirements for specific SA attributes and/or exchanges which
are appropriate for the IPSEC DOI, then get in touch with the authors
(IPSEC DOI == piper@tgv.com and ISAKMP/Oakley == dharkins or carrel
@cisco.com).
 
> 	thanks/Patrik Sjogren, Sectra AB
> 
> PS: The circular references between chapter 2 and appendix A
>     raises some amout of frustration while trying to understand
>     the draft.

I think you must be looking at ISAKMP-05. There are no references from
chapter 2 to Appendix A in the recently announced ISAKMP-06
(draft-ietf-ipsec-isakmp-06). However, there are several references to
the IPSEC DOI document (draft-ietf-ipsec-ipsec-doi-00).

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* Douglas Maughan                Voice:  (301) 688-0847           *
* Technical Director, R23        Fax:    (301) 688-0255           *
* National Security Agency       E-mail: wdmaugh@tycho.ncsc.mil   *
* 9800 Savage Road                       maughan@cs.umbc.edu      *
* Fort Meade, MD. 20755-6000                                      *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *