Subject: [pcp] remapping sctp ports

From: james woodyatt <[email-masked]>
Date: Fri, 14 Oct 2011 17:59:11 -0700

everyone--

Question: is SCTP a transport protocol that uses 16-bit ports from the perspective of PCP servers?  NAT traversal for SCTP is not done by remapping the ports, and it doesn't make sense to ask for a NAT to redirect SCTP public port A to SCTP private port B where A != B due to the need to recalculate the CRC32 checksum it uses.

Perhaps a word about SCTP and its "unconventional" use of port numbers would be in order.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Francis Dupont <[email-masked]>
Date: Sat, 15 Oct 2011 13:52:24 +0200

In your previous mail you wrote:

   Question: is SCTP a transport protocol...

=> is there today a NAPT with SCTP support?

Regards

[email-masked]

PS: don't believe I don't like SCTP but IMHO you more likely
get IPv6 than SCTP...
PPS: the PCP text (but not the question) still applies to firewalls.

---

From: james woodyatt <[email-masked]>
Date: Mon, 17 Oct 2011 10:47:07 -0700

> => is there today a NAPT with SCTP support?

Is there a NAPT today with PCP support?

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 17 Oct 2011 16:24:14 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> james woodyatt
> Sent: Friday, October 14, 2011 5:59 PM
> To: PCP
> Subject: [pcp] remapping sctp ports
> 
> everyone--
> 
> Question: is SCTP a transport protocol that uses 16-bit ports from the
> perspective of PCP servers?  NAT traversal for SCTP is not done by
> remapping the ports, and it doesn't make sense to ask for a NAT to
> redirect SCTP public port A to SCTP private port B where A != B due to
> the need to recalculate the CRC32 checksum it uses.
> 

Added to the Implementation Considerations section, which I have now
broken into normative and non-normative sections (this new text is
normative):

   12.3.3.  SCTP

   Although SCTP has port numbers like TCP and UDP, SCTP works
   differently when behind an address-sharing NAT, in that SCTP port
   numbers are not changed [I-D.ietf-behave-sctpnat].  Because of this,
   a PCP MAP or PEER request for an SCTP mapping MUST provide the same
   Internal Port and Requested External Port, or else the
   MALFORMED_REQUEST error is returned.  SCTP MAP or PEER requests for
   an SCTP mapping always imply PREFER_FAILURE semantics.  If the
   requested external port cannot be provided, the error
   CANNOT_PROVIDE_EXTERNAL_PORT is returned.

Feedback?

-d

---

From: james woodyatt <[email-masked]>
Date: Mon, 17 Oct 2011 16:48:46 -0700

On Oct 17, 2011, at 4:24 PM, Dan Wing wrote:
> 
>   If the requested external port cannot be provided, the error CANNOT_PROVIDE_EXTERNAL_PORT is returned.

I'm not sure whether or how much to say about implicit mappings the semantic difference between SCTP implicit dynamic mapping states, which are a 3-tuple of A) the Local [External/Internal] address, B) the Remote Peer Address and C) the SCTP verification tag, and the composition of explicit dynamic and static mappings for SCTP, which use the local and remote peer port numbers, and which do not [and cannot] use the verification tag.

Perhaps, "If the requested external port cannot be provided in an explicit dynamic SCTP mapping, then the error CANNOT_PROVIDE_EXTERNAL_PORT is return. Because implicit dynamic SCTP mappings use the verification tag of the association instead of the local and remote peer port numbers, explicit dynamic SCTP mappings need only be established by passive listeners expecting to receive new associations at the external port."

---

From: Alain Durand <[email-masked]>
Date: Mon, 17 Oct 2011 17:41:06 -0700

How much user generated sctp traffic is there on the public Internet?
Last I checked, it was zero point zero... Maybe things have changed since I checked, in that case I'd like to see actual numbers.

So, please, let's not over-engineer this, we need to ship the base PCP document. We can always revisit this later.

Alain.

Sent from my iPad

On Oct 17, 2011, at 7:24 PM, "Dan Wing" <[email-masked]> wrote:

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: james woodyatt <[email-masked]>
Date: Mon, 17 Oct 2011 18:01:57 -0700

> So, please, let's not over-engineer this, we need to ship the base PCP document. We can always revisit this later.

I sympathize with your concerns, but none of this would have been an issue if A) the PCP working group had not insisted on making the protocol a candidate for meeting REC-48 of RFC 6092, or B) the various authors of external standards based on RFC 6204 had not insisted on adding support for PCP as a requirement in the revised draft now underway in V6OPS.

You guys are about to spec something that will be in every IPv6 CPE router on the Internet soon.  If you get it wrong, you will break the Internet.  Again.

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Oct 2011 22:14:23 -0400

> So, please, let's not over-engineer this, we need to ship the base PCP document. We can always revisit this later.

That's the mentality that people had about NATs in the late 1990s... which is a good chunk of why the Internet is so screwed up now.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 18 Oct 2011 11:33:31 +0200

12.3.3.  SCTP

   Feedback?
   
=> I am not convinced implicit PREFER_FAILURE is the right choice
but I have no experience of SCTP NATs too...

Regards