Subject: [tsvwg] Post WGLC, comments on revised draft for draft-ietf-tsvwg-sctp-udp-encaps

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 13 Oct 2012 12:20:27 +0100

The questions and comments below are intended to help conclude the edits 
after the close of the WGLC in April. Comments are welcome.

Gorry Fairhurst
(as TSVWG-Co Chair)

-----

1) Which RFCs does this document formally update?

2) I assume we will intended to publish as PS (rather than BCP).

3) Please can each author confirm that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed?

-----

Review comments on this revision of the draft:

Section 4.3 - IPv6 UDP checksum change for tunnel APIs.
The text says:
/ The UDP checksum SHOULD be computed and the SCTP checksum MUST be
    computed./
- This needs to cite draft-ietf-6man-udpzero and ietf-6man-udpchecksum
- If the intent is to allow IPv6 UDP zero checksum it must explain how 
it meets the requirements for detecting paths that do not support this - 
and caution that NAPT/NAT/Firewall,etc traversal may be impacted.
- The issues in firewall traversal may also be noted in the security 
considerations section.
- This draft also needs to say that enabling IPv6 UDP zero checksum 
supports requires that SCTP registers the used port(s) as supporting the 
zero checksum option with the UDP module.
- I do not see a way defined for probing  whether a path will actually 
support a UDP zero checksum. This is needed for a transport - otherwise 
a change of path could result in a broken connection (no IPv6 zero 
checksum support).

- Thoughts welcome on this, since it is a new addition to the draft, and 
incorporating this adds new things to check.

Section 4.3 - Editorial
/port number stored for the destination
    address the packet is sent to (see Section 4.1)./
may be could be better:
/port number stored for the destination
    address to which the packet is sent (see Section 4.1)./

Section 4.3 - Editorial
/Then a lookup is performed to find the association the received SCTP
    packet belongs to./
may be could be better:
/Then a lookup is performed to find the association for the received SCTP
    packet./
and
/The UDP source port is stored as the
    encapsulation port for the destination address the SCTP packet is
    received from (see Section 4.1)./
may be could be better:
/The UDP source port is stored as the
    encapsulation port for the destination address in the received SCTP 
packet (see Section 4.1)./

Section 4.5 - RFC 2119 language?
/There MAY be implementation constraints not
    allowing to process received ICMP or ICMPv6 messages at all./
- may be better written as below, and I am not sure this is a 
requirement, this seems to be captured in the previous 'MUST'.

Section 4.5 - Need to clarify corner cases:
/Implementation constraints could prevent processing received ICMP or 
ICMPv6 messages./

Consider adding something like:
  [RFC5927] describes precautions that are desirable before TCP acts on 
the receipt of an ICMP message.
    Similar precautions are desirable prior to forwarding a UDP Datagram 
to the SCTP module.
    The minimal length ICMP error message generated in response to
    processing a UDP Datagram only identifies the Source UDP Port and
    Destination UDP Port.  This ICMP message does not carry sufficient
    information to discover the encapsulated SCTP association.

Section 4.6 - editorial
Should this Path MTU - with a capital 'P'?

Section 4.6 - editorial
/ If the implementation does not allow to control the dont't fragment
    (DF)-bit contained in the IPv4 header, path MTU discovery can't be
    used. /
may be better as:
/ If an implementation does not allow control of the dont't fragment
    (DF)-bit contained in the IPv4 header, then Path MTU Discovery can 
not be
    used. /

Section 4.7 - Info REF to behave RFC?

Is the intention to suggest using dns names instead of IP addresses, 
this would seem reasonable, and must surely be recommended in an RFC?

Section 4.8 - Query
/ the ECN
    bits MUST NOT be changed during encapsulation and decapsulation./
- I assume this refers to the ECN field in the IP header? (please explain)
- I assume that on reception this field SHOULD be passed to SCTP? 
(please say)
- Is there any procedure that needs to be specified here... or does SCTP 
detect that ECB marks are not being sent to the receiver and elect not 
to mark as ECN-capable, please explain.

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 15 Oct 2012 19:18:54 +0200

Dear Gorry,

see my comments below.

Best regards
Michael

On Oct 13, 2012, at 1:20 PM, Gorry Fairhurst wrote:

> The questions and comments below are intended to help conclude the edits after the close of the WGLC in April. Comments are welcome.
> 
> Gorry Fairhurst
> (as TSVWG-Co Chair)
> 
> -----
> 
Not sure why it has to? The boiler plate of the ID doesn't indicate that any RFC is 
> 2) I assume we will intended to publish as PS (rather than BCP).
The boiler plate says Intended status: Standards Track, so I guess it is PS.
> and BCP 79 have already been filed?
The "Status of this Memo" says:
  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.
What kind of additional statement are you looking for.
> - If the intent is to allow IPv6 UDP zero checksum it must explain how it meets the requirements for detecting paths that do not support this - and caution that NAPT/NAT/Firewall,etc traversal may be impacted.
> - The issues in firewall traversal may also be noted in the security considerations section.
> - This draft also needs to say that enabling IPv6 UDP zero checksum supports requires that SCTP registers the used port(s) as supporting the zero checksum option with the UDP module.
> - I do not see a way defined for probing  whether a path will actually support a UDP zero checksum. This is needed for a transport - otherwise a change of path could result in a broken connection (no IPv6 zero checksum support).
> 
> - Thoughts welcome on this, since it is a new addition to the draft, and incorporating this adds new things to check.
The original text was a MUST for both checksums. Based on comments on the list,
we changed it to a SHOULD for UDP. If I remember things correctly, the comments
were mostly related to IPv4. In the FreeBSD implementation this also covers only IPv4.
What about just requiring the UDP checksum for IPv6? This would make things simpler, right?
>   address to which the packet is sent (see Section 4.1)./
ACK. This change will be in the next revision of the ID.
> /Then a lookup is performed to find the association for the received SCTP
ACK. This change will be in the next revision of the ID.
>   encapsulation port for the destination address in the received SCTP packet (see Section 4.1)./
NACK. You take the UDP source port and store it for the destination, which is the source address of received
packet. You text change would use the destination address of the received packet, which is
not the same.
> - may be better written as below, and I am not sure this is a requirement, this seems to be captured in the previous 'MUST'.
> 
> /Implementation constraints could prevent processing received ICMP or ICMPv6 messages./
> 
> [RFC5927] describes precautions that are desirable before TCP acts on the receipt of an ICMP message.
>   Similar precautions are desirable prior to forwarding a UDP Datagram to the SCTP module.
I didn't had anything related to RFC5927 in mind. I had two things in mind:
* You can process received ICMP/ICMPv6 messages but you can't correlate them
  to an SCTP association and to the v-tag verification.
* You simply can't process them, because the stack doesn't provide them,
  you don't have the privileges to receive them or so on.

To make the first point clearer, the next revision will contain:
If a received ICMP or ICMPv6 packet can not be related to a specific
SCTP association or the verification tag can't be verified,
it MUST be discarded silently.

So I use your suggested text
Implementation constraints could prevent processing received ICMP or ICMPv6 messages.
to cover the second point.
> Should this Path MTU - with a capital 'P'?
ACK. This change will be in the next revision of the ID.
>   (DF)-bit contained in the IPv4 header, then Path MTU Discovery can not be
>   used. /
ACK. This change will be in the next revision of the ID.
> Is the intention to suggest using dns names instead of IP addresses, this would seem reasonable, and must surely be recommended in an RFC?
NACK: We are not requesting to use DNS names at all.
We are just saying (in the first paragraph) that you MUST NOT put
any address in the SCTP packet (which is the IP payload), which may
required NAT translation.

The second paragraph describes how to handle multihomed associations
and the third one how to change addresses during the lifetime of the
association.

This is the same way, how it is done for SCTP NAT traversal.
> - I assume this refers to the ECN field in the IP header? (please explain)
Yes.
> - I assume that on reception this field SHOULD be passed to SCTP? (please say)
Yes. But isn't the IP header passed to SCTP anyway? At least this is my
understanding.
> - Is there any procedure that needs to be specified here... or does SCTP detect that ECB marks are not being sent to the receiver and elect not to mark as ECN-capable, please explain.
If the implementation knowns that it can't send or receive the ECN bits, it
shouldn't announce ECN support.

---

From: "Gorry (erg)" <[email-masked]>
Date: Mon, 15 Oct 2012 19:34:14 +0100

Looks like we are nearly there, see in-line

Gorry

> Not sure why it has to? The boiler plate of the ID doesn't indicate that any RFC is 

Ok find with this - I need to ask.
> The boiler plate says Intended status: Standards Track, so I guess it is PS.
Ok
> What kind of additional statement are you looking for.

Each author needs to just affirm this (sorry for extra red tape) drop me an email off-list and I can tick this off:-)
> What about just requiring the UDP checksum for IPv6? This would make things simpler, right?

You could require checksum for both or define simple machinery for IPv6 - either way is fine for me. 

> packet. You text change would use the destination address of the received packet, which is
Fine with adding your clarification!
> to cover the second point.

I recall we talked before on this - and some new text would be fine in the way you suggest.
> This is the same way, how it is done for SCTP NAT traversal.

If this cites SCTP NAT this should be sufficient for me

> Yes. But isn't the IP header passed to SCTP anyway? At least this is my
Ok - it was just to note this because as I understand this could be implemented as a user-space udp app.
>> - Is there any procedure that needs to be specified here... or does SCTP detect that ECN marks are not being sent to the receiver and elect not to mark as ECN-capable, please explain.

That's ok but: Do you know via the api whether udp provided ecn ? I assume you rely on the handshake to know whether the peer supports ecn (as usual)

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 15 Oct 2012 21:15:03 +0200

> Each author needs to just affirm this (sorry for extra red tape) drop me an email off-list and I can tick this off:-)
Done.
> You could require checksum for both or define simple machinery for IPv6 - either way is fine for me. 
Using MUST for both is what we had and was not acceptable...
Isn't SHOULD for IPv4 and MUST for IPv6 acceptable?
Is defining the machinery for IPv6 related to SCTP. For me it looks like
a generic problem, completely unrelated to SCTP. Am I missing something?
> If this cites SCTP NAT this should be sufficient for me
I'll add it.
> Ok - it was just to note this because as I understand this could be implemented as a user-space udp app.
Ahh, OK. I agree, we can only pass what we need. So I'll change it to:

If the implementation supports the sending and receiving of the
ECN bits for the IP protocols being used by an SCTP association,
the ECN bits MUST NOT be changed during sending and receiving.

This covers both the case where you pass it down/up via the complete
IPv[46] header or via an additional parameter. OK?

> That's ok but: Do you know via the api whether udp provided ecn ? I assume you rely on the handshake to know whether the peer
I know because of I know if I'm running on a platform which provides the IP header or
provides (for example via CMSGs) the DSCP. This can be used to trigger the appropriate
SCTP handshake.
> supports ecn (as usual)

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 15 Oct 2012 21:26:47 +0200

> If this cites SCTP NAT this should be sufficient for me
Correction: In case of the NAT (supporting SCTP) traversal, you have special
parameters in the ASCONF. So I would prefer to not refer to the SCTP NAT documents.
I think the text is clear as is. Or do you have a suggestion for a clarification?

Best regards
Michael