Re: [TERNLI] Forwarding corrupt packets

[Gorry Fairhurst <[e-mail]>]

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


On 4/9/06 21:32, "Michael Tuexen" <[e-mail]> 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.
>> 
>>>> 
>>>> 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>
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 
>