RE: DRAFT San Diego minutes

Somesh,

It is not a question of basic principles but rather one of wording.
BTW IPsec suffers from a similar problem - no appliaction above has any 
way of knowing if it running on IPsec or not and I understand that for a 
large class of applications that is unacceptable and that is why TLS is so 
popular. IPsec going to fix this (I hear) through some channel binding 
mechanism. In the absence of such a mechanism the best iSER/MPA could do 
is strengthen wording as was suggested (and perhaps allow for some later 
fix if bonding becomes standardized - bonding involving API's).
And yes it is an administrative issue - but the administrator must have 
its tools (i.e., the mandatory to implement stuff).


Julo



"Somesh Gupta" <[email protected]> 
12/08/04 22:28

To
Julian Satran/Haifa/IBM@IBMIL, <[email protected]>
cc
<[email protected]>
Subject
RE: [rddp] DRAFT San Diego minutes






Julian,
 
I think there is some validity to Jim's point. Maybe the application is
satisfied if there is end-to-end IPSec instead. And although there is
a point of how does the application know, it is really the administrative
policy that determines what level of reliability is good enough or not.
 
Somesh
-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of 
Julian Satran
Sent: Thursday, August 12, 2004 6:58 AM
To: [email protected]
Cc: [email protected]
Subject: RE: [rddp] DRAFT San Diego minutes


The reasoning behind this requirement was  that an I_T pair may  want to 
negotiate CRC (or equivalent) as an e2e guarantee but have no way of doing 
that if they use iSER. 

Does it still look (or smell) as a red herring? 

Julo 


[email protected] 
Sent by: [email protected] 
11/08/04 17:48 


To
<[email protected]> 
cc

Subject
RE: [rddp] DRAFT San Diego minutes








> iSER is a protocol that uses MPA (RDDP mapping to TCP) for iSCSI.
> The iSER draft authors have found MPA's current CRC requirements text
> to be insufficient for iSER usage of MPA, and hence currently impose
> stronger requirements.  iSER requires that RDDP provide at least
> CRC32-class integrity, but the current MPA draft text allows CRC32C
> to be disabled in situations where that would not be the result.
> 
> The RDDP WG's rough consensus has been that ULPs can assume at least
> CRC-class integrity from RDDP.  Hence the sense of the room is that the
> MPA draft text needs to be tightened to do this and remove the need
> for iSER to add requirements to MPA.

This smells like a red herring.  CRC32 is not a class of integrity,
it is a mechanism for providing integrity.  Quantifying integrity 
should be done with metrics like mean time between undetected
failure or mean GB of data transferred between undetected failure,
not bits of CRC.  RDDP should provide the ULP with a guaranteed 
level of integrity, not guarantee a mechanism for providing it.

The case that iSER requires a higher level of reliability that
iSCSI or NFS seems like a difficult case to make (but since I
wasn't at the meeting, perhaps it was made effectively).  iSCSI
and NFS do not require mandatory CRC.

I suspect that the real reason is that all planned implementations
provide CRC for free, and options are a pain.  However this it
not a bad argument, so I am not troubled by the conclusion.

> --> Important Security Issue #1: IPsec - required or optional?
> 
> A lengthy discussion ensued on this topic.  Important points:
> - For optional: IPsec can involve significant hardware complexity.
> - For mandatory: Some attacks can only be mitigated by IPsec (WG has
>                  little interest in designing its own security 
mechanism), and
>                  they will be of concern in some deployment 
environments.

OK, I'll be politically incorrect.  Running RDMA over IPsec is
sufficiently stupid that NOBODY will implement IPsec regardless of
how mandatory it is.  Just make it mandatory and quit worrying.

_______________________________________________
rddp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rddp

_______________________________________________
rddp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rddp