Subject: RE: [Tsvwg] sctp error check

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Jun 2001 11:22:31 -0400

At 11:01 25/06/01, [email-masked] wrote:
>        I understand your concerns. But, as far as I know, the
>interoperability problems occur when something is optional. 

        Not strictly speaking.  UDP checksums are an example of 
something that isn't supposed to be optional, yet is an 
interoperability nightmare in practice in a different transport-layer
protocol

>This proposal is
>not something optional, nor negotiable, it is just a different way of
>processing the SCTP packet upon its reception... 

        However the proposal will have the same interoperability
issues around it that have occurred with other IETF protocols
in the past.  

>        I think we are stopped at some point of the discussion because
>people prefer Adler-32 or CRC-32 (or something else). This would give you
>the possibility of using one or the other. But in any case, I'm not going to
>push anybody... actually after about two months of discussion I think that I
>don't care that much which one is used... sick...

        I'm much more concerned that we pick precisely one checksum,
with no new complexity, than which one we pick.

        That noted, and given the known reality of middleboxes that
modify checksums in the middle of the network, I haven't seen the
crisp justification for a change.  I'd really still like to see
that.  But if we are going to change, pick one and keep the implementation
approach quite simple.  I see your proposal as increasing complexity
unduly.

Ran
[email-masked]

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 Jun 2001 11:10:58 -0500

> approach quite simple.  I see your proposal as increasing complexity
I agree 100% and I think even worse we are spreading the problem
into other areas of the protocol by weakening other elements ..i.e.
the 32 bit V-tag to try to solve a problem that can be done so
by just reaching a consensus.

I feel the ONLY strong consensus we had (note I use the
past tense here) was to make a decision
that picks only ONE c-sum and does not change ANY of the
current format. 

R

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

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 25 Jun 2001 16:59:15 +0100 (BST)

On Mon, 25 Jun 2001, RJ Atkinson wrote:

> crisp justification for a change. 

Imagine supporting the choice of two checksums, with different
computational cost. The middlebox will always prefer to advertise and
rewrite packets to use the less computationally-expensive checksum, in
order to boost its performance.

Another good argument for a single checksum, I think. There are no
good arguments for multiple optional checksums at the same layer...

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 25 Jun 2001 09:55:01 -0700

R & All,

I would be happy with just CRC-32 in the checksum field (where ever it is
placed).

Doug

---

From: David Lehmann <[email-masked]>
Date: Mon, 25 Jun 2001 13:51:35 -0400

> that picks only ONE c-sum and does not change ANY of the

Hear, hear.

-David

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 27 Jun 2001 10:00:40 -0700

Ran,

In response to your concern about middle boxes, a reason that a middle box
is likely to alter the SCTP packet would be to change a local port if acting
as a NAT in preventing port collisions.  Perhaps adding a one's-complement
entry of the port numbers where both of these values are excluded from the
error checking would make life in the middle box simpler and allow the
remainder with the error check to be seen end to end.  Although perhaps too
simple, the Verification Tag would also help excuded possible port errors.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Source Port Number       |    Destination Port Number    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     ~Source Port Number       |   ~Destination Port Number    |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<
 |                        Verification Tag                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Packet Check                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

To continue the CRC theme however it could also be:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Source Port Number       |    Destination Port Number    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Port Check                          |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<
 |                        Verification Tag                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Packet Check                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Doug

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 27 Jun 2001 13:56:19 -0400

At 13:00 27/06/01, Douglas Otis wrote:
>as a NAT in preventing port collisions.  

Actually, there are a variety of reasons that different kinds
of middle boxes change different parts of the packet.  I agree
that NAT/PAT is a common one.

>Perhaps adding a one's-complement

This does not help the middle-box situation, because it doesn't
handle all kinds of middle-boxes.  Also, it means that a critical
part of the SCTP header isn't as well protected as it would be
normally.

Really no kidding, the bottom line is that applications that need
particularly strong integrity need to provide it themselves in the 
application layer on the user data that requires such integrity.
I wish this weren't so, but reality is what it is.

Cheers,

Ran
[email-masked]

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 27 Jun 2001 11:10:19 -0700

Ran,

You will note that if there was a concern about the level of integrity for
port assignments, it too could use CRC in such a case it would be iron-clad.
If adding a separate check for ports would eliminate 90+% of these concerns
about middle boxes, would that not be a good thing?  Things like NATs are
also likely owned by the client and thus somewhat under their control.  What
other middle box function is likely?

Doug

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 27 Jun 2001 14:43:24 -0400

At 14:10 27/06/01, Douglas Otis wrote:
>Things like NATs are
>also likely owned by the client and thus somewhat under their control.  

        Sadly this if often not the case.  Often there are NATs
in the middle or on the far end.  Some NATs are forced on users
by some (few) operators, where the operator runs the NAT and
users might not have a choice.

>What other middle box function is likely?

        Various boxes that intercept, modify the data contents,
and then resend the packet are not uncommon today with TCP
and UDP.  It is extremely likely that such will also exist
for SCTP shortly, probably munging telephony apps' data as well.
One could imagine an operator who intercepted all such traffic
running through their network to ensure that voice calls went
via the operator's official voice gateway and didn't go elsewhere.

        Note that I might not like any of the above.  I'm just
noting that they are likely to exist, given the history with
TCP and UDP to date.

Ran
[email-masked]

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 27 Jun 2001 16:25:16 -0700

Ran,

Application Specific Gateways (ALGs) for SCTP would be new and hopefully new
SCTP specific applications will consider limitations of NATs which creates
the impetus for most ALGs.  This may be optimistic but even those altered
packets are typically done only on a few of the packets if one excludes port
alteration which then limits exposure.  Creating a separate port check field
would afford a significant improvement in providing an end to end check if
such middle boxes where NATs make the greatest population are of concern.

Yes, there will be ALGs as you suggest that will create havoc, but if these
are reaching into the application data, even end to end protections created
by these applications are subject to the same changes.  As a practical
approach, removing 90+% of those situations that may corrupt the data should
merit consideration.

Doug