Subject: RFC question

From: "Anatoly Khusid" <[email-masked]>
Date: Mon, 20 Jun 2005 13:44:11 -0400

Hello,

I had a question about this section in RFC:

-------------------
8.1 Endpoint Failure Detection

   An endpoint shall keep a counter on the total number of consecutive
   retransmissions to its peer (including retransmissions to all the
   destination transport addresses of the peer if it is multi-homed).
   If the value of this counter exceeds the limit indicated in the
   protocol parameter 'Association.Max.Retrans', the endpoint shall
   consider the peer endpoint unreachable and shall stop transmitting
   any more data to it (and thus the association enters the CLOSED
   state).  In addition, the endpoint shall report the failure to the
   upper layer, and optionally report back all outstanding user data
   remaining in its outbound queue. The association is automatically
   closed when the peer endpoint becomes unreachable.

   The counter shall be reset each time a DATA chunk sent to that peer
   endpoint is acknowledged (by the reception of a SACK), or a
   HEARTBEAT-ACK is received from the peer endpoint.
----------------------

Does this section also apply when SCTP peer is congested?
I have a situation where the remote peer is congested, and it keeps sending
SACKs with a_rwnd = 0.
To simulate this, I establish SCTP association and keep sending data to the
remote SCTP side. The remote SCTP user
is not reading messages from SCTP read queue.

Eventually the local SCTP keeps resending the same DATA chunk(lets say
TSN=100), but the SACKs come in with only TSN=99.
After Association.Max.Retrans, the sending side(local) aborts association as
per section 8.1.
I just wanted to confirm that this is a correct behavior.

Thanks,

Anatoly

-----Original Message-----
From: Randall Stewart [mailto:[email-masked]]
Sent: Wednesday, June 08, 2005 8:49 AM
To: Kacheong Poon
Cc: [email-masked];
[email-masked]
Subject: Re: [Lksctp-developers] Re: ipv6 link local addresses and sctp
bindx

Kacheong Poon wrote:
> Randall Stewart wrote:
>
>> LLS1----INIT()----LL1----> (to address is LL1 and from is the
>>                            proper address [LLS1] for this link out)
>>
>> ... rest of handshake...
>>
>>
>> LLS2----ADD-IP(lookup-addr LLS1)----->LL2
>>
>> Now the add IP would  need to lookup the assoc by LLS1 or
>> we are actually discussing adding a new address type for
>> NAT purposes .. i.e. have a address type == myvtag... that
>> way between the two vtags one could lookup and validate
>> that its the same assoc.. espeically when we add in the
>> AUTH draft... which means the shared/and-or/generated key (per the
>> auth draft) would be used to authenticate the ADD-IP..
>
>
>
> Has any security analysis been done one this?  Without
> knowing the actual spec, it seems that it is quite
> easy for an attacker to arbitrarily generate random
> packets and the SCTP stack needs to do much more checking
> to verify and reject those packets than now.
Please look at the auth draft of Michaels.. in fact
the current ADD-IP document requires it with a MUST
implement and use...

>
> In the above packet, both the source and destination addresses
> are not in any association.

Actually, thinking on this your right.. and I am not
sure it would work then... so maybe this will NOT
work for LL... you can see the general idea we want
to use for NAT though...

  So SCTP needs to parse the packet
> (and all out of the blue packets if it supports the above
> mechanism) to find the "lookup-addr" field and then to lookup the
> association again.  And it seems that both LL1 and LLS1
> addresses need to be present.  With only a vtag (since not
> unique) and one address, it is not enough to differentiate two
> associations to two different remote endpoints.
The auth draft requires a H-MAC SHA-1 signature with a
shared secret... but I think the LLS2 is the real
problem with using this for link locals...

>
> What we have been discussing is the case with multiple
> interfaces on the same link.  It does not really need ADD-IP
> if it is required that all the link local addresses listed
> in the INIT must belong to the same link.  I think this can be
> useful for a simple setup to tolerate NIC failure.

Yep.. but KAME-BSD does not support this.. since I don't
see it has a general solution... and besides.. you still
end up with a single point of failure... aka the one switch.
I suppose you could have more than one.. but one network
is still one network... not two :-0

R
>
>
>> Basically it will work the same way it would work for a NAT..
>>
>> The key of course is the sender must provide the LL addresses
>> with the proper scope to the connectx..
>
>
>

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 20 Jun 2005 14:41:21 -0400

> I had a question about this section in RFC:
How would congestion be an error count... I don't quite
understand this.. an error happens when I have to retransmit
due to a lost packet... if you mean the data is LOST due
to congestion.. then YES.. it would increment the count.. it
basically does not matter WHY the packet is lost.. if it
needs to get retransmitted then it bumps the count (with
one exception).
> I have a situation where the remote peer is congested, and it keeps sending

Please see section 2.2.15 of the Implementors guide.. basically .. in a
nutshell.. you DO NOT increment an error counter during 0 rwnd probes.

> TSN=100), but the SACKs come in with only TSN=99.
Yep..
> I just wanted to confirm that this is a correct behavior.

No this is incorrect behavior... as I said, go look at the I-G..

R

---

From: "Anatoly Khusid" <[email-masked]>
Date: Mon, 20 Jun 2005 15:47:16 -0400

Hi,

You said this:

>if you mean the data is LOST due

Yes, the data is lost due to congestion.

>Please see section 2.2.15 of the Implementers guide.. basically .. in a

OK, I see, so 0 rwnd probes should not incremment an error counter.

Thanks!

Anatoly

-----Original Message-----
From: Randall Stewart [mailto:[email-masked]]
Sent: Monday, June 20, 2005 2:41 PM
To: Anatoly Khusid
Cc: 'Kacheong Poon'; [email-masked];
[email-masked]
Subject: Re: RFC question

Yep..

R