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

["Maksim Proshin [GMAIL]" <[e-mail]>]

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 notavailable, which is bad. It is bad for the peer not
detecting this and bad for the hostwhen 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
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 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.

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