Subject: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-sctp-dtls-encaps-08: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 19 Jan 2015 14:41:18 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-tsvwg-sctp-dtls-encaps-08: 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-dtls-encaps/

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

- I had a discuss on DTLS1.0 as the MTI. I'm told that 
was decided by the WG last Nov in consultation with 
WebRTC and TLS WG chairs, so while I'd prefer to
see DTLS1.2 as the MTI, I've cleared the DISCUSS.

- Figure 1: Couldn't ICE/UDP be somewhat confusing for
someone unaware that ICE is more of an algorithm than a
wire protocol? Might be nice to clarify that here in
the intro. (If you want to be nice, if you don't that's
ok too and can be the right decision.)

- section 3: Isn't "complete SCTP packet" a teeny bit
ambiguous? It could mean including the IP and other
lower headers but I guess you do not. But that's a nit
since it's probably clear enough that you don't put an
IP or layer 2 header into the DTLS payload:-)

- Given heartbleed, and the use here of RFC6520 I think
some note of that famous implementation bug would be
wise. Just to a pointer to how to not have that
problem. But it's not a protocol bug so I'm not trying
to insist, i.e. no need for us to argue the toss on
this:-)

- I'm also wondering if the text here on 6520 is
sufficiently clear given this week's discussion of that
on the rtcweb list. (I'm not on tsvwg@ so would
appreciate an update on how the thread [1] pans out on
the tsvwg list before we approve this.)

  [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg14069.html

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 23 Jan 2015 23:09:14 +0100

> On 19 Jan 2015, at 23:41, Stephen Farrell <[email-masked]> wrote:
> 
Hi Stephen,

thank you very much for your review. Please see my comments in-line.

Best regards
Michael
> see DTLS1.2 as the MTI, I've cleared the DISCUSS.
OK.
> ok too and can be the right decision.)
We are actually using text very similar to the text in
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13

Using ICE might not change the packet format on the wire,
just some TURN messages are multiplexed. However, if a
TURN server is involved, the wire format changes. However,
all that is described in RFC 5245.

However, what about adding to

   This encapsulation of SCTP over DTLS over UDP or ICE/UDP (see
   [RFC5245]) can provide a NAT traversal solution in addition to
   confidentiality, source authentication, and integrity protected
   transfers.

the following sentence:
   Please note that using ICE does not necessarily imply
   that a different packet format is used on the wire.

Would that address your comment?
> IP or layer 2 header into the DTLS payload:-)
I agree that "complete SCTP packet" might not be as clear as possible.
That is the reason why the text reads:
the complete SCTP packet, consisting of the SCTP common header and
a number of SCTP chunks,
Doesn't that make it clear?
> to insist, i.e. no need for us to argue the toss on
I'm not sure if this document is the right place to discuss this.
I completely agree that heartbleed is an implementation bug.
There is already explicit text in
https://tools.ietf.org/html/rfc6520#section-4
which tells an implementer how to avoid it:

   If the payload_length of a received HeartbeatMessage is too large,
   the received HeartbeatMessage MUST be discarded silently.

I can add text stressing this again, but I'm not sure if it helps, since
an implementer should read RFC 6520 and implement the appropriate
input validation as written in the RFC using normative language.
> the tsvwg list before we approve this.)
I think it is clear how to implement PMTUD according to
RFC4821 and using RFC6520 for probe packets. 
The question in the thread was about which of the two
option allowed by this document is used in the RTCWeb
context:
1. DTLS does the PMTUD
2. SCTP does the PMTUD
It was concluded in that discussion that it is clear
in the WebRTC document that option 2 is used.
The other question was why ICMP can't be processed by SCTP.

So I can add some explanation to Section 6.1:

OLD:
   o  The implementation MUST NOT rely on processing ICMP or ICMPv6
      packets.  This applies in particular to path MTU discovery when
      performed by SCTP.

NEW:
   o  The implementation MUST NOT rely on processing ICMP or ICMPv6
      packets, since the SCTP layer most likely can't access the
      SCTP common header in plain text of the packet, which triggered
      the sending of the ICMP or ICMPv6 packet. This applies in
      particular to path MTU discovery when performed by SCTP.

Does that address the issue?

---

From: [email-masked]
Date: Fri, 23 Jan 2015 22:29:13 +0000

Hi Michael,

Thanks those all look good 

S