[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt
Ken,
Comments below...
> -----Original Message-----
> From: Ballou, Ken [SMTP:kballou@quarrytech.com]
> Sent: Wednesday, September 06, 2000 8:16 PM
> To: ipsec@lists.tislabs.com
> Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt
>
> Overall, I think this is a good idea. It's extremely useful to be able
> to avoid the overhead of a separate ISAKMP SA for each VPN.
>
> But, I'm a little surprised to see that you're defining an entirely new
> DOI, rather than extending the IPsec DOI. Is that because there is no
> provision for a DOI version number?
>
There is no DOI version number but there is a DOI number. I believe you are
differentiating DOI version numbers from DOI numbers by implying that a
higher version automattically supports all extensions defined in lower
versions while that's not automatically assumed with DOI numbers. Well,
that's why the VPN DOI inherits the existing DOI: to be just like a version
2.
Regarding extending the existing IPsec DOI, there are many implementations
out there which are using the existing DOI and changing it would cause a
major impact and I don't think is feasible. A new DOI is OK because ISAKMP
dictates what to do with negotiations that request a DOI which you do not
support.
> I'm concerned because I can envision multiple DOIs derived from the IPsec
> DOI, all differing ever so slightly. For example, this draft adds new ID
> types. Another DOI might add a new security protocol (other than AH and
> ESP). Now, what happens when an implementation wants to support both
> extensions?
>
Well, the application can negotiate some phase 2 SA's using the VPN DOI and
others phase 2 SA's with the NewProtocol DOI.
> Is it feasible to extend the IPsec DOI? If ISAKMP is ever revisited, is
> there a possibility of adding a version field to the security association
> payload?
>
If ISAKMP is ever revisited...
> - Ken
>
Claudio
Follow-Ups: