RE: [rddp] FW: Analysis of overhead for software implementation o f markers verses key based framing

["Williams, Jim" <[e-mail]>]

 

-----Original Message-----
From: Jim Pinkerton [mailto:[e-mail]]
Sent: Thursday, December 05, 2002 3:55 PM
To: [e-mail]
Subject: [rddp] FW: Analysis of overhead for software implementation of
markers verses key based framing



Below is an analysis that I mailed out a while back to the group that was
looking at the framing issue -  they were trying to select between the
"magic key" based approach (see draft-ietf-tsvwg-tcp-ulp-frame-01 for the
details) verses using markers. 

 

[...]

 

After yesterday's internal review, the conclusion was that a key based
mechanism which includes a hash function based on [srcip, dstip, srcport,
dstport, TCPSeqNum, Len] is preferable to using a marker based approach.
However, this assumes that the application does not somehow discover the
"secret" - the initial sequence number, or ISN. If it does, the probability
of silent data corruption is possibly much less than the chance of silent
data corruption with a CRC. Badness. 

I hadn't heard this one before.  It must have come up after I realized

that framing wasn't as good an idea as I had once thought. :-)

 

Anyway, if I understand correctly, the threat model is an application layer

that discovers the framing layer's secret and embeds that in the payload

Further it must engage in a malicious

conspiricy with a middle-box that agrees to resegment and arranges for

the first resegmented packet to somehow be dropped so that the

receiver won't discover that resegmenting is going on prior to making

a framing mistake.  And for all this effort the application succeeds in 

corrupting its own data.

 

On the other hand, it is plausable that the application is not creating

its own data, but rather receiving its data from multiple external sources

which are mutual suspicious.  At this point the threat becomes 

more concerning as the ability for one such source to corrupt another

sources data is bad.  It does assume that the malicious

source can snoop the packets or otherwise discover the framing layers

secret, but can't inject forged packets.  (If it could inject forged
packets,

that would be a simpler and more direct way to corrupt data.)

 

Hmmm .... I guess this is not a totally bogus argument.

 

How is it that the data source can discover the "secret" but not 

directly corrupt the data?  Perhaps it has read only access to

memory used by framing layer?  Perhaps it has the ability

to snoop packets on the network, but not send them?

 

Perhaps the packets are protected by IPSec authentication

but not encryption?  No can't be that because authenticated

packets can't be resegmented by a middle box.

 

Interesting.  I'll have to ponder this one a bit.