Subject: RE: [rddp] CRC - rough consensus update

From: "Williams, Jim" <[email-masked]>
Date: Mon, 2 Jun 2003 12:33:03 -0400

Caitlin Bestler wrote:

> But we have to be very careful to make certain that the
> costs do not grow. Most importantly, ULP designers must
> have no doubts that they are guaranteed end-to-end CRC32c
> protection.

I am a bit concerned with confusing service with mechanism.
The service provided by the transport is reliable delivery.
The mechanism is the number of bits of CRC or checksum.

If one wants to quantify reliability, a good metric might be
Mean Time Between Undetected Error.  Should the ULP be
allowed to specify MTBUE to the transport (or MPA) and
have the transport adapt the checksum or CRC to this
requirement?  I think this is a bad idea, but I think
having the ULP specify (explicitly or implicitly) the
need for a CRC is even worse.

> I sense a strong concensus for allowing CRC suppression when
> the network truly provides the equivalent of end-to-end
> CRC32c protection. The strongest scenario for this is when
> most of the path is over IPSEC.

That's surprising, my reaction is exactly the opposite.
I would regard the risk of IPSEC hardware/software/firmware
bugs causing data corruption as far greater than the risk
of data corruption on a vanilla TCP connection.  I would
be much more inclined to keep the CRC on when IPSEC is
being used.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 2 Jun 2003 12:25:07 -0500

On 6/2/03, Williams, Jim wrote:

>If one wants to quantify reliability, a good metric might
>be Mean Time Between Undetected Error.  Should the ULP be
>having the ULP specify (explicitly or implicitly) the need
>for a CRC is even worse.
>
Agreed. But I would simly state it as "or equivalent",
rather than drafting a mathamatical definition. For one
thing, equivalence has to be measured relative to the
actual error charateristics of the underlying L2 networks
and hop points. I wouldn't want to penalize an L2 error
detection/correction scheme merely because it was well
adapted to that link's actual characteristics. That is
especially true when you consider that some links have
error correction, not just error detection. Coming up
with an equivalence formula that applied to *all* networks
would be a monumental undertaking.

>> I sense a strong concensus for allowing CRC suppression
>> when the network truly provides the equivalent of
>> end-to-end CRC32c protection. The strongest scenario for
>> this is when most of the path is over IPSEC.
>
Interesting point. Because an "IPSEC hop" manipulates the
payload there is admittedly a higher chance that it would
mismanipulate it. But I believe that this is a highly
theoretical risk.

Any good cryptographic cipher is already engineered to make
it nearly impossible to end up with anything that "almost"
resembles the true payload. The goal is that even a one bit
error in the key will continue to produce gibberish. If this
is not true, the cipher is vunerable to differential attacks
which allow probing for the correct key one bit at a time.
A good cipher provides zero useful information when the
incorrect key is supplied, even when the key is "close".

The rationale that has been offered for viewing IPsec as
"safe" is that it has its own end-to-end protection. That
rationale would also apply to many forms of IP tunneling,
including ATM and IPoverIB.

But in the spirit of the proposal, it would be up to the
network administrator to determine whether they viewed
the IPsec tunnel to be a single reliable link or not.
Ultimately, the real test is that there are a very small
number of highly reliable links, each with their own
highly reliable error detection (and/or correction).
In that sense, IPsec is not really different, it is
just that it can be viewed as a single link.

Now if the cryptographic algorithm in use is in any way
at risk, then its not a highly reliable link. But I would
think that an unreliable IPsec link would have been tossed
in the trash long before any RDMA applications showed up.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: [email-masked]
Date: Tue, 3 Jun 2003 00:15:41 +0000 (UTC)

> need for a CRC is even worse.

The problem is that if we talk about MTBUE, we have to cast everything to
a very strong mathematical basis. While the fact that we can is important,
it's not easy to cast the status of a live system into the numbers the
math would need, so it would be very hard to actually use such a metric in
practice.

So if no one will be likely to use it, we should try to describe things a
different way. :-)

> be much more inclined to keep the CRC on when IPSEC is

Interesting. What IPsec stacks are you familiar with? The ones I've used
haven't left me with that impression.

Take care,

Bill