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 <ramon.casel...@cttc.es>wrote: > 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<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. > 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 >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
