Michael,
Thanks for the response.
iSCSI is a rather stable protocol - existing implementations are expected to
comply with this new spec with little to no change. There is another draft in
the storm WG that is making minor functional additions to iSCSI (given the
number of years since RFC 3720, the amount of change needed is surprisingly
small).
The new spec needs to normatively reference and update RFC 3723 (but there will
be no 3723bis), so it sounds like the right approach is the following
combination:
- MUST implement IPsec, 2400-series RFCs (IPsec v2, IKEv1).
- SHOULD implement IPsec, 4300-series RFCs (IPsec v3, IKEv2).
The MUST is for interoperability and to acknowledge what's out there; the
SHOULD is to encourage implementers to move forward. Now I need to go write
the actual text to go into the draft.
Thanks,
--David
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Tuesday, October 11, 2011 9:42 PM
> To: Black, David
> Cc: [email protected]
> Subject: Re: [IPsec] iSCSI: IPsec requirements
>
>
> >>>>> "david" == david black <[email protected]> writes:
> david> Assuming 2400-series IPsec is not extinct, the appropriate
> requirements may be of
> david> roughly the following form (this is a template, see RFC 3720
> david> or 3723 for the specific
>
> Well, I'm not really sure how to answer your question.
> There is certainly still lots and lots and lots of 2400-series IPsec in
> use. I'd say it was the majority in devices which can easily be
> upgraded, and which aren't because IKEv1 still works well for the
> solution space out there. Certainly IKEv2 is pretty rare on
> smartphones, I'd say for *VPN* connectivity.
> While at the same time, it's required for 3GPP interop (my
> understanding, I never wrote that code myself)
>
> However, we aren't talking about general purpose devices, but rather
> operating systems, HBA cards, virtualization systems (iSCSI clients) and
> NAS (iSCSI targets).
>
> Presuming that none of these devices is going to want to stop claiming
> conformance to RFC 3723/RFC 3720, then they will have to continue to
> implement IPsec-2400 series.
>
> The only advantage to implementing IPsec-4300 series would be on newer
> devices where code space and configuration is an issue, i.e. HBAs.
> It isn't like an IKEv2 speaking endpoint can't recognize and speak
> IKEv1, particularly when it is a responder, it doesn't even cost a round
> trip.
>
> I don't know what other things you are updating in this round, so I
> don't know what other things might drive an implementation to do
> RFC3720bis, but would prevent it from deploying IKEv2.
>
> I therefore think that you should MUST implement 4300 (IKEv2), and MAY
> implement 2400 series (IKEv1). Note that the *ESP* level things, like
> extended sequence numbers that appears in 4300 can be negotiated, so
> it's really not that big a deal to MUST the rest of 4300 stuff in my
> opinion.
>
> All the iSCSI devices that want to support 3723/3720 clients is going to
> support IKEv1. But, if there is a greenfield implementation of 3720bis,
> then they could implement only the much simpler IKEv2.
>
>
> --
> ] He who is tired of Weird Al is tired of life! | firewalls
> [
> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net
> architect[
> ] [email protected] http://www.sandelman.ottawa.on.ca/ |device
> driver[
> Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> then sign the petition.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
