Subject: Re: [pcp] WG last call on draft-ietf-pcp-base-16.txt

From: Stuart Cheshire <[email-masked]>
Date: Wed, 16 Nov 2011 21:41:05 -0800

On 31 Oct 2011, at 10:04, james woodyatt wrote:

> Every standard transport protocol that uses 16-bit port numbers, with the singular exception of SCTP, admits network address-port translation that floats the port number.  SCTP is unique among standard transports in that it was designed with a mechanism, i.e. the verification tag, to facilitate address amplification by network address translators without requiring the port number to float.
> 
> So, yes... the implicit PREFER_FAILURE sematics also imply that, in the special case of SCTP, the fields are sematically equivalent to Internal/External Port and Suggested External Address.

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 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.

   Because an SCTP-aware NAT does not rewrite SCTP port numbers (and
   firewalls never do), a PCP MAP or PEER request for an SCTP mapping
   SHOULD provide the same Internal Port and Suggested External Port.
   If the PCP server supports SCTP, and the suggested external port
   cannot be provided in an explicit dynamic SCTP mapping, then the
   error CANNOT_PROVIDE_EXTERNAL is returned.

I am unclear on how this is supposed to work.

Suppose I have two SCTP-based network cameras at my house.

Suppose both are listening for incoming SCTP connections on SCTP port 1234.

Suppose the external IP address of my SCTP-aware PCP-supporting NAT is X.

As you say, SCTP has this unique feature where SCTP NATs don't rewrite the port number.

Now, I'm in Taipei at the IETF meeting, and I want to view the images from my SCTP-based network cameras. I send an SCTP connection request to X:1234. Which of the two network cameras does that connection request go to? Apparently the verification tag identifies which endpoint I'm trying to connect to. How does my client learn the verification tag to use for camera A and the verification tag to use for camera B? Verification tags are not in the SRV record.

With static TCP port mappings today this works because camera A receives connections sent to X:801 and camera A receives connections sent to X:802 -- the external ports are different. If the external ports have to be the same for SCTP, then how does the client indicate which camera it is connecting to? Or does this simply not work for SCTP? (And it it doesn't work, why are we warping PCP to accommodate something that can never work anyway?)

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: james woodyatt <[email-masked]>
Date: Wed, 16 Nov 2011 22:08:24 -0800

On Nov 16, 2011, at 9:41 PM, Stuart Cheshire wrote:
> 
> Or does this simply not work for SCTP? (And it it doesn't work, why are we warping PCP to accommodate something that can never work anyway?)

In theory, a SCTP-NAT could be willing to recalculate the much more labor intensive CRC-32c checksums on every SCTP packet, and this would alleviate the need to maintain the identity relation of private and public port numbers.

If a SCTP-NAT isn't willing to work that hard, then your SCTP-base residential network camera scenario doesn't work for SCTP, at least not strictly as you describe.  What your camera has to do is embed a PCP client, ask for an unused SCTP port, then use the one assigned to it.  It *doesn't* get to hardcode one and assume that the SCTP-NAT will translate the fixed private port to a variable public port at the address realm boundary; that's what you do with TCP and UDP, but it's *not* the same when you use SCTP.

I suppose this means there's still an issue with SCTP support and PCP in the NAT case (as opposed to the firewall case, which is where SCTP support is really needed).  In the NAT case, you need to be able to ask for an arbitrary external port without having selected an internal port, and if one is available, then the reply needs to succeed and assign the external port.  Simply returning CANNOT_PROVIDE_EXTERNAL because another private address has mapped the your Suggested External Port isn't really helpful in the NAT case.

I propose making an allowance for SCTP, in which the Internal Port can be zero and the Suggested External Port can be non-zero.  If the PCP server supports SCTP, the Internal Port is zero and the Suggested External Port is non-zero but cannot be provided in an explicit mapping to the Internal Address, then the server should be able to reply with a successful mapping to a different external port.

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 28 Nov 2011 09:45:32 -0800

Changed the subject of this email, because it pertains more to SCTP than to
PCP.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stuart Cheshire
> Sent: Wednesday, November 16, 2011 9:41 PM
> To: PCP
> Subject: Re: [pcp] WG last call on draft-ietf-pcp-base-16.txt
> 
> > Every standard transport protocol that uses 16-bit port numbers, with
> the singular exception of SCTP, admits network address-port translation
> that floats the port number.  SCTP is unique among standard transports
> in that it was designed with a mechanism, i.e. the verification tag, to
> facilitate address amplification by network address translators without
> requiring the port number to float.
> >
> > So, yes... the implicit PREFER_FAILURE sematics also imply that, in
> the special case of SCTP, the fields are sematically equivalent to
> Internal/External Port and Suggested External Address.
> 
> 12.3.3.  SCTP
> 
> Now, I'm in Taipei at the IETF meeting, and I want to view the images
> from my SCTP-based network cameras. I send an SCTP connection request
> to X:1234. Which of the two network cameras does that connection
> request go to? Apparently the verification tag identifies which
> endpoint I'm trying to connect to. How does my client learn the
> verification tag to use for camera A and the verification tag to use
> for camera B? Verification tags are not in the SRV record.

And verification tags are not specified by the application 
(similarly, TCP sequence numbers are not specified by a TCP
application).

> With static TCP port mappings today this works because camera A
> receives connections sent to X:801 and camera A receives connections
> sent to X:802 -- the external ports are different. If the external
> ports have to be the same for SCTP, then how does the client indicate
> which camera it is connecting to? Or does this simply not work for
> SCTP? (And it it doesn't work, why are we warping PCP to accommodate
> something that can never work anyway?)

The cameras would have to be listening on different SCTP port 
numbers.

SCTP was designed on purpose to Be Different, and works even worse
than TCP or UDP with IP address sharing, IMHO.  IPv6 is where SCTP
will have its chance to shine.

-d

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 28 Nov 2011 09:48:50 -0800

> james woodyatt
> Sent: Wednesday, November 16, 2011 10:08 PM
> To: Stuart Cheshire
> Cc: PCP
> 	Or does this simply not work for SCTP? (And it it doesn't work,
> why are we warping PCP to accommodate something that can never work
> anyway?)
> 
> 
> In theory, a SCTP-NAT could be willing to recalculate the much more
> labor intensive CRC-32c checksums on every SCTP packet, and this would
> alleviate the need to maintain the identity relation of private and
> public port numbers.
> 
> If a SCTP-NAT isn't willing to work that hard, then your SCTP-base
> residential network camera scenario doesn't work for SCTP, at least not
> strictly as you describe.  What your camera has to do is embed a PCP
> client, ask for an unused SCTP port, then use the one assigned to it.
> It *doesn't* get to hardcode one and assume that the SCTP-NAT will
> translate the fixed private port to a variable public port at the
> address realm boundary; that's what you do with TCP and UDP, but it's
> *not* the same when you use SCTP.
> 
> I suppose this means there's still an issue with SCTP support and PCP
> in the NAT case (as opposed to the firewall case, which is where SCTP
> support is really needed).  In the NAT case, you need to be able to ask
> for an arbitrary external port without having selected an internal
> port, and if one is available, then the reply needs to succeed and
> assign the external port.  Simply returning CANNOT_PROVIDE_EXTERNAL
> because another private address has mapped the your Suggested External
> Port isn't really helpful in the NAT case.

Agreed.

> I propose making an allowance for SCTP, in which the Internal Port can
> be zero and the Suggested External Port can be non-zero.  If the PCP
> server supports SCTP, the Internal Port is zero and the Suggested
> External Port is non-zero but cannot be provided in an explicit mapping
> to the Internal Address, then the server should be able to reply with a
> successful mapping to a different external port.

That should work.  I am leery of additional port=0 complications, but
I don't see a better solution.

-d

---

From: james woodyatt <[email-masked]>
Date: Mon, 28 Nov 2011 10:07:43 -0800

On Nov 28, 2011, at 09:48 , Dan Wing wrote:
> 
> That should work.  I am leery of additional port=0 complications, but I don't see a better solution.

It's okay if the RFC recognizes that SCTP and address amplifying translators for IPv4 are a dog's breakfast, and expressly admits that SCTP support in such cases should be considered OPTIONAL.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 Nov 2011 17:54:00 -0800

> From: james woodyatt [mailto:[email-masked]]
> Sent: Monday, November 28, 2011 10:08 AM
> To: Dan Wing
> Cc: 'Stuart Cheshire'; 'PCP'
> It's okay if the RFC recognizes that SCTP and address amplifying
> translators for IPv4 are a dog's breakfast, and expressly admits that
> SCTP support in such cases should be considered OPTIONAL.

SCTP support in NATs is certainly being considered optional by vendors
for a variety of reasons.

In -18, Stuart added the sentence beginning with "This places an extra 
burden" to pcp-base's existing SCTP text, and I think it captures the 
problem pretty well and sets the proper tone:

	  <t>Because an SCTP-aware NAT does not rewrite SCTP port numbers, a
	  PCP MAP or PEER request for an SCTP mapping SHOULD provide the
same
	  Internal Port and Suggested External Port.  If the PCP server
	  supports SCTP, and the suggested external port cannot be provided
in
	  an explicit dynamic SCTP mapping, then the error
	  CANNOT_PROVIDE_EXTERNAL is returned. This places an extra burden
on
	  the SCTP client because it then has to tear down its listening
socket
	  and try again with a different Internal Port, repeatedly until it
is
	  successful in finding a port it can use.</t>

and I added a follow-on paragraph that simply states:

	  <t>The SCTP complications described above do not occur when
address
	  sharing is not used (e.g., 1:1 NAT, firewall).</t>

Good?

-d