Subject: RE: iSCSI: IPsec tunnel / transport mode decision

From: "Ofer Biran" <[email-masked]>
Date: Thu, 1 Nov 2001 21:57:08 +0100

No, this issue never got rough consensus. The statement was
put there just to provoke the discussion. And before the thread
of the security draft official positioning is awaken - an effort
will be made s.t. it will not include any normative text that
doesn't match the protocols standards normative text.

   Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
[email-masked]  972-4-8296253

"Saqib Jang" <[email-masked]> on 01/11/2001 19:03:29

Please respond to <[email-masked]>

To:   Ofer Biran/Haifa/IBM@IBMIL, <[email-masked]>
cc:
Subject:  RE: iSCSI: IPsec tunnel / transport mode decision

I thought the latest security draft already closed
on this issue.

From Section 2.3 of -04 draft.
iSCSI security implementations MUST support ESP in transport mode.

Saqib

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Ofer Biran
Sent: Thursday, November 01, 2001 4:31 AM
To: [email-masked]
Subject: iSCSI: IPsec tunnel / transport mode decision

I'd like to drive this open issue into group consensus. It seems to
me that the tendency was more toward making tunnel mode a MUST as iFCP
and FCIP did, mainly due the option of integrating an existing IPsec
chip/box with the iSCSI implementation offering. If we reach this decision,
we may choose even not to mention transport mode (as MAY or some other
recommending text).

There is an excellent analysis made by Bernard Aboba in Section
"5.1. Transport mode versus tunnel mode" of draft-ietf-ips-security-04
( http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt )
that can help us with this decision (also Section "5.2. NAT traversal" is
relevant).

   Regards,
     Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
[email-masked]  972-4-8296253

---

From: [email-masked]
Date: Thu, 1 Nov 2001 15:42:03 EST

My concern is with the requirement that a host MUST support both Tunnel and 
Transport Mode.  A large enterprise most likely has its own VPN today. For it 
to not trust its Intranet is a question they already addressed. Instead of 
imposing another layer of IPSec for the enterprise, we ought to make it easy 
for them to use their existing VPNs for securing transport over the Internet. 

Bottom line, I think we should go with Tunnel Mode, that can be deployed 
anywhere in the customer environment, and leave it up to the customer and 
vendor to determine where exactly to deploy the Tunnel Mode. Transport Mode 
should be Optional and let the market demand vs cost drive its 
implementations. 

Trust the customer! 

Subject: RE: iSCSI: IPsec tunnel / transport mode decision
From: "Bill Strahm" <[email-masked]>
To: <[email-masked]>, "Ofer Biran" <[email-masked]>, <[email-masked]>
Date: Thu, 1 Nov 2001 11:57:21 -0800

Funny because RFC 2401 says (Section 4.1)
"
In summary,
           a) A host MUST support both transport and tunnel mode.
           b) A security gateway is required to support only tunnel
              mode.  If it supports transport mode, that should be used
              only when the security gateway is acting as a host, e.g.,
              for network management.
"

I am assuming that at least one end of the iSCSI implementation is a Host
(if not both ends) and therefore will have a conformant IPsec
implementation...

Now the question is where do we want to allow security endpoints to be.  If
we want to allow only host-host security (and the requisite policy
nightmares) then Transport Mode will work.  However if we want to allow
Tunneling between hosts and security gateways, then Tunnel mode will need to
be used.  In reality I think we should stick with the 2401 requirements,
that way I don't have to write my own implementation...

I have not seen a call of consensus on this issue, have you issued it David
?

Bill
+========+=========+=========+=========+=========+=========+=========+
Bill Strahm     Software Development is a race between Programmers
Member of the   trying to build bigger and better idiot proof software
Technical Staff and the Universe trying to produce bigger and better
[email-masked] idiots.
(503) 601-0263  So far the Universe is winning --- Rich Cook

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Saqib Jang
Sent: Thursday, November 01, 2001 10:03 AM
To: Ofer Biran; [email-masked]
Subject: RE: iSCSI: IPsec tunnel / transport mode decision

Saqib

-----Original Message-----

   Regards,
     Ofer

Ofer Biran

---

From: [email-masked] (Sandeep Joshi)
Date: Wed, 7 Nov 2001 12:55:09 -0500 (EST)

Bill,

> I actually would prefer if we didn't say anything other than a statement
> saying "Here is a policy that will cover IPS traffic" from there it is up to
> compliant IPsec implementations to utilize this policy...
> 
> Being that the WG feels that just specifying a coverage policy is adequate,
> but must get into specifying portions of the IPsec functionality, I would
> prefer Tunnel mode, because as far as I can tell, no one has shown a
> functional e-e transport mode implementation in the wild...
> 
> Can anyone point to one ?

I think Borderware has a bridge proxy which supports 
transport mode but you would need to double-check.

You must be aware of OpenBSD's bridging which came close 
but did not do transport mode, since RFC 2401 requires 
that transport mode must not be applied to IP fragments.  

Anything In the wild..? dunno

-Sandeep

> > From: Ofer Biran [mailto:[email-masked]]
> > Sent: Tuesday, November 06, 2001 11:53 AM
> > To: Bill Strahm
> > Cc: [email-masked]; [email-masked]
> > Bill,
> > I agree that you can make external devices that support transport mode,
> > but it seems that most of those existing today do not support it.
> > 
> > Anyway for our required decision... you also said you prefer tunnel mode,
> > right ?
> > 
> > Regards,
> > Ofer
> > 
> > Ofer Biran
> > > "Bill Strahm" <[email-masked]> on 04/11/2001 21:39:22
> > > 
> > > Please respond to "Bill Strahm" <[email-masked]>
> > > 
> > > To:   Ofer Biran/Haifa/IBM@IBMIL, <[email-masked]>
> > > cc:   <[email-masked]>
> > > Ok,
> > > How does mandatory Transport mode remove the possibility of external
> > > IPsec...
> > > 
> > > I have said before I can make IPsec transport & tunnel mode work in
> > > external
> > > devices, just like you can do SSL/TLS accelerators both internally and
> > > externally
> > > 
> > > Bill
> > > 
> > > Sent: Sunday, November 04, 2001 4:27 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Saqib,
> > > Mandatory transport mode would make bundling of external IPSec
> > > impossible, while tunnel mode is not more difficult to implement
> > > within the iSCSI endpoint than transport mode.
> > > 
> > > "Cost of ownership and complexity of deploying a stand-alone
> > > IPsec gateway" might be among the considerations of vendors and
> > > customers, but I don't think the standard should block such
> > > solutions (and  it blocks more than just stand-alone IPsec
> > > gateway).
> > > 
> > > Regards,
> > > Ofer
> > > 
> > > Ofer Biran
> > > "Saqib Jang" <[email-masked]> on 02/11/2001 20:59:03
> > > 
> > > To:   "Bill Strahm" <[email-masked]>, "CAVANNA,VICENTE V
> > > (A-Roseville,ex1)" <[email-masked]>
> > > cc:   "SHEEHY,DAVE (A-Americas,unix1)" <[email-masked]>, Ofer
> > > Biran/Haifa/IBM@IBMIL, <[email-masked]>
> > > What about the cost of ownership and complexity of deploying
> > > a stand-alone IPsec gateway for use with IPsec end-points?
> > > If transport-mode IPsec is a must-to-implement capability in
> > > iSCSI end-points there is an opportunity to have much
> > > more coherent security for iSCSI.
> > > 
> > > Saqib
> > >

---

From: "Herbert, Howard C" <[email-masked]>
Date: Fri, 9 Nov 2001 12:24:43 -0800

Does this mean that transport mode will be a "MAY" or a "SHOULD"?

Howard

-----Original Message-----
From: Ofer Biran [mailto:[email-masked]]
Sent: Friday, November 09, 2001 10:54 AM
To: [email-masked]
Subject: RE: iSCSI: IPsec tunnel / transport mode decision

It seems that most people prefer tunnel over transport mode
and there is no real opposition for choosing tunnel mode as
the MUST. In view of that we intend to add it in version 09
in the following iSCSI statements:

In Section 10.3.1 Data Integrity and Authentication :

"An iSCSI compliant initiator or target MUST provide data
integrity and authentication by implementing IPSec [RFC2401]
with ESP in tunnel mode [RFC2406] with the following..."

And in Section 10.3.2 Confidentiality :

"An iSCSI compliant initiator or target MUST provide
confidentiality by implementing IPSec [RFC2401] with
ESP in tunnel mode [RFC2406] with the following..."

Any objection ?

  Regards,
    Ofer

Ofer Biran

"Saqib Jang" <[email-masked]> on 01/11/2001 20:03:29

-----Original Message-----

   Regards,
     Ofer

Ofer Biran

---

From: [email-masked]
Date: Fri, 9 Nov 2001 21:47:36 -0500

With my WG chair hat firmly on, I have to say that Paul Koning
is mistaken in asserting the absence of WG rough consensus
for use of IPsec with iSCSI.  The rough consensus in question
is at least 6 months old having been established across 2
interim meetings plus the meeting in London, all of whose
minutes have been reported to the mailing list and all of
which have been accepted without significant objection on
the list.  Paul's objection to this consensus is noted, but
the consensus stands.

The two "MUST"s that Ofer proposed are not only appropriate,
but required - the IESG can be expected to return a document
that does not contain them to the WG in short order.

More on security is coming shortly, but this seemed important
enough to put in a message by itself.

Thanks,
--David

> From: Paul Koning [mailto:[email-masked]]
> Sent: Friday, November 09, 2001 4:43 PM
> To: [email-masked]
> Cc: [email-masked]
> I'm not sure if this is the sort of answer your question was looking
> for, but I don't want to let silence be taken for agreement, so...
> 
> I'm opposed to the presence of "MUST" in sections 10.3.1 and 10.3.2
> for reasons stated in mail to this list a week or two ago.
> 
>     paul
>

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 10 Nov 2001 10:51:38 +0200

SG,

You must have one of them MUST to ensure interoperability.

Julo

Sukanta ganguly <[email-masked]>
Sent by: [email-masked]
09-11-01 21:07
Please respond to Sukanta ganguly

        To:     Ofer Biran <[email-masked]>, [email-masked]
        cc: 
        Subject:        RE: iSCSI: IPsec tunnel / transport mode decision

By doing this we are forcing IPSec. No flexibility of
going transport over tunnel. I think we were still
having a discussion of whether transport can also be
supported and hence instead of forcing with IPSec
can't we allow both mechanisms to a MAY.

In that scenario one could opt for transport mode with
tunnel and still have a good implementation running.
What do other think?

SG

--- Ofer Biran <[email-masked]> wrote:
> data
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Ofer Biran
> (
http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt
> )

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

---

From: "Ofer Biran" <[email-masked]>
Date: Sun, 11 Nov 2001 11:40:40 +0200

Howard,

In my opinion we only need a MUST on one mode and algorithm
to ensure interoperability. This doesn't rule out implementation
and use of transport mode. I don't think putting a MAY is necessary -
the only reason for MAY (RFC2119) is forcing each side to expect that
the other side might offer this option. Transport mode offering is
well defined in the IKE negotiation and the responder chooses the
desired SA, a one which it supports of course, or denies. So I think
we have an implicit MAY for transport mode and any other (and future)
algorithm by the IKE negotiation and by not saying MUST NOT or
SHOULD NOT use.

  Regards,
    Ofer

Ofer Biran

"Herbert, Howard C" <[email-masked]> on 09/11/2001 22:24:43

Please respond to "Herbert, Howard C" <[email-masked]>

To:   Ofer Biran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: iSCSI: IPsec tunnel / transport mode decision

Howard

-----Original Message-----
From: Ofer Biran [mailto:[email-masked]]
Sent: Friday, November 09, 2001 10:54 AM
To: [email-masked]
Subject: RE: iSCSI: IPsec tunnel / transport mode decision

Any objection ?

  Regards,
    Ofer

Ofer Biran

-----Original Message-----

   Regards,
     Ofer

Ofer Biran