[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on ...isakmp-mode-cfg-02
> This same converstaion has gone on for a couple of weeks off the mailing
> list as well, so I'd like to propose the following:
>
> 1) A separate Config payload is defined.
> 2) Support for ISAKMP-Cfg is denoted by a ISAKMP version of 1.1 or
> higher. Support does not mean you actually use it, just that it does
> not break your implementation.
>
> Comments?
If Config becomes a separate payload type, then we're also going to need
a new exchange type to deal with any exchanges of config info that
happen after Phase 1 completes, such as those required for extended
authentication (draft-ietf-ipsec-isakmp-xauth-01.txt). The Informational
exchange no longer applies, and we aren't allowed to extend either Main
or Aggressive mode, so it seems a new Config exchange is necessary.
Actually, I'm wondering now if adding a new exchange might eliminate the
need to "bump up" the ISAKMP version number(s), as it seems to me that
going to 1.1 might cause its own set of interoperability problems. That
would mean that we couldn't put Config payloads in Phase 1, but that might
be a small price to pay to avoid problems with the version number. How
would most implementations handle an unrecognized exchange type?
-Shawn Mamros
E-mail to: smamros@BayNetworks.com