Subject: Re: [Pce] PCE port number

From: Vishwas Manral <[email-masked]>
Date: Tue, 2 Aug 2011 14:31:54 -0700

Hi folks,

I heard this very issue came up again in the PCE, after a couple of years.
Do you want me to finally put out a draft for this?

I think this is a basic change and requires a lot more then an errata, as
this changes the basic protocol functioning.

Thanks,
Vishwas

On Fri, Sep 11, 2009 at 10:01 AM, Vishwas Manral <[email-masked]>wrote:

> Hi Adrian,
>
> It would have been ok if it was a connectionless transport like UDP.
>
> However I notice a problem when I want multiple sockets to use the
> same port number in particular cases. I figured that I cannot have a
> server socket (accepting connections) as well as a client socket
> trying to connect having the same port number, though I can allow same
> port to be shared across multiple sockets in some cases by using the
> socket option SO_REUSEPORT.
>
> Thanks,
> Vishwas
>
> On Fri, Sep 11, 2009 at 9:33 AM, Adrian Farrel <[email-masked]>
> wrote:
> > Hi,
> >
> > For my part (I only worked as an author quite late in the process, but I
> was
> > helping to get this through the IESG review that raised issued about TCP
> > ports) I think Julien has not captured the point.
> >
> > The RFC is not silent about source ports because it does intend to limit
> the
> > scope.
> >
> > As Julien says, it does matter which port is listened on, and this is
> > deliberately a well-known port number so that it is not necessary to
> > configure (or advertise) the port that must be called.
> >
> > But in Section 4.2.1 you will find...
> >
> >  Only one PCEP session can exist between a pair of PCEP peers at any
> >  one time.  Only one TCP connection on the PCEP port can exist between
> >  a pair of PCEP peers at any one time.
> >
> > One way to help ensure this is to reduce the number of available ports to
> > use as the source port.
> >
> > Does restricting the source port cause any implementation or deployment
> > problems?
> >
> > Thanks,
> > Adrian
> >
> > ----- Original Message ----- From: <[email-masked]>
> > To: <[email-masked]>; <[email-masked]>;
> > <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Thursday, September 10, 2009 9:57 AM
> > Subject: Re: [Pce] PCE port number
> >
> >
> > Hi Vishwas.
> >
> > Interesting comment. We must admit the wording is a bit ambiguous.
> >
> > RFC 5440 says: "The system listens to the PCEP-registered TCP port" and
> > "Upon receiving a TCP connection on the PCEP-registered TCP port"; I do
> not
> > see any behavior description for the source TCP port (good thing!).
> > My guess is that there is no intend to put constraints on the TCP
> initiator
> > port. I would interpret the sentence you mention as "using the registered
> > TCP port on the PCE side, i.e. for the source TCP port for PCE to PCC
> > messages and for destination TCP port for PCC to PCE messages"... A
> little
> > cumbersome, I agree.
> >
> > Authors of RFC 5440, would there be an actual intend to specify
> otherwise?
> > Implementers, any other interpretation?
> >
> > Thanks,
> >
> > Julien
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Vishwas Manral
> >
> > Hi,
> >
> > I looked at the following in the spec:
> >
> > “Transport Protocol
> >
> >  PCEP operates over TCP using a registered TCP port (4189).  This
> >  allows the requirements of reliable messaging and flow control to be
> >  met without further protocol work.  All PCEP messages MUST be sent
> >  using the registered TCP port for the source and destination TCP
> >  port.”
> >
> > This has been worrying me a bit. Unlike other protocols like BGP or LDP
> >
> > In BGP it states clearly:
> >
> >  A BGP implementation MUST connect to and listen on TCP port 179 for
> >  incoming connections in addition to trying to connect to peers.
> >
> > and
> >
> >  BGP's destination port SHOULD be port 179, as defined by IANA.
> >
> > Why do we have this restriction on source port? It is becoming a
> > challenging task
> > in merchant OS.
> >
> > Thanks,
> > Vishwas
> > Vishwas
>

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 03 Aug 2011 01:31:55 +0200

El 02/08/2011 23:31, Vishwas Manral escribió:
> Hi folks,
> I heard this very issue came up again in the PCE, after a couple of 
> years. Do you want me to finally put out a draft for this?
> I think this is a basic change and requires a lot more then an errata, 
> as this changes the basic protocol functioning.
>

Hi Vishwas

Indeed, I presented the issue in IETF80 in Prague, you may want to check 
the slides [1-2],  plus several mails to the list (along with private 
ones) discussing technical aspects as BSD sockets, Linux, reuseaddr etc. 
as a follow up of yours (and others) concerns during latest stages 
(~2009). During the meeting, it seemed a consensus that it was worth 
changing, after checking potential security implications. I was hoping a 
final answer would be given during IETF81.

IMHO, I do believe that an errata should be enough, since only the 
actual protocol transport is affected, not the protocol itself (well, 
true, the transport is somehow part of the protocol but... :)
 From a practical point of view, the client just needs to allow the S.O 
to select an ephemeral port, and avoid a (potentially problematic) bind 
syscall. It can be argued that forcing the bind does not improve security.
Removing this restriction actually simplies both the client/server.

Backwards compatilibily is only problematic in the case where the 
accepting side of the TCP connection (i.e. the PCE acting as a TCP 
server) actually enforces the incoming source port, rejecting the connection

A (completely limited, unofficial, ...) survery did not show that this 
specific point was affecting a lot of implementations (none?)

Thanks and best regards
Ramon

[1] http://www.ietf.org/proceedings/80/minutes/pce.htm

[2] http://www.ietf.org/proceedings/80/slides/pce-0.pdf

-- 
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 2 Aug 2011 16:51:35 -0700

Hi Ramon,

Great to see you have done extensive work in this area. I had brought this
up earlier on the list, and I knew of the problems impending. Infact I
remember talking to Julien at one of the IETF's about this.

With that said, this is basic functionality change, about which port a
protocol should use. I do not think, we can make a change about the
transport as an errata. It very clearly is the case of a new draft required,
we can expedite this through the IETF processes so that it is made an RFC
soon.

Let me know if you are willing to help writing the draft. I think it is a
necessary requirement that will help the PCE community, which I only see
growing.

Thanks,
Vishwas
On Tue, Aug 2, 2011 at 4:31 PM, Ramon Casellas <[email-masked]>wrote:

> the slides [1-2],  plus several mails to the list (along with private ones)
> discussing technical aspects as BSD sockets, Linux, reuseaddr etc. as a
> follow up of yours (and others) concerns during latest stages (~2009).
> During the meeting, it seemed a consensus that it was worth changing, after
> checking potential security implications. I was hoping a final answer would
> be given during IETF81.
>
> IMHO, I do believe that an errata should be enough, since only the actual
> protocol transport is affected, not the protocol itself (well, true, the
> transport is somehow part of the protocol but... :)
> From a practical point of view, the client just needs to allow the S.O to
> select an ephemeral port, and avoid a (potentially problematic) bind
> Backwards compatilibily is only problematic in the case where the accepting
> side of the TCP connection (i.e. the PCE acting as a TCP server) actually
> enforces the incoming source port, rejecting the connection
>
> [1] http://www.ietf.org/**proceedings/80/minutes/pce.htm<http://www.ietf.org/proceedings/80/minutes/pce.htm>
>
> [2] http://www.ietf.org/**proceedings/80/slides/pce-0.**pdf<http://www.ietf.org/proceedings/80/slides/pce-0.pdf>
>
> --
> Ramon Casellas, Ph.D.

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 03 Aug 2011 02:01:47 +0200

El 03/08/2011 1:51, Vishwas Manral escribió:
>  It very clearly is the case of a new draft required, we can expedite 
> this through the IETF processes so that it is made an RFC soon. 
I guess I am not knowledgeable enough about best/current IETF-related 
practices & procedures, so I will humbly step back and let others decide 
:) (chairs?)

>  Let me know if you are willing to help writing the draft. I think it 
> is a necessary requirement that will help the PCE community, which I 
> only see growing.
If this is the case, gladly, although I guess it would be a one-page 
"Updates" RFC?
R.

---

From: [email-masked]
Date: Wed, 3 Aug 2011 08:54:08 +0800

Hi Ramon, Vishwas

I think the WG prefer to use RFC errata, 
Please check the presentation material "WG status" in IETF81

Ramon Casellas <[email-masked]> 
发件人:  [email-masked]
2011-08-03 08:01

收件人
Vishwas Manral <[email-masked]>
抄送
[email-masked]
主题
Re: [Pce] PCE port number

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

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 2 Aug 2011 20:02:56 -0700

Hi Zhang,

Thanks. It very clearly mentions Errata is only an option. :) Like I
mentioned we have discussed thiw about 2 years back, and you can look at the
archives for some of the details.

-Vishwas

On Tue, Aug 2, 2011 at 5:54 PM, <[email-masked]> wrote:

>   *Ramon Casellas <[email-masked]>*