Subject: [TERNLI] Forwarding corrupt packets

From: Michael Welzl <[email-masked]>
Date: 01 Sep 2006 10:00:23 +0200

Hi all,

Here's an idea for a potentially useful message that
could be exchanged between end systems and the inner
network:

>From transport end point to network:
"Corruption Acceptable (CA)" (meaning that it would be
preferrable to forward packets that are corrupt rather
than drop them)

>From network to transport end point: "Corruption
Forwarding supported (CF)"

Purpose: help the end system decide whether to use
UDP-Lite, or partial checksums in DCCP, or the
Data Checksum option in DCCP.

These functions don't yield a benefit if a network
element drops all corrupt packets anyway. A CF
message could indicate that they would yield a
benefit. A CA message could increase the chance
of seeing a benefit.

What do you say?

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Fri, 01 Sep 2006 07:06:44 -0700

> Data Checksum option in DCCP.

Why does the _network_ need to know about these? The network doesn't
check (or shouldn't check) transport checksums.

The only reason the network would think a packet is corrupt:

1) bad net checksum (e.g., IPv4)

2) bad link checksum

In both cases, the destination address is not trusted anymore, so you're
potentially sending the corrupt packet to the wrong _place_. If you
can't send it the right place, then why are you sending it?

This isn't a new issue; it's one of the reasons for the partial checksum
in lite/DCCP - but also why it should be only over the _data_ portion.

In those conditions, you might end up with one e2e-pair causing a
separate endpoint to throttle-back thinking its packets are corrupted.
That cross-contamination seems like a sufficient reason not to do this.

IMO, partial transport checksums are useful only where the header
checksum is still valid; otherwise, there's no point in interpreting the
header at all.

Joe

---

From: Michael Welzl <[email-masked]>
Date: 01 Sep 2006 16:30:36 +0200

> 1) bad net checksum (e.g., IPv4)

I agree that, if this checksum is known to be corrupt, the
packet should be dropped.

> 2) bad link checksum

which normally covers everything, e.g. in 802.11 nets AFAIK.
So that's the one that I'm concerned about.

> can't send it the right place, then why are you sending it?

i remember you saying some time ago that sending it to the
wrong destination isn't a big problem for the network, and
therefore the lack of a checksum in ipv6 isn't a big issue.

chances are that it would reach the right place, so where's
the problem?

> in lite/DCCP - but also why it should be only over the _data_ portion.

This is at least the only portion the end node is concerned
with, so yep - the precise message from the sender would have
to be "corrupt data portion is okay" (no matter how exactly
the element in the network would handle this message - e.g. by
looking at the data portion, which I consider ugly design,
or by always forwarding corrupt data when at least the IP
checksum is ok, which I'd prefer).

> That cross-contamination seems like a sufficient reason not to do this.

I don't get this - could you go into more details?

> checksum is still valid; otherwise, there's no point in interpreting the

As I say above, that's an implementation detail in my opinion.
We can make recommendations in either direction - right now,
I'm just suggesting this explicit message between the transport
endpoints and the network.

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Fri, 01 Sep 2006 07:59:33 -0700

Michael Welzl wrote:
...
> therefore the lack of a checksum in ipv6 isn't a big issue.

*ONLY* because there is a link checksum that is *checked*.

> chances are that it would reach the right place, so where's

Why do you believe that? With multiaccess networking regaining dominance
(802.11, CDMA, etc.), a bad link checksum means the packet header may be
corrupted (as well as the data). In those cases, the *link* MUST NOT
forward the packet; it doesn't know where to forward it.

> looking at the data portion, which I consider ugly design,

The link/net ought not look at the transport layer. If it does, it's
because it needs to access info at that layer (for app-layer
forwarding). In that case, it's necessary to drop the packet because
forwarding isn't possible.

It's self-correcting - anyone who needs to look at data that's corrupt
ought not do so, period. For any data, anywhere in the network.

> checksum is ok, which I'd prefer).

If the header is OK (link, net, or app - based on what kind of
forwarding is happening), then it's OK to forward. If not, then not.

> I don't get this - could you go into more details?

A sends to B. The packet gets corrupted and goes to C. C throttle's ITS
connections because it got corrupted packets, but it didn't. Or
shouldn't have.

> As I say above, that's an implementation detail in my opinion.

I disagree; this is a fundamental statement about interpreting bits that
are corrupt. It's a mistake to do so. If that impedes forwarding, then
you MUST NOT forward.

> endpoints and the network.

If the network header is corrupt - or even if the transport header is
corrupt - the network doesn't know which endpoints or apps in the
endpoint to inform.

In that case, silence is the appropriate response.

Joe

---

From: "alessandro salvatori" <[email-masked]>
Date: Fri, 1 Sep 2006 14:39:16 +0000

> chances are that it would reach the right place, so where's

Well, let me be the devil's lawyer... Can you trust the TTL field to
be monotonically decreased if frames get corrupted? You can not, and
packets would be able to be forwarded forever. Well, they wouldn't if
they eventually reached their destination, but remember the fact that
you might forward packets with a varying destination address, and you
wouldn't even need to have route loops to keep trying to route to a
"moving" target...

-- 
Alessandro Salvatori

---

From: Michael Welzl <[email-masked]>
Date: 01 Sep 2006 19:20:28 +0200

> forward the packet; it doesn't know where to forward it.

The same is the case if the IP checksum is wrong.

In a February 2005 discussion on the end2end-interest list, I said:

>> Still, that doesn't make sense to me. What if you transfer an
>> IPv6 packet across a link layer that does *NOT* check your data -
>> why wouldn't this cause harm to the source / destination addresses,
>> and therefore cause wrong router behavior downstream? 

and you answered:

> It doesn't cause harm at the destination, since there's supposed
> to be a transport checksum (even for ICMP - one was added). I
> suppose there's no perceived harm in sending some corrupted
> traffic through the wrong paths.
> 
> Note - this is designed to address corruption, not malicious behavior.

...and that's why I now believe that. You convinced me of it.

> forwarding isn't possible.

I'd agree that having it look at the transport layer is not
clean design, but that's what we ended up with in the UDP-Lite RFC:

   For a link that supports
   partial error detection, the Checksum Coverage field in the UDP-Lite
   header MAY be used as a hint of where errors do not need to be
   detected.  Lower layers MUST use a strong error detection mechanism
   [RFC-3819] to detect at least errors that occur in the sensitive part
   of the packet, and discard damaged packets.  The sensitive part
   consists of the octets between the first octet of the IP header and
   the last octet identified by the Checksum Coverage field.  The
   sensitive part would thus be treated in exactly the same way as for a
   UDP packet.

If you're going to do this, it might be better to selectively
enable/disable it.

> forwarding is happening), then it's OK to forward. If not, then not.

What you're saying seems to mean that a link layer must not
forward corrupt data unless it has a means to check whether
at least its header is correct. I don't know any link layer
technology that can do this - so you're saying that partial
and separate checksums as in UDP-Lite and DCCP should not
exist, or only be there for the case where you have a link
layer that can restrict its checksum to the link layer header.

Even that might be a nice feature for a new link layer
technology in my opinion, but in any case you're
contradicting existing language in the UDP-Lite and
DCCP RFCs, where it is assumed that link layers can
in fact forward corrupt data.

In any case, it seems to me that we're again debating an
implementation detail here - partial and separate checksums
are there, so it is assumed that there are (or will be)
link layers which forward some corrupt packets for one
way or another. Based on this assumption, wouldn't this
explicit message make sense?

> connections because it got corrupted packets, but it didn't. Or

Let's pick DCCP as an example protocol. If C throttles its
connection because of corruption, it means that the Data
Checksum option is in place - which will detect a failure
in the header and therefore drop the packet. This feature
("option" - one has to be careful what one calls a feature
in DCCP) is there to prevent exactly this type of problem
from occurring.

> are corrupt. It's a mistake to do so. If that impedes forwarding, then

Again, you seem to contradict your original statement from 2005.
If you changed your mind, why?

> In that case, silence is the appropriate response.

Same point again.

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Fri, 01 Sep 2006 11:12:29 -0700

> The same is the case if the IP checksum is wrong.

Agreed.

> ...and that's why I now believe that. You convinced me of it.

The question is the impact of the bad packet.

If the transport checks things and silently discards bad packets, then
the only harm is bandwidth, and I figured this wouldn't be substantial
(since errors are presumably somewhat random).

If the transport reacts to corrupt packets - as would be the case with
UDP-lite and some configs of DCCP - that would be very bad. The
difference is whether we're talking about corrupted data and corrupted
headers; corrupt data isn't too bad (that's what UDP-lite and DCCP are
designed for). Corrupt headers are VERY bad to forward.

>    sensitive part would thus be treated in exactly the same way as for a

The link isn't looking at the net layer for forwarding here; it's
looking only for an optimization to detect errors over a subset of the
packet.

For UDP-lite, when the link error is detected (above), the checksum
coverage field could be wrong, which means that it's inappropriate to
use that information to limit link error coverage, and that the packet
MUST be discarded (see 'discard' above).

> If you're going to do this, it might be better to selectively

I disagree; once link protection is provided as noted above and the
UDP-lite checksum fails, there is NO utility in forwarding the corrupted
packet anywhere. So you forward it to the endpoint... to which port? The
port is corrupt, so you can't know you're sending it the right place.

> at least its header is correct.

Yes- that's how I read section 4 of the UDP-lite doc, quoted above, and
repeated in specific here:

----
Lower layers MUST use a strong error detection mechanism [RFC-3819] to
detect at least errors that occur in the sensitive part of the packet,
and discard damaged packets.
----

> I don't know any link layer

That's exactly how I read section 4 above.

> in fact forward corrupt data.

Yup. Further in sec 4 of the same doc:
---
   Link layers that do not support partial error detection suitable for
   UDP-Lite, as described above, MUST detect errors in the entire UDP-
   Lite packet, and MUST discard damaged packets [RFC-3819].
---

> explicit message make sense?

No; UDP-lite requires that the packets be discarded. I don't agree that
sending a signal about corrupt header info is ever appropriate.

> in DCCP) is there to prevent exactly this type of problem

That assumes:

	a) partial coverage of the packet by a strong link
	layer

	b) correct checksum of the packet at the DCCP-partial
	layer

I.e., IMO, the same requirements as for UDP-lite (I haven't checked
DCCP, which is a longer spec, but I'll assume it has similar
requirements, or -should- ;-)

> If you changed your mind, why?

See above; header vs. data. I've never presumed that forwarding or
signalling based on a corrupt header is appropriate.

>> In that case, silence is the appropriate response.

Same reply ;-)

Joe

---

From: Michael Welzl <[email-masked]>
Date: 04 Sep 2006 09:59:01 +0200

Agreed.

> designed for). Corrupt headers are VERY bad to forward.

I still don't get it - no matter how you use them, the
reaction of DCCP and UDP-Lite would always be to silently
discard a packet if the transport header is wrong, so
no harm is being done (except for the potential waste of
bandwidth you mention above, but we agree that this isn't
substantial).

> MUST be discarded (see 'discard' above).

I see that this is in the specification, but I question that
it would have to be so strict (could also be a SHOULD in my
opinion). The reason is that the checksum coverage field is
itself covered by UDP-Lite's checksum in any case, so the
harm is again just a waste of bandwidth.

> port is corrupt, so you can't know you're sending it the right place.

I agree that UDP-lite detection by links as above eliminates
any need for such explicit signaling. I however question that
this is clean design - now links should detect UDP-Lite, look
at the checksum coverage field, then they should also detect
DCCP and forward corrupt data if it makes sense according
to the DCCP header. What's next?

This is why I'd prefer an explicit message. This being said,
there are of course also issues with it - for instance, if
the link layer should only do this for the specific flow
which requests it, it must again look at the IP header to
classify flows. This is probably not much "cleaner" than the
scenario I criticize here. Then again, a link could just
forward any corrupt data for a while upon reception of such
a message, and that single state would have to be refreshed.

I'm guessing that you won't like that - such behavior
of course requires all the receivers to be able to
"survive" the reception of corrupt data. I think
that this should be the case anyway, though - that's
why we have transport checksums.

> and discard damaged packets.

I say that this is too strict, based on our previous
discussion, where you (convincingly) argued that it was
okay for a link to forward IPv6 packets with errors.

Now you refer to a much stricter specification - so let's
use TCP over IPV6 as a reference, not UDP-Lite.

> That's exactly how I read section 4 above.

Hm, right, both the UDP-Lite and DCCP spec are as strict
as that about this issue, requiring this (in my opinion
ugly) method of communication between the transport and
link layers anyway, perhaps making it pointless to add
additional explicit communication...

>    Lite packet, and MUST discard damaged packets [RFC-3819].

*sigh* ... I just forgot how strict all that text was.
I wish it wasn't.

> requirements, or -should- ;-)

This would also work without a), and that's exactly why
I think that the specifications (indeed, both of them
have these statements you quote here) are too strict in
this aspect.

But that's just the way they are, so I guess there's
no point in debating them right now.

> signalling based on a corrupt header is appropriate.

Well yes, you said it's appropriate to forward an IPv6 packet
with a broken IPv6 header, or at least that it doesn't cause
harm. This type of forwarding just isn't happening for DCCP
and UDP-Lite because their specs are so strict about this matter.

Cheers,
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 04 Sep 2006 12:01:36 +0100

A) On which link layers support this?

Not all link-layers necessarily check all the bytes within a link framer 
when calculating the frame integrity check (e.g. CRC-16 or CRC-32).

A classic example of this is the ISO HDLC frame format, that has long 
included a frame-type called UIH, which assigns the CRC to cover a 
pre-agreed minimum number of bytes (perhaps pre-configured, perhaps 
negotiated using the XID method). Frames with invalid CRCs are 
discarded, frames with good CRCs are forwarded without judgement on the 
remaining content. This could be used by a UDP-Lite aware (L4 snooping) 
link driver to select to choose UIH format in favour of UI frames, when 
this is compatible with the UDP-Lite coverage value.

HDLC Voice links have used this format, and something similar is 
supported in some of 3GPP specs. BUT DO NOTE, to support this and get 
strong benefits you have to make the correct PHY decisions, which 
impacts coding, modulation, synchronisation, etc. - It's not just a 
matter of ignoring the CRC and hoping for the best.

If you don't use a CRC at all, you increase the chance of mis-delivery 
to others (and the possibility of getting mangled packets). This is 
particularly bad for IPv6 nodes. The IPv4 checksum is too weak to really 
give you much confidence under these cases either;-).

---

B) On whether this extra signalling is useful?

What I don't understand is the "essence" of the message that you need to 
generate to utilise this, since you seem to suggest in this thread using 
explicit signalling to set L2 state, rather than per-packet choices.

 > "From transport end point to network"
- I think we already have this as a transport option.
- not sure I am convinced we need the signal.
- I don't understand this signal... it seems to bind a specific TSpec 
(IPsrc,IPdst, Transport, srcport,dstport)to a L2 identity... How do you 
differentiate when a new app replaces the previous one with different 
semantics?

 > From network to transport end point:"Corruption Forwarding supported 
(CF)"
- Why do we need to know this at the transport layer?
- If your end systems (and any L4 middleboxes!) support UDP-Lite and/or 
DCCP with partial coverage it is FINE to use this irrespective of 
whether the links do anyrthing special. you don't gain, but you don't 
loose either.

- Can you clarify how the extra signalling helps?

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 4 Sep 2006 13:19:27 +0200

Dear all,
for SCTP there is an ID
http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-05.txt
which sends back a packet to the sender if the receiver detects a  
transport
layer checksum failure...

Best regards
Michael

---

From: Michael Welzl <[email-masked]>
Date: 04 Sep 2006 13:28:30 +0200

> A) On which link layers support this?

Thanks for all the interesting details!

> B) On whether this extra signalling is useful?

At this point, I should perhaps mention that I'm not
making a very concrete proposal here which I try to
defend - the way I understood it, TERNLI is still in
its defining stage and people are just tossing ideas
around. So I thought I'd add an idea and see what the
reaction would be - and the reactions are surely
interesting, thanks a lot to both of you for the
feedback you gave so far!

> explicit signalling to set L2 state, rather than per-packet choices.

at least in the "From transport end point to network" case, yes.

> differentiate when a new app replaces the previous one with different 

When I proposed this, I didn't think of the parts of
the UDP-Lite and DCCP specs that Joe pointed me to,
which require link layers to detect that forwarding
corrupt packets is desired.

The "beauty" of this design notwithstanding, that signal
is therefore already existent on a per-packet basis,
so I would now agree that the message isn't useful anymore
in this direction.

> - Can you clarify how the extra signalling helps?

In DCCP, the data checksum option is extra overhead, but it is
useless unless you have a link which delivers known-corrupt
data. Here I'd say that it would help.

As for UDP-Lite, a reason not to use it is (as with any
new protocol) the fact that it might not pass through
firewalls. Thus, my application could first use UDP =>
extra signaling tells me to try UDP-Lite, so I do.

Theoretically, it might be preferrable to always try
UDP-Lite first, and switch back to UDP in case of failure.
But will application programmers do this? I imagine that
the outlook of receiving a message which tells an application
to use UDP-Lite might be a more convincing argument for
application programmers to support the protocol at all.
Then again, maybe not - I'm really just guessing here.

Cheers,
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 04 Sep 2006 14:05:08 +0100

So, I had missed this being discussed (sorry).

I'm quite confused about several things:

* In Section 3 it says:
    The SCTP endpoint can inform its peer that it has received an SCTP
    packet, but the CRC-32 was wrong.

I presume though that the receiver can somehow verfy that the original 
packet has been sent with a particular IP source, and protocol. How?

I'm curious also here how you know some details

* How do you find the process to respond to (since ports are not 
protected by an IP checksum)?

* How do you verify this isn't a third-party DoS attack, because 
presumably you can't rely on sequence numbers, ports, etc to help you?

* I think I could have missed it, but what is the mechanism by which an 
IP packet passes through the node and receives a treatment that leaves 
it with a corrupted CRC-32 at the transport layer, but some (reliable) 
understanding of the content (IP addresses, length, protocol, etc).

* If you return a message from a mid-box, how do you know that routers 
down-stream of the mid-box would have forwared this packet?

Gorry

>>> The question is the impact of the bad packet.
<Snip>

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 04 Sep 2006 14:13:43 +0100

I think it was a reasonable strawman, and is a form of cross-layer 
signalling. I suggest any L2 signalling has to demonstrate it is 
necessary, safe, etc.

Not sure the case for DCCP is much stronger, but would could think on 
this. My take is that links have to work hard to get UDP-Lite-style L2 
processing working effectively. Links that do this can get benefit (if 
desigend that way). Peeking into the header may also be reasonable for DCCP.

Your deployment note at the end on UDP-Lite is a good point. If some 
signal could help address this issue, this would be a great step towards 
  real deployment, however at the moment, I'm not yet persauded this is 
the right way to do this.

Thanks,

Gorry

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 4 Sep 2006 15:25:12 +0200

Hi Gorry,

see my comments in-line.

Best regards
Michael

On Sep 4, 2006, at 3:05 PM, Gorry Fairhurst wrote:

> I presume though that the receiver can somehow verfy that the  
> original packet has been sent with a particular IP source, and  
> protocol. How?
We try to lookup the association based on the IP addresses, port  
numbers and verification tag.
If this is successful, we assume that the error is in the payload,  
but we still know the
peer. So we send back the PKTDRP report.
If the lookup of the association is not successful (because the error  
is in the port numbers
or verification tag (8 bytes) then we simply drop the packet.
> protected by an IP checksum)?
We just try. Please note that the IP addresses (protected by the IP  
header checksum), the
port numbers and the verification tag must match before we take any  
action.
> presumably you can't rely on sequence numbers, ports, etc to help you?
The verification tag must match... But I do not see a point here.  
Someone sending us a packet
such that we send a PKTDRP report to the victim could just send the  
PKTDRP report to the victim
using our address as the source. So I think security is not a problem  
here.
>
> * I think I could have missed it, but what is the mechanism by  
> which an IP packet passes through the node and receives a treatment  
> that leaves it with a corrupted CRC-32 at the transport layer, but  
> some (reliable) understanding of the content (IP addresses, length,  
> protocol, etc).
I saw a buggy switch which corrupted always some bytes in the SCTP  
payload. Therefore the IP header
checksum was correct, the Ethernet CRC was correct, because the  
switch computed it correclty,
only the SCTP checksum was wrong.
>
> * If you return a message from a mid-box, how do you know that  
> routers down-stream of the mid-box would have forwared this packet?
I'm not sure what you are asking about here... Routers do not look at  
the SCTP checksum, so why
would they care? The wrong checksum indication will come from an end- 
point most likely.

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 04 Sep 2006 14:39:51 +0100

Michael Tuexen wrote:

> If this is successful, we assume that the error is in the payload,  but 
> we still know the
OK, so if I think you're saying the verification tag effectively 
provides you with a cookie that identifies the flow.

> header checksum), 
Yes for IPv4, but not for IPv6.

> the

> using our address as the source. So I think security is not a problem  
My worry was more that the "attack" made *that receiver* send an error 
report, that takes capacity on the return route, and then causes the 
corresponding sender to get a valid message (from the receiver) saying 
there are link errors (when there are not), and to somehow ignore other 
losses on the forward route (which may not even go via a link that has 
errors).

>> * I think I could have missed it, but what is the mechanism by  which 
>> an IP packet passes through the node and receives a treatment  that 
>> leaves it with a corrupted CRC-32 at the transport layer, but  some 
>> (reliable) understanding of the content (IP addresses, length,  
>> protocol, etc).
> 
> checksum was correct, the Ethernet CRC was correct, because the  switch 
> computed it correclty,
OK, and buggy routers can do this too. However, should we really be 
building IETF documents to work around such bugs????

If that is the main motivation, I think this is ill-founded. Do you have 
other uses in mind?

> would they care? The wrong checksum indication will come from an end- 
If it's from an end-point, that seems to answer my question.
>>
>> Gorry
>>
>>
>> Michael Tuexen wrote:
>>
>>> Dear all,
>>> for SCTP there is an ID
>>> http://www.ietf.org/internet-drafts/draft-stewart-sctp- pktdrprep-05.txt

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 4 Sep 2006 16:31:50 +0200

Hi Gorry,

comments in-line.

Best regards
Michael

On Sep 4, 2006, at 3:39 PM, Gorry Fairhurst wrote:

>> If this is successful, we assume that the error is in the  
>> payload,  but we still know the
>> If the lookup of the association is not successful (because the  
>> error  is in the port numbers
and the addresses and the port numbers. For IPv4 this is 4+4+2+2+4=16  
bytes that must match.
>> We just try. Please note that the IP addresses (protected by the  
>> IP  header checksum),
Correct. However, if there is an error in the IP addresses, it is  
unlikely that the
16+16+2+2+4=40 bytes still match an existing association.
>
>> the
>> port numbers and the verification tag must match before we take  
>> any  action.
>
>> such that we send a PKTDRP report to the victim could just send  
>> the  PKTDRP report to the victim
>> using our address as the source. So I think security is not a  
>> problem  here.
> My worry was more that the "attack" made *that receiver* send an  
> error report, that takes capacity on the return route, and then  
> causes the corresponding sender to get a valid message (from the  
> receiver) saying there are link errors (when there are not), and to  
> somehow ignore other losses on the forward route (which may not  
> even go via a link that has errors).
Hmm. What we have in mind is that the sender gets an indication that  
a packet was not successfully
received but was not dropped because of congestion in the network. So  
the sender does not see
this "packet drop" as a congestion indication.
>>> which an IP packet passes through the node and receives a  
>>> treatment  that leaves it with a corrupted CRC-32 at the  
>>> transport layer, but  some (reliable) understanding of the  
>>> content (IP addresses, length,  protocol, etc).
>> I saw a buggy switch which corrupted always some bytes in the  
>> SCTP  payload. Therefore the IP header
That is not the intention of the document. The core of the document  
is to handle the
case where some middleboxes are "tunneling" the traffic and there is  
packet loss without
congestion. This can happen, for example, on satellite links.

So the purpose of the document is to inform the sender that some  
packets have been dropped
but not due to congestion.

The support of the checksum error stuff is there because it was very  
easy to add and it is
very helpful for finding problem as the one above.
>
> If that is the main motivation, I think this is ill-founded. Do you  
> have other uses in mind?
>
>>>
>> I'm not sure what you are asking about here... Routers do not look  
>> at  the SCTP checksum, so why
>> would they care? The wrong checksum indication will come from an  
>> end- point most likely.
Yes, and if it is from an middle box, it is a special box, which  
detects this stuff and does
not forward the corrupted packet, but sends back that notification  
instead. But normal routers
will just forward it...
>>>> which sends back a packet to the sender if the receiver detects  
>>>> a   transport

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 Sep 2006 09:01:56 -0700

...
> bandwidth you mention above, but we agree that this isn't

Bad body, good header: the harm is the bandwidth to the correct
endpoint; the benefit is that this endpoint knows something legitimate,
and the packet serves as its own corruption signal

Bad header: the harm is the signal is sent to the WRONG endpoint.

I reviewed the Feb 2005 discussion on this issue from End2end-interest.

Here's the summary:

- IPv6 does NOT, in RFC2640, require link checksums (as UDP-Lite does).

The relevant text is:

-------------------------------
> Although IPv6 (at 
> least as I recall) omits the IP checksum because of sufficient link 
> checksums to detect corrupted packets, there's no requirement that link 
> layers have such checksums (as hinted in the UDP-Lite RFC) - at least 
> not in 2460 (anyone else know anywhere else a body is buried in this 
> regard?)
-------------------------------

I saw no followup to that question.

- I said that UDP-Lite's requirement of link checksums was an ugly layer
violation. I still think that's the case.

As far as I can tell, UDP-Lite is relaxing a requirement in IPv6 -
allowing partial link checksums rather than full, but I can't locate
that requirement, as per above.

---

I don't have a problem with forwarding the information to the wrong
place; I have a problem with the wrong place acting on it. You're
assuming that the UDP-Lite partial checksum is sufficient to avoid that;
for some reason, the UDP-Lite authors and WG clearly did not.

It'd be useful to review the UDP-lite discussions as to why that text
was required so prominently.

Joe

---

From: Michael Welzl <[email-masked]>
Date: 04 Sep 2006 18:57:44 +0200

Joe,

I couldn't agree more with everything you say here.

Cheers,
Michael

-- 
Michael Welzl <[email-masked]>
University of Innsbruck

---

From: Michael Welzl <[email-masked]>
Date: 04 Sep 2006 19:15:25 +0200

Hi,

I think that this SCTP proposal is very interesting -
especially because it doesn't use another checksum but
just assumes that everything is right because it's
improbable to hit the right association anyway. I'm
not yet quite sure whether I like or dislike the
idea, though.

> 16+16+2+2+4=40 bytes still match an existing association.

unlikely enough? does this enable an attacker to do bad things,
or doesn't it?

I'm thinking of a very recent email by Joe, where he explained
that bad things can happen if a receiver tells a sender to
slow down because the receiver has received a (corrupt) packet
which it should never have received in the fist place. My
argument was that this would never happen - in DCCP as well
as UDP-Lite, the transport header is always checked.

All of a sudden, your proposal seems to change this matter.
In this context, "we just try" just doesn't have a good
sound to it...

> this "packet drop" as a congestion indication.

and how does a sender react? In the discussions for the
DCCP Data Checksum, there was agreement that we don't know
enough about the right sender reaction to corruption yet -
but simply sending at the same rate without reducing it
at all would not be the right thing to do.

This seems to contradict the following part of your draft:

      The DATA
      chunk should be treated just as if it had been marked for fast
      retransmit with the exception that no adjustment should be made to
      the value of cwnd (providing that the receiver can validate a
      portion of the packet as being what was sent).

Cheers,
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 04 Sep 2006 18:24:20 +0100

So, from a quick look:

The first place I looked was the book on IPNG by Bradner and Mankin, and 
this say (p193, from Craig Partridge) and I found:

"IP Header Checksum. There has been discussion indicating that the 
IP[v4] Checksum does not provide enough error protection to warrant its 
performance impact. The argument states that there is almost always a 
stronger datalink level CRC, and that end-to-end protection is provided 
by the TCP Checksum. Therefore, an IPng checksum is not reqiuired."

This was the basis of what I understood, when working with UDP-Lite, and 
also what was finally was expressed in RFC3819:

   " Any new subnetwork designed to carry IP should therefore provide
     error detection at least as strong as the 32-bit CRC specified in
     [ISO3309]."

Section 8.3 said:

   "Errors in other IPv6 header fields may go
    undetected within the network; this was considered a reasonable price
    to pay for a considerable reduction in the processing required by
    each router, and it was assumed that subnetworks would use a strong
    link CRC."

It would be good to uncover more IETF History.

Gorry

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 4 Sep 2006 20:02:11 +0200

Hi Michael,

see my comments in-line.

I'll not respond the next week, because I'll be on vacation :-)
I'm CCing Randall Stewart, he is definitely also interest in
this subject and should be available next week.

Best regards
Michael

> not yet quite sure whether I like or dislike the
Hmmmm.
> unlikely enough? does this enable an attacker to do bad things,
I think we have to consider two cases:
- An on path attacker. He can do everything, SCTP, as any other
   transport layer (UDP, TCP, DCCP) does not provide any way of
   protection. You could use SCTP-AUTH to prevent this, but this
   would need a shared secret and SCTP-AUTH is an extension, not
   part of "plain SCTP".
- An off path attacker. SCTP uses a 32 bit random number (the
   verification tag) to protect against bind attackers. We
   also recommend that one side uses a random port number (ephemeral)
   which would give another 14 bit randomness to guess. So it
   is 48 bit of randomness an attacker has to guess. The probability
   is 1/2^48 which is pretty small.

So I do not think that this adds an additional threat to SCTP.
But if you have an attack in mind, I would be very interested
to think about it. We (the authors of the ID) do NOT want to
make SCTP with that extension weaker than without.
> In this context, "we just try" just doesn't have a good
Do not get me wrong: This "we just try" means that we try to
lookup the TCB. And I think if there is an error in the port number
V-tag combination, then we will not find a TCB. Everything has to match.
>       portion of the packet as being what was sent).
What we know is:
- the payload was corrupted (the SCTP common header was intact)
- the receiver proofed that he got the packet. So it is not in the
   network anymore
We assume that this is NOT an indication of congestion. So we can  
fast retransmit
it...

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 04 Sep 2006 21:01:19 +0100

> 16+16+2+2+4=40 bytes still match an existing association.
Yep, that's what I wanted to see :-)

>> somehow ignore other losses on the forward route (which may not  even 
>> go via a link that has errors).
> 
> Hmm. What we have in mind is that the sender gets an indication that  a 
> packet was not successfully
This is what I thought, but this seems a potentially dangerous signal to 
give, if it can be incorrect. I guess if the signal says I got "X" and 
it was the correct size and has the fields set (as you said), then it is 
safe to re-send X when the congestion window permits, without 
considering this as a congestion loss.

It seems like the danger is only if the sender makes assumptions about 
any other packets that failed to reach their intended destination.

>>>> treatment  that leaves it with a corrupted CRC-32 at the  transport 
>>>> layer, but  some (reliable) understanding of the  content (IP 
>>>> addresses, length,  protocol, etc).
>>>
> That is not the intention of the document. The core of the document  is 
> to handle the case where some middleboxes are "tunneling" the traffic 
 > and there is packet loss without
> packets have been dropped but not due to congestion.
> 
OK - so I guess I still missed how you "know" packets lost on a link (or 
tunnel) would have reached the destination, if only they had not been lost?

> instead. But normal routers will just forward it...
> 
OK. I think this is a little different to UDP-Lite, in that the 
assuymption in that case, and with DCCP, is that the delivery is doing 
useful work for the end-points. Whereas if you are only using it to 
generate a NACK, then I can see whty you'd rather get the special box to 
fix this.

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 4 Sep 2006 22:32:15 +0200

Hi Gorry,

see my comments in-line.

Best regards
Michael

On Sep 4, 2006, at 10:01 PM, Gorry Fairhurst wrote:

>>>>> original packet has been sent with a particular IP source,  
>>>>> and   protocol. How?
>>>>
>>>> We try to lookup the association based on the IP addresses,  
>>>> port   numbers and verification tag.
>> and the addresses and the port numbers. For IPv4 this is 4+4+2+2 
>> +4=16  bytes that must match.
>>>
>>>>>
>>>>> * How do you find the process to respond to (since ports are  
>>>>> not   protected by an IP checksum)?
>>>>
>>>> We just try. Please note that the IP addresses (protected by  
>>>> the  IP  header checksum),
>>>
>>>>> * How do you verify this isn't a third-party DoS attack,  
>>>>> because   presumably you can't rely on sequence numbers, ports,  
>>>>> etc to help  you?
>>>>
>>>> The verification tag must match... But I do not see a point  
>>>> here.   Someone sending us a packet
>>> receiver) saying there are link errors (when there are not), and  
>>> to  somehow ignore other losses on the forward route (which may  
>>> not  even go via a link that has errors).
>> Hmm. What we have in mind is that the sender gets an indication  
>> that  a packet was not successfully
>> received but was not dropped because of congestion in the network.  
>> So  the sender does not see
> This is what I thought, but this seems a potentially dangerous  
> signal to give, if it can be incorrect. I guess if the signal says  
> I got "X" and it was the correct size and has the fields set (as  
> you said), then it is safe to re-send X when the congestion window  
> permits, without considering this as a congestion loss.
>
> It seems like the danger is only if the sender makes assumptions  
> about any other packets that failed to reach their intended  
> destination.
Agreed. But we do not do this. We take it just as an indication that  
the packet being reported was corrupted during
transmission, but made it to the reporting node. So there was no  
congestion.
>
>>>
>>>>> * I think I could have missed it, but what is the mechanism  
>>>>> by   which an IP packet passes through the node and receives a   
>>>> checksum was correct, the Ethernet CRC was correct, because  
>>>> the   switch computed it correclty,
>>> OK, and buggy routers can do this too. However, should we really  
>>> be  building IETF documents to work around such bugs????
>> That is not the intention of the document. The core of the  
>> document  is to handle the case where some middleboxes are  
>> "tunneling" the traffic
>> The support of the checksum error stuff is there because it was  
>> very  easy to add and it is
> OK - so I guess I still missed how you "know" packets lost on a  
> link (or tunnel) would have reached the destination, if only they  
> had not been lost?
Here you are talking about the tunnel endpoints. Consider the case  
where the link has a high
error rate and the receiving end of the tunnel got the packet, but  
corrupted. If it knows
that the corruption is not related to congestion, it can send the  
report. But *if* the
tunnel endpoints run an appropriate tunneling protocol with their own  
acks, even the
sending side of the tunnel could know that the receiver only got it  
corrupted.
>
>>>
>>> If that is the main motivation, I think this is ill-founded. Do  
>>> you  have other uses in mind?
>>>
>>>>>
>>>>> * If you return a message from a mid-box, how do you know  
>>>>> that   routers down-stream of the mid-box would have forwared  
>>>>> this packet?
>>>>
>>>> I'm not sure what you are asking about here... Routers do not  
>>>> look  at  the SCTP checksum, so why
>>>> would they care? The wrong checksum indication will come from  
>>>> an  end- point most likely.
>>>
>> not forward the corrupted packet, but sends back that  
>> notification  instead. But normal routers will just forward it...
> assuymption in that case, and with DCCP, is that the delivery is  
> doing useful work for the end-points. Whereas if you are only using  
> it to generate a NACK, then I can see whty you'd rather get the  
> special box to fix this.
Yes, it is different from UDP-lite. SCTP never presents payload which  
was received with checksum errors to the user.
It is only to speed up the retransmission the get the payload without  
checksum errors to the receiver.
>>>>>> which sends back a packet to the sender if the receiver  
>>>>>> detects  a   transport

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 Sep 2006 15:50:09 -0700

...
> - An on path attacker....
> - An off path attacker. ...

Checksums are not protection from attacks.

Joe

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 5 Sep 2006 00:59:09 +0200

Hi Joe,

comments in-line.

Best regards
Michael

> Checksums are not protection from attacks.
Correct.
But the question was could the PKTDRP report be used for an attack.  
What I wanted to
make clear is the an on path attacker can use it, but he can do this  
even without PKTDRP.
An off path attacker has the same problem as for basic SCTP without  
PKTDRP.

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 Sep 2006 17:24:53 -0700

> But the question was could the PKTDRP report be used for an attack. 

If it isn't signed, then yes. But that holds for any message.

> What
> I wanted to
> An off path attacker has the same problem as for basic SCTP without PKTDRP.

Aren't these statements true for any unsigned SCTP message?

Joe

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 5 Sep 2006 07:49:40 +0200

Hi Joe,

comments in-line.

Best regards
Michael

Correct.
> Aren't these statements true for any unsigned SCTP message?
Correct. That was my point. SCTP with PKTDRP is not less safe than  
pure SCTP.

---

From: Michael Welzl <[email-masked]>
Date: 05 Sep 2006 09:15:52 +0200

> I'll not respond the next week, because I'll be on vacation :-)

there's still quite a bit of this week left   :-)

> make SCTP with that extension weaker than without.

I don't have a particular attack in mind, and what you said
sounds convincing. I just shared my initial feelings...
I'd like to leave the security check to Joe who certainly
knows a lot more about these things (security is one particular
weakness of mine, so I should probably just shut up).

> We assume that this is NOT an indication of congestion. So we can  

I fully agree about fast retransmitting. It's the "no adjustment
should be made to the value of cwnd" part that worries me.

Cheers,
Michael

---

From: Randall Stewart <[email-masked]>
Date: Tue, 05 Sep 2006 07:06:23 -0400

Michael Tuexen wrote:
>> This is what I thought, but this seems a potentially dangerous  signal 
>> to give, if it can be incorrect. I guess if the signal says  I got "X" 
>> and it was the correct size and has the fields set (as  you said), 
>> then it is safe to re-send X when the congestion window  permits, 
>> without considering this as a congestion loss.
>>
>> about any other packets that failed to reach their intended  destination.
> 
>>> is to handle the case where some middleboxes are  "tunneling" the 
>>> traffic
>>
>> OK - so I guess I still missed how you "know" packets lost on a  link 
>> (or tunnel) would have reached the destination, if only they  had not 
>> been lost?
> 

This is what Cisco's RBSCP does.. its a released feature
offered in most of our routers.. intended for Satellite network
configurations with high loss rates... (not the new K band but
the older C band sat's)

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

---

From: Randall Stewart <[email-masked]>
Date: Tue, 05 Sep 2006 07:07:47 -0400

Michael Tuexen wrote:
> Correct. That was my point. SCTP with PKTDRP is not less safe than  pure 
> SCTP.
Exactly its no different then TCP/UDP/DCCP.. anything that is
not signed has this danger...

R

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 05 Sep 2006 16:43:20 +0100

So, now I am much clearer about the method. For me, I am pleased we had the
discussion. I have a lingering query about how applicable these methods are
to other link types and hence how important this is as an IETF transport
activity (but that not an issue for TERNLI).

Thanks,

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 05 Sep 2006 16:44:06 +0100

This seems fine, the "risk" is only from on-path devices, same as for
TCP,etc. 

Gorry