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

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



Your points are very convincing.  The original draft (-00) actually had
a Configuration payload specified.  This was changed to a NOTIFY payload
for the second revision of the draft because of interoperability issues.
 

Most, if not all, ISAKMP implementations would send back an
INVALID-PAYLOAD-TYPE error message when encountering an unknown payload
type.  Since ISAKMP-Cfg is not part of the base ISAKMP spec (nor should
it be) not all ISAKMP implementations will support it.  Thus we had to
come up with a way of not breaking existing implementations.

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?


>-----Original Message-----
>From:	Scott G. Kelly [SMTP:skelly@redcreek.com]
>Sent:	Friday, March 13, 1998 4:05 PM
>To:	ipsec@tis.com
>Subject:	comments on ...isakmp-mode-cfg-02
>
>I have a few comments on draft-ietf-ipsec-isakmp-mode-cfg-02.txt. I am
>not prepared to comment regarding the usefulness of the proposed
>functionality. Rather, I'll confine my comments to the mechanism
>proposed for adding the suggested functionality, i.e. piggy-backing
>'configuration' messages onto the notify payload.
>
>While such configuration messages might be useful, this is *not* the
>best way to add them, and in fact, it looks like a hack. The notify
>messages have been defined for one-way communication of status
>information, while the configuration exchange being proposed is actually
>a 2-way negotiation. Why not suggest a new payload type for this? 
>
>I won't go into all the specific and obvious arguments against the
>suggested payload overloading, as I believe these are self-evident. I
>will, however, point out that the ISAKMP-09 draft contains the following
>text on page 70:
>
>'Because the Informational Exchange with a Notification payload is a 
>unidirectional message a retransmission will not be performed...'
>
>It appears that the design intent is for one-way (unidirectional) usage,
>while the configuration mode suggested clearly requires bidirectional
>communication...
>
>Scott
>


Follow-Ups: