RFC Errata System | 1 Feb 02:20 2015

[Technical Errata Reported] RFC4960 (4250)

The following errata report has been submitted for RFC4960,
"Stream Control Transmission Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4960&eid=4250

--------------------------------------
Type: Technical
Reported by: Phung Pham <tidopham <at> gmail.com>

Section: 3.3.4

Original Text
-------------
                     +--------------------------------+
                     |   Cumulative TSN Ack = 12      |
                     +--------------------------------+
                     |        a_rwnd = 4660           |
                     +----------------+---------------+
                     | num of block=2 | num of dup=0  |
                     +----------------+---------------+
                     |block #1 strt=2 |block #1 end=3 |
                     +----------------+---------------+
                     |block #2 strt=5 |block #2 end=5 |
                     +----------------+---------------+

Corrected Text
--------------
                     +--------------------------------+
(Continue reading)

gorry | 31 Jan 14:50 2015
Picon
Picon

TSVWG Status Update February 2015

The list below shows the status of the working group documents as we see
it. Please check below and comment on drafts using the list. Please do
send any corrections/omissions to the chairs.

Gorry & David
(TSVWG Chairs)
February 2015

-------------------------------------------------------------------
Document recently published:

RFC 7417 draft-ietf-tsvwg-rsvp-pcn - Document Shepherd: David

-------------------------------------------------------------------
IDs in RFC Editor Queue (http://www.rfc-editor.org/queue.html) :

draft-ietf-tsvwg-sctp-dtls-encaps - PS - Document Shepherd: Gorry
Replaces: draft-tuexen-tsvwg-sctp-dtls-encaps-01
WG adopted 13/12/2013. Support {AB, IR, SL, MB, TD}
[Milestone: Jan 2014, PS] Implemented in Firefox (FF21).
Required by RTCweb. Comments received.
WGLC ended 28th February 2014.
Comments from Joe Touch (draft updated)
Review comments and revised ID published.
Eric Rescorla has reviewed this.
All authors confirmed no IPR
Write-up submitted, Comments and revised ID.
IESG evaluation: Completed.
----------------------------------------------------------

(Continue reading)

Bob Briscoe | 29 Jan 16:23 2015

Re: partial review of draft-ietf-tsvwg-gre-in-udp-encap-03

David,

OK. Understood.

Bob

At 08:37 27/01/2015, Black, David wrote:
> > A specification like Lucy's is surely solely for
> > an implementer audience.
>
>With my OPS Directorate member hat on (and WG chair hat off), I
>definitely disagree ...
>
>... we routinely review all drafts for appropriate operational
>considerations - see RFC 5706, and in particular Appendix A.1,
>which is definitely applicable to this draft.
>
>Thanks,
>--David
>
> > -----Original Message-----
> > From: Bob Briscoe [mailto:bob.briscoe <at> bt.com]
> > Sent: Monday, January 26, 2015 8:47 AM
> > To: Black, David
> > Cc: tsvwg <at> ietf.org
> > Subject: RE: partial review of draft-ietf-tsvwg-gre-in-udp-encap-03
> >
> > David,
> >
> > Apologies for the ultra-long RTT. Inline...
(Continue reading)

SCTP MH connectx(), INIT collisions and RFC4960 MUST

Hi,

 

We have stumbled into an issue with a MUST in RFC4960 text on INIT Collision handling.

We hope that the wg could help resolve the issue.

 

The issue is the following underlined text of RFC4960 (from RC4460).

 

Section 5.2.1 of RFC4960:

  

 

   Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST

   respond with an INIT ACK using the same parameters it sent in its

   original INIT chunk (including its Initiation Tag, unchanged).

   When responding, the endpoint MUST send the INIT ACK back to the same

   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   address that the original INIT (sent by this endpoint) was sent to.

   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 

   Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST

   respond with an INIT ACK using the same parameters it sent in its

   original INIT chunk (including its Initiation Tag, unchanged),

   provided that no NEW address has been added to the forming

   association.  If the INIT message indicates that a new address has

   been added to the association, then the entire INIT MUST be

   discarded, and NO changes should be made to the existing association.

   An ABORT SHOULD be sent in response that MAY include the error

   'Restart of an association with new addresses'.  The error SHOULD

   list the addresses that were added to the restarting association.

 

 

 

The issue we have can be illustrated by the following example:

 

        A connect() towards peer address X and Y has been made at local EP. INIT is sent to Peer address X.

 

       Peer EP in fact have local addresses Y and Z and an incoming collision INIT is sent from Y including Y and Z as address parameters.

 

       According to the above MUST the INIT ACK should be returned to X which will be completely in vain (of course).

 

 

Note:

 

It is understood that the in order to prevent association high jacking then it is imperative that the INIT ACK be not returned to a peer address

not  specified on the local EP side as a remote address for the association (in cookie_wait). Thus the INIT ACK cannot simply be reflected to sender address.

   

Question:

 

Is this the intention of the RFC4960 MUST to prescribe for this exact operation.

 

Possible answers:

 

·         Yes this is the intention, hopefully the association will be established when local EP re-send INIT to alternative address Y

·         No,  the “MUST” is wrong and should have read – “SHOULD return to a destination address provided in  the INIT which also is specified locally as a peer address for the association (in cookie_wait)”

 

Thanks !

 

BR, Karen

IETF Secretariat | 26 Jan 20:16 2015
Picon

ID Tracker State Update Notice: <draft-ietf-tsvwg-sctp-dtls-encaps-09.txt>

IESG state changed to RFC Ed Queue from Approved-announcement sent
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps/

IETF Secretariat | 26 Jan 20:06 2015
Picon

ID Tracker State Update Notice: <draft-ietf-tsvwg-sctp-dtls-encaps-09.txt>

IANA action state changed to No IC
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps/

IETF Secretariat | 26 Jan 20:06 2015
Picon

ID Tracker State Update Notice: <draft-ietf-tsvwg-sctp-dtls-encaps-09.txt>

IANA action state changed to In Progress
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps/

Bob Briscoe | 26 Jan 14:47 2015

Re: partial review of draft-ietf-tsvwg-gre-in-udp-encap-03

David,

Apologies for the ultra-long RTT. Inline...

At 19:03 21/11/2014, Black, David wrote:
>Bob,
>
> > 1) Regarding congestion control, I do not share the position of some
> > others in tsvwg. Congestion responsiveness is determined by how the
> > source spaces out the packets (i.e. their instantaneous rate). Just
> > because a tunnel ingress encapsulates a packet with a UDP header does
> > not suddenly make it unresponsive to congestion. The spacing between
> > packets is still determined by the source. So there is no need to
> > even mention congestion control considerations in a tunneling
> > document, except to say in the scoping at the start that the addition
> > of tunnel headers is completely orthogonal to congestion avoidance and
> > control.
>
>Unfortunately, it's not "completely orthogonal" because UDP goes many
>places that the encapsulated protocols can't.  Hence "can't get there
>from here" protection in NATs and other middleboxes that drop the
>unencapsulated protocol won't stop non-congestion controlled UDP-
>encapsulated traffic from getting into places that it shouldn't and
>causing damage.  Also, please take note of the text in the mpls-in-udp
>draft that recommends filters to block such traffic from going where
>it shouldn't, which restores some of these protections.

OK, that's correct, but I should have phrased my concern differently.

Advice on where an operator should not deploy tunnel endpoints is a 
run-time concern, for which it is appropriate to advise operators 
(and maybe users). A specification like Lucy's is surely solely for 
an implementer audience. Unless we can say there is something that 
must be implemented along with the tunnel encap/decap, surely we 
should not hold Lucy back.

Yes, we should work on circuit breakers for tunnels. But that's for 
the operator audience. We should not take out our frustrations with 
operators on implementers. We should not hold Lucy and others like 
her back for this. She is innocent in this battle.

Bob

>Thanks,
>--David
>
> > -----Original Message-----
> > From: Bob Briscoe [mailto:bob.briscoe <at> bt.com]
> > Sent: Friday, November 21, 2014 12:30 PM
> > To: Lucy yong
> > Cc: Black, David; tsvwg <at> ietf.org
> > Subject: partial review of draft-ietf-tsvwg-gre-in-udp-encap-03
> >
> > Lucy,
> >
> > I'll wait for David's promised proposal to the list before commenting
> > on the checksum issue.
> >
> > 1) Regarding congestion control, I do not share the position of some
> > others in tsvwg. Congestion responsiveness is determined by how the
> > source spaces out the packets (i.e. their instantaneous rate). Just
> > because a tunnel ingress encapsulates a packet with a UDP header does
> > not suddenly make it unresponsive to congestion. The spacing between
> > packets is still determined by the source. So there is no need to
> > even mention congestion control considerations in a tunnelling
> > document, except to say in the scoping at the start that the addition
> > of tunnel headers is completely orthogonal to congestion avoidance and
> > control.
> >
> > 2)
> > Please replace:
> >     Tunnel end points that support
> >     ECN MUST use the method described in [RFC6040] for ECN marking
> >     propagation.
> > With:
> >     Tunnel end points need to use the method described in [RFC6040]
> > for ECN marking
> >     propagation.
> > Rationale:
> >     i) There is no such thing as a tunnel end point that does not
> > support ECN - it has to put something in the ECN field, and it would
> > not be appropriate to put anything in there other than what RFC6040 says.
> >    ii) Generally it is not a good idea to fill one draft with
> > normative statements that repeat normative statements made in other
> > drafts. Otherwise updating an RFC gets very difficult - we have to
> > update all the other RFCs that gratuitously repeat what it says.
> >
> > 3) Nit in section 3.1.
> >     Section 5 of RFC6936 [RFC6936] specifies the additional requirements
> >     that implementation of UDP zero-checksum over IPv6 MUST compliant
> >     with. To compliant with it, the following additional requirements
> >     apply
> > s/compliant/comply/ (twice)
> >
> > There are other nits, but they can be dealt with later.
> >
> >
> > Cheers
> >
> >
> > Bob
> >
> >
> >
> >
> > ________________________________________________________________
> > Bob Briscoe,                                                  BT

________________________________________________________________
Bob Briscoe,                                                  BT 

IETF Secretariat | 26 Jan 15:38 2015
Picon

ID Tracker State Update Notice: <draft-ietf-tsvwg-sctp-dtls-encaps-09.txt>

IESG has approved the document and state has been changed to Approved-announcement sent
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps/

Barry Leiba | 26 Jan 14:14 2015
Picon

Barry Leiba's No Objection on draft-ietf-tsvwg-sctp-prpolicies-06: (with COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-tsvwg-sctp-prpolicies-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- Section 3.1 --

   The Limited Retransmissions Policy can be used with data channels in
   the WebRTC protocol stack.  See [I-D.ietf-rtcweb-data-channel] for
   more information.

I wonder whether implementors might misunderstand, and think this is
meant to be restrictive.  Please consider changing the wording (here and
in 3.2) to something like this:

NEW
   The Limited Retransmissions Policy was designed to be used with
   data channels in the WebRTC protocol stack (see
   [I-D.ietf-rtcweb-data-channel]), and can also be used in other
   appropriate situations.
END

...or maybe...

NEW
   The WebRTC protocol stack (see [I-D.ietf-rtcweb-data-channel]), is
   an example of where the Limited Retransmissions Policy might be
   used.
END

-- Section 3.2 --

   When storing a user message in the send buffer
   while there is not enough available space, the SCTP stack at the
   sender side MAY abandon other user messages of the same SCTP
   association with a priority lower than the provided one.  The
   algorithm for selecting the message being abandoned is implementation
   specific.

A minor point: the first part is written as allowing multiple messages to
be abandoned, and the last sentence is written in the singular.  Should
the second part say "message(s)" ?

-- Section 4.2 --

The table shows the two policies that come out of RFC 6458 and the two
that come from this document.  Is it worth it to create a (FCFS?)
registry for these names, to document them and provide references?

Jose Saldana | 26 Jan 13:19 2015
Picon

RV: New Version Notification for draft-saldana-tsvwg-simplemux-02.txt


> -----Mensaje original-----
> De: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> Enviado el: lunes, 26 de enero de 2015 13:18
> Para: Jose Saldana; Jose Saldana
> Asunto: New Version Notification for draft-saldana-tsvwg-simplemux-02.txt
> 
> 
> A new version of I-D, draft-saldana-tsvwg-simplemux-02.txt
> has been successfully submitted by Jose Saldana and posted to the IETF
> repository.
> 
> Name:		draft-saldana-tsvwg-simplemux
> Revision:	02
> Title:		Simplemux. A generic multiplexing protocol
> Document date:	2015-01-26
> Group:		Individual Submission
> Pages:		11
> URL:            http://www.ietf.org/internet-drafts/draft-saldana-tsvwg-simplemux-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/
> Htmlized:       http://tools.ietf.org/html/draft-saldana-tsvwg-simplemux-02
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-saldana-tsvwg-simplemux-02
> 
> Abstract:
>    There are some situations in which multiplexing a number of small
>    packets into a bigger one is desirable.  For example, a number of
>    small packets can be sent together between a pair of machines if they
>    share a common network path.  Thus, the traffic profile can be
>    shifted from small to larger packets, reducing the network overhead
>    and the number of packets per second to be managed by intermediate
>    routers.
> 
>    This document describes Simplemux, a protocol able to encapsulate a
>    number of packets belonging to different protocols into a single
>    packet.  It includes the "Protocol" field on each multiplexing
>    header, thus allowing the inclusion of a number of packets belonging
>    to different protocols on a packet of another protocol.
> 
>    The size of the multiplexing headers is kept very low (it may be a
>    single byte when multiplexing small packets) in order to reduce the
>    overhead.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission until
> the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat


Gmane