Re: [tsvwg] Comments on draft-ietf-tsvwg-rfc4960-bis-08

[Michael Tuexen <[e-mail]>]

> On 11. Mar 2021, at 16:09, Maksim Proshin [GMAIL] <[e-mail]> wrote:
> 
> Hi Michael, others,
> 
> I'd like to discuss the following particular comment:
> 
> >
> > Section 8.4 " Handle "Out of the Blue" Packets"
> > The whole section assumes that a single SCTP Host is taking care of a computing machine,
> > whereas it can be better for the implementor to have multiple SCTP Host instances taking
> > care of different SCTP Endpoint within the same machine.
> > In my opinion for being considered OOTB, an SCTP packet must be addressed to one of the
> > SCTP Endpoints belonging to a specific SCTP Host.
> But that would mean that you don't get back inn indication that the peer end-point is not
> available, which is bad. It is bad for the peer not detecting this and bad for the host
> when being attacked.
> 
> I think your reasoning about the indication is clear but I don't think that in the case when the host is being attacked, it's a good idea to spend resources on ABORT generation. I would even prefer to silently discard it instead like in the case when SCTP received an invalid cookie. I also think that there are other arguments against ABORT in such case. Based on our 
The specification says:

The receiver SHOULD respond to the sender of the OOTB packet with an ABORT.

So you are free to decide that you prefer to not send an ABORT. This is actually
implemented in FreeBSD by providing a sysctl variable (where the default is to send
an ABORT).
> experience it's a big problem for other SCTP implementations to be deployed because kernel SCTP implementations always abort packets not belonging to them and this might even stop other implementations to be developed. So in my opinion there are pros and cons and as a compromise 
I think the problem is that you run multiple SCTP on a host and don't have an
appropriate demultiplexer. In particular, the kernel implementation seems to be
written under the assumption that there is no other SCTP implementation running
on the host. This is at least the case in FreeBSD and the kernel does even not deliver
SCTP packets to an application using raw sockets. This is the same for any other transport
protocol implemented in the kernel. If you want to use one or more different
stacks, then don't compile the SCTP into the kernel or don't load it as a module.
> I would clearly describe this situation in a spec and put "SHOULD silently discard the packet" similarly to an invalid cookie which will bring a room for restrictive implementations to send back an ABORT. 
> This is probably not just SCTP issue so it would also be good to see how other transports handle such situation and align with them.
TCP is the same. If a TCP stack receives a segment and has no endpoint, RFC 793 says:

    If the state is CLOSED (i.e., TCB does not exist) then
    all data in the incoming segment is discarded.  An incoming
    segment containing a RST is discarded.  An incoming segment not
    containing a RST causes a RST to be sent in response.

At least on FreeBSD, a similar sysctl variable is used to control the sending of the RSTs.

Best regards
Michael
> 
> On Fri, Feb 19, 2021 at 1:02 AM Michael Tuexen <[e-mail]> wrote:
> > On 1. Dec 2020, at 09:07, Claudio Porfiri <claudio.porfiri=[e-mail]> wrote:
> > 
> > Hi, 
> > here are my comments on the draft:
> Hi Claudio,
> 
> thank you very much for the comments. See my replies in-line.
> 
> Best regards
> Michael
> > 
> > Generic:
> > About chunks and timers, I'd wish to observe that having a t3-rtx timer on per chunk is
> > computationally expensive, and that I don't see how it's possible that chunks being 
> > bundled in the same SCTP packet can be lost independently.
> > An effective implementation would have a T3-rtx timer on per SCTP packet and tie 
> > all the transported chunks.
> The specification describes a T3-rtx timer per destination address, not per packet.
> Having a per-packet timer or even a per DATA chunk timer seems to require way to
> much resources. You can improve the loss recover by using similar to RACK, if you
> want.
> 
> However, there was one sentence mentioning this:
> 
> Note: If the implementation is maintaining a timer on each DATA chunk, then only DATA chunks whose timer expired would be marked for retransmission.
> 
> I removed it.
> > 
> > About implementation of rx-buffer: it should be written somewhere that there MUST be 
> > independent rx-buffers on per Association. This come from having observed that 
> > implementations exist that share the same rx-buffer among all the Associations 
> > (and endpoints) and advertise the arwnd with the full shared buffer size.
> > The clear side effect is that a zero-window situation for an Association causes
> > zero-window case on all the other Associations.
> I agree that having a receive buffer for multiple association is a bad idea. And
> I think the specification talks about receive buffers in the context of association.
> Just to make it crystal clear, I added in the section
> Parameters Necessary per Association
> the following text:
> 
> Receive Buffer: Buffer to store received user data which is not yet delivered
>                 to the upper layer.
> 
> > 
> > In section 6.1 "Transmission of DATA Chunks", part A, it's written:
> >       If the sender continues to receive SACKs from the peer while
> >       doing zero window probing, the unacknowledged window probes
> >       SHOULD NOT increment the error counter for the association or any
> >       destination transport address.  This is because the receiver
> >       could keep its window closed for an indefinite time.
> > Actually, when a fault happens at the SCTP User, the indefinite time of zero-window
> > situation may cause a deadlock situation, I have observed that problem in the reality.
> > It would be good suggesting for the implementor to have a supervision for zero-window
> > situation that allows aborting the Association when that state lasts too long.
> As you state, the problem is not at the SCTP layer, but the user not reading data.
> So the SCTP association, the problem is with the upper layer. Therefore it makes
> sense to have a heartbeat like mechanism in the upper layer; like all the
> SIGTRAN layers or Diameter... 
> > 
> > 
> > In section 6.4 "Multi-Homed SCTP Endpoints"
> >   By default, an endpoint SHOULD always transmit to the primary path,
> >   unless the SCTP user explicitly specifies the destination transport
> >   address (and possibly source transport address) to use.
> > In situation where the primary path is not stable, this can cause traffic bouncing
> > between paths. There are cases where cost is different per path, thus the SCTP adopter
> > wants to use the primary path as soon as possible (i.e. when the path is IPSec encapsulated
> > and the bandwidth on secondary IPSec tunnel is less than on the primary),
> > but when the paths have the same cost, moving the association due to t3-rtx expiration
> > towards another path would make the Association to use the path with better quality.
> > That's why I'd change SHOULD with MAY and give the implementor a chance for deciding.
> If you change it to MAY you basically give up to concept of a primary path...
> > 
> > Section 7.3 "Path MTU Discovery"
> >   An endpoint SHOULD apply these techniques, and SHOULD do so on a per-
> >   destination-address basis.
> > In my opinion SHOULD is a MUST.
> But it is allowed to disable PMTUD, for example when used in networks where you know the MTU.
> So SHOULD allows for this.
> > 
> > Section 8.4 " Handle "Out of the Blue" Packets"
> > The whole section assumes that a single SCTP Host is taking care of a computing machine,
> > whereas it can be better for the implementor to have multiple SCTP Host instances taking
> > care of different SCTP Endpoint within the same machine.
> > In my opinion for being considered OOTB, an SCTP packet must be addressed to one of the
> > SCTP Endpoints belonging to a specific SCTP Host.
> But that would mean that you don't get back inn indication that the peer end-point is not
> available, which is bad. It is bad for the peer not detecting this and bad for the host
> when being attacked.
> > With the current description, whenever a situation requires to have separated SCTP Hosts
> > in the same machine, a filtering mechanism is needed to avoid the hosts to mutually abort the
> > traffic, and when the filtering mechanism is implemented the behavior is the one I wish
> > to have in the host itself i.e. to only take care of the traffic directed towards the 
> > SCTP Endpoints defined for it.
> > In the part
> >   8)  The receiver SHOULD respond to the sender of the OOTB packet with
> >       an ABORT.
> > I think that SHOULD is to be replaced by MAY.
> The SHOULD protects the host, a MAY does not.
> > 
> > 
> > Section 16 " Suggested SCTP Protocol Parameter Values"
> >   The following protocol parameters are RECOMMENDED:
> > 
> >   RTO.Initial:  1 second
> >   RTO.Min:  1 second
> >   RTO.Max:  60 seconds
> >   Max.Burst:  4
> >   RTO.Alpha:  1/8
> >   RTO.Beta:  1/4
> >   Valid.Cookie.Life:  60 seconds
> >   Association.Max.Retrans:  10 attempts
> >   Path.Max.Retrans:  5 attempts (per destination address)
> >   Max.Init.Retransmits:  8 attempts
> >   HB.interval:  30 seconds
> >   HB.Max.Burst:  1
> >   SACK.Delay:  200 milliseconds
> > 
> > The timers used depend on the actual network, there are cases where 
> > in order to fulfil the requirements, they need to be set one order of
> > magnitude below the values recommended. (SIGTRAN and RAN).
> > I'd suggest not to state absolute values, but to provide a criteria
> > for selecting those values.
> > In the signaling networks the ratio is 
> > RTO.Max = 4 * RTO.Min
> > RTO.Initial = 2 * RTO.Min
> > HB.interval = 20 * RTO.Min
> > SACK.Delay = RTO.Min / 5
> I understand completely your point and wanted around 2000 (when SCTP was
> initially specified) to write up an RFC describing SCTP parameter settings
> which could be used in signalling networks. This was not possible, since 
> the IETF only describes protocols and setting for the Internet. Signalling
> networks are not part of it.
> The settings used in the document for RTO.Min, RTO.Max, and RTO.Initial
> are based on 6298 and RFC 8961. One can argue if 20 seconds or 30 seconds
> for HB.Interval are better. The SACK.Delay has the value as you propose.
> > 
> > 
> > 
> > Best regards,
> > Claudio Porfiri
> > 
> 
> 
> 
> -- 
> BR, Maxim