Re: [TERNLI] Forwarding corrupt packets

[Randall Stewart <[e-mail]>]

Michael Tuexen wrote:
> Hi Gorry,
> 
> see my comments in-line.
> 
> Best regards
> Michael
> 
> On Sep 4, 2006, at 10:01 PM, Gorry Fairhurst wrote:
> 
>> Michael Tuexen wrote:
>>
>>> 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.
>>
>> Yep, that's what I wanted to see :-)
>>
>>>>
>>>>> 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.
>>
>> 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   
>>>>>> 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.
>>
>> 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.

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

> 
>>
>>>>
>>>> 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...
>>
>> 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.
> 
> 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.
> 
>>
>>>>>>
>>>>>> 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>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
> 


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