Michael Tüxen | 1 Feb 09:36 2010
Picon

Re: q about draft-stewart-natsupp-tsvwg-00

On Jan 31, 2010, at 10:28 PM, Yoshifumi Nishida wrote:

> 
> Hello, 
> Recently, I've read draft-stewart-natsupp-tsvwg-00.
> I guess the approach will eventually be related to other multi home support transport 
> protocols. So, I personally prefer to use general methods if possible.
> 
> My naive question is why we have to make NAT boxes send SCTP packets.
> Can't we use ICMP Error Packet Translation in RFC5508 for this?
Why not make them send SCTP packets? You need to change them anyway...
In principle, as long as all information needed is available, we could
use ICMP messages. But as I said: What is the difference?
> 
> Also, the draft seems to presume SCTP end nodes can know whether they are behind NAT
> or not. But, how do they know it? ICMP Query Mapping?
This is left open. A node having a private address talking to
a node with a global address knows that it needs to use the mechanism.
You could also use it always, as long as you peer supports it.
> 
> Thanks,
> --
> Yoshifumi Nishida
> nishida <at> sfc.wide.ad.jp
> 

Internet-Drafts | 1 Feb 11:15 2010
Picon

I-D Action:draft-ietf-tsvwg-sctpsocket-21.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Sockets API Extensions for Stream Control Transmission Protocol (SCTP)
	Author(s)       : R. Stewart, et al.
	Filename        : draft-ietf-tsvwg-sctpsocket-21.txt
	Pages           : 92
	Date            : 2010-02-01

This document describes a mapping of the Stream Control Transmission
Protocol SCTP into a sockets API.  The benefits of this mapping
include compatibility for TCP applications, access to new SCTP
features and a consolidated error and event notification scheme.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-21.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-tsvwg-sctpsocket-21.txt): message/external-body, 70 bytes
Yoshifumi Nishida | 1 Feb 11:47 2010
Picon

Re: q about draft-stewart-natsupp-tsvwg-00


Hello Michael, 
Thanks for the response.

From: Michael Tüxen <Michael.Tuexen <at> lurchi.franken.de>
Subject: Re: [tsvwg] q about draft-stewart-natsupp-tsvwg-00
Date: Mon, 1 Feb 2010 09:36:30 +0100
Message-ID: <806F0EC8-DEB5-4AF0-A62D-9AFE669C9121 <at> lurchi.franken.de>

 > > My naive question is why we have to make NAT boxes send SCTP packets.
 > > Can't we use ICMP Error Packet Translation in RFC5508 for this?
 > Why not make them send SCTP packets? You need to change them anyway...
 > In principle, as long as all information needed is available, we could
 > use ICMP messages. But as I said: What is the difference?

I think sending SCTP packet from NAT boxes will require NAT boxes to perform 
source spoofing, which will be a bit tricky. 
Also, although it's not very sure, other trasnport protocols which support multihome 
will be standardilized in future. Using general method will make NAT's implementation
simple rather than using protocol depndent method. 

 > > Also, the draft seems to presume SCTP end nodes can know whether they are behind NAT
 > > or not. But, how do they know it? ICMP Query Mapping?
 > This is left open. A node having a private address talking to
 > a node with a global address knows that it needs to use the mechanism.
 > You could also use it always, as long as you peer supports it.

I personally would like to avoid to make transport layer interprete IP addresses,
but, yes, that's a possible way. Thanks for the clarification.

(Continue reading)

Robin Seggelmann | 1 Feb 16:19 2010
Picon

draft-ietf-tsvwg-sctpsocket: shutdown() with SHUT_RD

In section 4.1.7 of draft-ietf-tsvwg-sctpsocket is described that shutdown() with the SHUT_RD argument
"Disables further receive operations. No SCTP protocol action is taken."

If SHUT_RD disables receiving but nothing is done by SCTP, what happens to messages still send by the peer?
If there is no notification on application layer, the peer doesn't know that its messages won't be
received anymore. And what about notifications? Is it still possible to read them or will the read call
just return an error? Wouldn't that always cause an ABORT because of unread messages left in the receive buffer?

Regards,
Robin
Michael Tüxen | 1 Feb 17:43 2010
Picon

Re: draft-ietf-tsvwg-sctpsocket: shutdown() with SHUT_RD

On Feb 1, 2010, at 4:19 PM, Robin Seggelmann wrote:

> In section 4.1.7 of draft-ietf-tsvwg-sctpsocket is described that shutdown() with the SHUT_RD
argument "Disables further receive operations. No SCTP protocol action is taken."
> 
> If SHUT_RD disables receiving but nothing is done by SCTP, what happens to messages still send by the peer?
If there is no notification on application layer, the peer doesn't know that its messages won't be
received anymore. And what about notifications? Is it still possible to read them or will the read call
just return an error? Wouldn't that always cause an ABORT because of unread messages left in the receive buffer?
I think no protocol action is taken when the SHUT_RD is issued. However, if
a message is received after the SHUT_RD was issued, an ABORT should be sent to
the peer. Not sure if this should be stated in the ID.
What do others think?

Best regards
Michael
> 
> Regards,
> Robin

Michelle Cotton | 1 Feb 23:39 2010
Picon

Re: [Fwd: Re: AD review: draft-ietf-tsvwg-port-randomization-05]

Fernando/Lars,

Following-up on the thread below.

Port Number requests are rejected for many reasons.  Here are three of the most common reasons:

1 - Duplicates a function or protocol already in existence
2 - Is the secure version of a port already applied for or already in existence
3 - Port applied for is of local use only and traffic does not flow over the public Internet


In general, a port number request is granted when an applicant can show a well-defined, public Internet protocol.  The port must identify a named service that allows sessions to be created over the public Internet.  The protocol, in a successful application, will be sufficiently documented to ensure that it is not local or a version of another service already in use.

I hope this information helps.  Please let me know if there is anything I can clarify.

Michelle
IANA


On 1/27/10 11:20 AM, "Fernando Gont" <fernando <at> gont.com.ar> wrote:


>> Have there any cases in which use of a port has been rejected?
>
> Yes.
>
>> If so, what has been that reason?
>
> Depends :-) Maybe IANA can give some examples.



>
>> And what has been the criteria for actually "granting" the use of
>> ports (as the above)?
>
> Satisfying the Expert Reviewer.



Fernando Gont | 1 Feb 23:40 2010
Picon

"assigned" vs. "registered" (was: Re: [Fwd: Re: AD review: draft-ietf-tsvwg-port-randomization-05])

Hello, Michelle,

> Port Number requests are rejected for many reasons.  Here are three of
> the most common reasons:
> *
> 1 *- Duplicates a function or protocol already in existence
> 2 - Is the secure version of a port already applied for or already in
> existence
> 3 - Port applied for is of local use only and traffic does not flow over
> the public Internet
> 
> In general, a port number request is granted when an applicant can show
> a well-defined, public Internet protocol.  

What about all the closed protocols that have been assigned a port
number? My impression is that there are *many* of them.

> The port must identify a
> named service that allows sessions to be created over the public
> Internet.  The protocol, in a successful application, will be
> sufficiently documented to ensure that it is not local or a version of
> another service already in use.

Does the documentation need to be publicly available?

Thanks!

Kind regards,
--

-- 
Fernando Gont
e-mail: fernando <at> gont.com.ar || fgont <at> acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Michelle Cotton | 1 Feb 23:51 2010
Picon

Re: "assigned" vs. "registered" (was: Re: [Fwd: Re: AD review: draft-ietf-tsvwg-port-randomization-05])

If a document (or the individual registrant of a report) requests that a port be removed or de-registered, IANA does complete those requests.
However, the requester has to be sure that no one is using the port anymore.  If the request comes from an individual to remove a port number assignment, an expert review will provide guidance to IANA.  

The documentation for port assignments does not have to be publically available for user ports.

Best regards,

Michelle




On 2/1/10 2:40 PM, "Fernando Gont" <fernando <at> gont.com.ar> wrote:

Hello, Michelle,

> Port Number requests are rejected for many reasons.  Here are three of
> the most common reasons:
> *
> 1 *- Duplicates a function or protocol already in existence
> 2 - Is the secure version of a port already applied for or already in
> existence
> 3 - Port applied for is of local use only and traffic does not flow over
> the public Internet
>
> In general, a port number request is granted when an applicant can show
> a well-defined, public Internet protocol.

What about all the closed protocols that have been assigned a port
number? My impression is that there are *many* of them.


> The port must identify a
> named service that allows sessions to be created over the public
> Internet.  The protocol, in a successful application, will be
> sufficiently documented to ensure that it is not local or a version of
> another service already in use.

Does the documentation need to be publicly available?

Thanks!

Kind regards,
--
Fernando Gont
e-mail: fernando <at> gont.com.ar || fgont <at> acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





Fernando Gont | 2 Feb 00:32 2010
Picon

Re: "assigned" vs. "registered"

Michelle Cotton wrote:

> If a document (or the individual registrant of a report) requests that a
> port be removed or de-registered, IANA does complete those requests.
> However, the requester has to be sure that no one is using the port
> anymore.  If the request comes from an individual to remove a port
> number assignment, an expert review will provide guidance to IANA.

My question is about the procedure for port assignment, rather than for
port "removal".

That is, it is not clear to me what was the policy for assigning most of
those port numbers that correspond to closed protocols. (if it was
really an "assignment", i.e. more than simply a "registration" process).

Thanks!

Kind regards,
--

-- 
Fernando Gont
e-mail: fernando <at> gont.com.ar || fgont <at> acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Bob Briscoe | 3 Feb 13:13 2010
Picon

Re: Generic UDP tunneling (draft-manner-tsvwg-gut-00)

Jukka,

I'm about to send a review of your (& Nuutti's) GUT draft. But some 
of my review relates to Pasi's points in the old thread below. So 
I'll rekindle it, inline...

At 05:59 01/10/2009, Jukka Manner wrote:
>Hi Pasi,
>
>Thanks for the comments, some late replies below.
>
>cheers,
>Jukka
>
>Pasi Sarolahti wrote:
>>Hi Jukka,
>>I had discussed about a generic UDP tunneling scheme with a few 
>>IETF colleagues (including you) a couple of months ago, but the 
>>draft I started to write then got forgotten in my drawer.
>>Of course there is the main tussle aspect about whether starting to 
>>encapsulate protocols generally inside UDP in hopes of better 
>>middlebox traversal is the right step from the standardization 
>>viewpoint (as discussed in earlier BOFs and plenaries, I guess). 
>>Putting that question aside, here are some technical thoughts:
>
>Yes, you are right, whether creating some generic UDP tunnelling is a
>valid goal would need some wide discussion within the community - I
>don't recall what the end resul has been so far, probably against 
>it. My quick-and-dirty draft and spec just wanted to trigger some 
>discussion at least by making one proposal in that direction. The 
>fact still remains, a lot of protocols do not get through NATs or 
>firelwalls, and this harms progress.

There are two reasons new protocols can't be deployed:
i) deliberate: the above tussle where "new = potentially dangerous"
ii) accidental: lazy middlebox designs that don't take account of evolvability

GUT allows (i) to still play out as before.
But at least it aims to remove (ii).

You might want to say this in the draft.

>>I'm a little doubtful about the idea of using a single UDP port for 
>>all protocols. The receiver of the UDP datagrams would need to 
>>carry out the de-multiplexing and forwarding to different protocol 
>>modules and manage the related state, which could as well be done 
>>"automatically" by the UDP implementatation, by using different 
>>port numbers for each protocol.

Pasi, what's the real problem you see?

For me, the problem is that we are having to create a whole sub-layer 
just to get back to where we were before badly designed NATs were 
deployed. But if that's the best we can do, we need to grasp the nettle.

>For the multplexing, the implementation we have is very simple: at the
>receiver, you just get the packet, remove the GUT header, reattach 
>the IP header, calculate a possible checksum if the encapsulated 
>protocol has one, and give the packet to the IP stack. The stack 
>then handles the
>protocols by itself as if it came from the interface directly, the 
>GUT implementation does not need to care about the local IP stack 
>processing after it has rebuilt the original packet. Our 
>implementation on Linux is  only a few hundred lines of code, need 
>to check, but it was quite little (without the fragmentation and IP 
>option handling).
>
>>We had discussed a couple of ways for doing this:
>>1) simply allocate the needed range of UDP ports from IANA for 
>>different protocols (which might be wasteful), or
>>2) (in my opinion) more elegantly, have a separate initiation 
>>phase: first, a client sends a message to a well-known UDP port and 
>>asks what is the UDP port number for tunneling protocol X. If the 
>>client gets a positive response, it can start sending UDP-tunneled 
>>protocol packets directly to the returned port Y without additional 
>>GUT header overhead. In such system it would be easy to add new 
>>protocols for experimentation, for example just by adding new 
>>entries in a configuration file processed by a small application 
>>that listens to the queries at a well-known UDP port and responds 
>>by returning the port numbers for tunneling the configured protocols.
>
>Of these two, I'd take the latter. It sounds pretty okey to me. You 
>could as well send the first encapsulated packet to GUT and have a 
>control message saying that subsequent packets should be sent to 
>port P from now on.

I prefer something like the GUT approach to both of these. The choice 
is between:
1) wasting port numbers
2) wasting round trop times
GUT) wasting header bandwidth

For me, avoiding RTTs is the most important thing for a datagram 
service. It needs to get started with minimum delay. The first 
datagram may be the only one, but fast start is still important even 
if it might be supporting connection-oriented services above it like 
DCCP or SCTP. Short flows are where all the value is on the Internet, 
so we don't need extra RTTs to get started. Then we might as well 
have used ATM.

Building in an unnecessary extra RTT delay should only be 
contemplated if no other way will ever be possible.

>>In any of the above cases, a strong advise should be given to first 
>>try if the native protocol works without UDP encapsulation, before 
>>going into UDP tunneling mode.
>
>Naturally this is the way to go. A scheme like GUT could monitor the 
>original protocol and if a connection does not seem to materialize, 
>try UDP tunneling automagically.

An implementation could try both native & GUT in parallel (perhaps 
heuristically if it has found that every time it doesn't use GUT for 
certain protocols, it gets no response - i.e. the blackhole is 
probably its own NAT).

>>Other issue: I don't get the usefulness of the magic number. If a 
>>well-known port is allocated by IANA, it should be safe to assume 
>>it is used for this purpose. If there are malformed packets, for 
>>example from some older app that doesn't know GUT, they would 
>>likely be rejected at some point in the processing, because the 
>>content would not match any protocol state (or checksum 
>>calculation) of the inner protocol.
>
>This concept was taken from GIST where we use a magic number for 
>this exact purpose, verify that the packet truly (at some level of 
>confidence) is a GIST packet. You could live without it, sure, but 
>you can run into problems later due to unnecessary packet processing.

I also would prefer GUT without the magic number. See my full review for why.

Cheers

Bob

>>- Pasi
>>
>>On Sep 14, 2009, at 7:16 AM, Jukka MJ Manner wrote:
>>
>>>Dear all,
>>>
>>>We submitted the following draft and would appreciate feedback and 
>>>comments from the community.
>>>
>>>The spec is not purely a pen and paper exercise, we have a Linux 
>>>implementation that indicates that the concept works quite nicely, 
>>>at least with the hardware we tried it with (Linux end hosts, some 
>>>out-of-the-box D-link and Linksys NAT boxes in between). We need 
>>>to fix and add a few things, then we can release the 
>>>implementation as open source.
>>>
>>>http://www.ietf.org/id/draft-manner-tsvwg-gut-00.txt
>>>
>>>cheers,
>>>Jukka
>>>
>>>-------------------------------
>>>
>>>A new version of I-D, draft-manner-tsvwg-gut-00.txt has been 
>>>successfuly submitted by Jukka Manner and posted to the IETF repository.
>>>
>>>Filename:     draft-manner-tsvwg-gut
>>>Revision:     00
>>>Title:         Generic UDP Tunnelling (GUT)
>>>Creation_date:     2009-09-14
>>>WG ID:         Independent Submission
>>>Number_of_pages: 12
>>>
>>>Abstract:
>>>Deploying new transport protocols on the Internet is a well-known
>>>problem, as NATs and firewall drop packets with new protocol types.
>>>Tunnelling over UDP is one way to make IP packets hide the actual
>>>payload and enable end-to-end delivery.  This draft proposes a simple
>>>UDP tunnelling encapsulation and end-host operation to enable new IP
>>>payloads, e.g., new transport protocols, to be deployed on the
>>>Internet.
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design  


Gmane