Subject: RE: [Tsvwg] Comment on:I-D ACTION:draft-ietf-tsvwg-sctpcsum-02.txt

From: [email-masked]
Date: Mon, 21 Jan 2002 15:21:18 +0200

Hi Randy,

> Hmm..  I too thought of this when Doug posted the original
> text proposal to the WG.. 
> 
> And it is true that I don't think I would check the V-Tag
> first in my implementation however there is something to the
> fact that a small amount of more overhead processing as
> been added to the protocol... i.e. the difference in
> CPU cost of doing Adler32 and CRC32c... 
> 
> I realize this is a very small amount of difference, but
> an implementor MAY want to use this fact to instead lookup
> the association first and check the V-Tag before going
> to the trouble of computing the CRC...
> 
> So I think it is worth mentioning...(i.e. that is why I
> did not object to Doug's proposal).

I think it is worth mentioning too, I'm just suggesting
moving it from the Security Considerations.

John

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

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 21 Jan 2002 14:32:50 -0600

In certain cases, the alternative approach proposed by Doug may enhance
the endpoint's resistance against flooding attacks - you may need less
computation to discard an attacking packet by checking the V-tag first.
I don't know whether this is the original intention of Doug when he put
this in the security section, though.

-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Mon, 21 Jan 2002 15:41:48 -0600

This is exactly what Doug meant (at least I think) :)

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 21 Jan 2002 16:28:46 -0800

Randall,

I considered an attack designed to consume CPU cycles an aspect of security.
Perhaps this is too broad of an interpretation of what belongs within a
security section.  The method used to verify validity of a packet may
require some considerations to minimize resources (CPU cycles) consumed by
an attack.  As both the V-tag and the Checksum fields must be verified,
should the packet become rejected by the V-tag, there would be no need to
continue further validation.  It is likely an attacker would create a valid
Checksum in a large packet, but would be unable to create valid V-tags but
for exceptions listed with their incumbent overhead advantages as per the
RFC2960 design.  Checksum failures should not represent a high overhead
within valid associations.

I did not intend to suggest how implementations should validate packets or
that this approach would be elegant, only that there may be a computational
advantage in doing so.  That would depend on the relative speed of the
network and the CPU.  Those writing code will likely wish to get Checksum
operations done prior to the V-tag examination to ensure no state is created
as a result of injected errors.  That is a valid consideration and is a
general implementation design based on simplicity.  I would not wish anyone
to think of the security statement as anything but a heads-up for those
systems that may find themselves CPU starved as there are a few extra cycles
added in this checking scheme that may otherwise weaken their resistance.

Doug

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Randall Stewart
> Sent: Monday, January 21, 2002 1:42 PM
> To: Qiaobing Xie
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] Comment on:I-D
> ACTION:draft-ietf-tsvwg-sctpcsum-02.txt
>
>