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

RE: comments on ...isakmp-mode-cfg-02

Adding a new exchange type would solve the problem of bumping up the
ISAKMP version number and should not break any existing implementations.
 If the peer implementation does not support that exchange it would
merely send back a "INVALID-EXCHANGE-TYPE" notify error messages.

BTW: If you take a look at draft-ietf-ipsec-isakmp-mode-cfg-00.txt, you
will see that it used a CFG payload as well as a CFG exchange.  So
perhaps we should have kept it that way. ;-)


>-----Original Message-----
>From:	Shawn Mamros [SMTP:smamros@BayNetworks.com]
>Sent:	Monday, March 16, 1998 3:23 PM
>To:	Roy Pereira
>Cc:	skelly@redcreek.com; ipsec@tis.com
>Subject:	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