Subject: RE: [nfsv4] Updated: checksum extensions I-D

From: Peter Varga <[email-masked]>
Date: Tue, 16 May 2006 09:32:09 -0400

Maybe this will refresh some memories:
http://en.wikipedia.org/wiki/End-to-end_argument
<http://en.wikipedia.org/wiki/End-to-end_argument> 
 
Especially this part:
"According to the end-to-end principle, protocol features are only justified
in the lower layers of a system if they are a performance optimization"
 
Peter

-----Original Message-----
From: Julian Satran [mailto:[email-masked]] 
Sent: Tuesday, May 16, 2006 9:18 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [nfsv4] Updated: checksum extensions I-D

For many that see an end-2-end (client-2-client) protection as the only one
good  in a service world (in which the NFS server is not necessarily
trusted) it is definitely the only mechanism they can rely on (I would not
qualify it as "extra protection"). 

julo 

[email-masked] 

16/05/06 08:22 

To
Julian Satran/Haifa/IBM@IBMIL, <[email-masked]> 

cc
<[email-masked]> 

Subject
RE: [nfsv4] Updated: checksum extensions I-D

I agree with Brent's question: Is the resulting extra protection worth the
effort ? 
- mw 

Sorry I did not make mysef clear _ the previous discussion clarified the
end-to-end nature required for a client checksum - that does not rely on the
server 

Julo 

Brent Callaghan <[email-masked]> wrote on 15/05/2006 22:11:21:

> 
> On May 15, 2006, at 6:40 PM, Julian Satran wrote:
> 
> > Are you purposefully ignoring all previous discussion on the subject?
> > I think that some arguments for the client-2-client integrity where  
> > made and you do not even acknowledge them being made.
> > I find this "erasing of the past discussion" distasteful.
> 
> I'm erasing nothing - my comment is specific to the requirements the
> proposal addresses.
> 
> >
> 
> >
> > kerb5+zFS do not equal zFS storing clent generated checksums (that  
> > might include also keyed criptographic digests) and are
> > not relying on server (nor can they be affected by it).
> 
> Sorry if I didn't make it clear.  If krb5i is used, then data on the  
> network
> is protected.  If ZFS is used, then data on the storage network and  
> media
> are protected.  The checksum extension would provide additional  
> protection
> only while the data are transiting server memory.  So my question was:
> how much extra protection is that ?
> 
>    Brent
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Julian Satran <[email-masked]>
Date: Tue, 16 May 2006 09:58:41 -0400

Ver good summary. Perhaps we should add also that checksum could be made 
unforgeable by have them keyed. Julo

Peter Varga <[email-masked]> 
16/05/06 09:32

To
Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc
[email-masked]
Subject
RE: [nfsv4] Updated: checksum extensions I-D

Especially this part:
"According to the end-to-end principle, protocol features are only 
justified in the lower layers of a system if they are a performance 
optimization"
 
Peter
 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]] 
Sent: Tuesday, May 16, 2006 9:18 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [nfsv4] Updated: checksum extensions I-D

For many that see an end-2-end (client-2-client) protection as the only 
one good  in a service world (in which the NFS server is not necessarily 
trusted) it is definitely the only mechanism they can rely on (I would not 
qualify it as "extra protection"). 

julo 

[email-masked] 
16/05/06 08:22 

To

Sorry I did not make mysef clear _ the previous discussion clarified the 
end-to-end nature required for a client checksum - that does not rely on 
the server 

Julo