Re: [TERNLI] Forwarding corrupt packets

[Michael Tuexen <[e-mail]>]

Hi Gorry,

comments in-line.

Best regards
Michael

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

> Michael Tuexen wrote:
>
>> Hi Gorry,
>> see my comments in-line.
>> Best regards
>> Michael
>> On Sep 4, 2006, at 3:05 PM, Gorry Fairhurst wrote:
>>> 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?
>> 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.
> OK, so if I think you're saying the verification tag effectively  
> provides you with a cookie that identifies the flow.
and the addresses and the port numbers. For IPv4 this is 4+4+2+2+4=16  
bytes that must match.
>
>>>
>>> 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)?
>> We just try. Please note that the IP addresses (protected by the  
>> IP  header checksum),
> Yes for IPv4, but not for IPv6.
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.
>
>>> * 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
>> 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.
>
>>> * 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.
> 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 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?
>
>>>
>>> * 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.
> If it's from an end-point, that seems to answer my question.
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...
>>>
>>> Gorry
>>>
>>>
>>> Michael Tuexen wrote:
>>>
>>>> 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
>>>> On Sep 4, 2006, at 9:59 AM, Michael Welzl wrote:
>>>>
>>>>>> The question is the impact of the bad packet.
>>>>
>>>>
>>> <Snip>
>>>
>>>
>>>
>
>