Re: [XCON] BFCP over UDP

[Joerg Ott <jo at netlab.tkk.fi>]

Hi,

being a co-author of the BFCP spec, I am not really comfortable with
this at this point.

As I mentioned in a private note before, the draft to date appears
to be ignoring some of the potential dangerous issues.  UDP was
(intended to be) deprecated for SIP for good reasons.  Even for
BFCP, it brings up quite a few issues of congestion control and
security.  These critical aspects are not yet mentioned in the
draft.  The security considerations are empty!

I cannot believe that we seriously want to discuss about the textual
integration into the main spec if we haven't understood/sorted out
these details.

Will the proposal MANDATE the use of ICE and STUN to help against
attacks?  Will it MANDATE DTLS?  Will it deal with congestion control?
How will this be done?

All this could *really* make me nervous.

As a WG chair of a MMUSIC I have seen how little interest there may
be in certain aspects, so I would not take silence as consent here.

I suggest that the authors go ahead to to figure out all the
issues in their individual contribution and solve them and, once there
is a promise that this can go well, ask for integration with the BFCP
spec.  This may all go very well, but I would not accept to create
perceived facts _before_ it is clear that the approach is a workable
one.  The current suggestion seems to be taking two steps at once.

Cheers,
Joerg

Gonzalo Camarillo wrote:
> Hi,
>
> OK, we can do a bis then. I will coordinate this effort together with 
> the authors of the draft below.
>
> Cheers,
>
> Gonzalo
>
> Geir Arne Sandbakken wrote:
> > Gonzalo,
> >
> > The UDP usage draft does utilize transaction ids more and has a few 
> > extra messages to get reliable delivery.  The changes are still very 
> > minor to the protocol itself and our implementation of it.
> > IMHO having a single way of operating the protocol is better than 
> > having two different modes of operation.  Also as mentioned in San 
> > Francisco it makes any intermediaries easier to implement only having 
> > to forward messages independent of transport.   Can we do a bis?
> >
> > Geir Arne
> >
> > Gonzalo Camarillo wrote:
> > > Hi,
> > >
> > > the following (expired) draft was presented in the XCON session in 
> > > San Francisco:
> > >
> > > http://www.watersprings.org/pub/id/draft-sandbakken-xcon-bfcp-udp-00.txt
> > >
> > > The agreement was that given the problems TCP has with NATs (the 
> > > P2PSIP WG is currently discussing the same issue) it would be a good 
> > > idea to define a more NAT-friendly transport for BFCP. The proposal 
> > > was to simply use UDP (this is what existing deployments do).
> > >
> > > Since BFCP messages can be rather long, we would need an 
> > > applicability statement saying which types of messages cannot be used 
> > > over UDP.
> > >
> > > In order to specify the new UDP-based transport we can either put 
> > > together a new draft or revise the BFCP specification. I got the 
> > > action point to list the things that could be fixed in a potential 
> > > revised BFCP spec. These are the contents of my notes. Of course, if 
> > > someone knows of more issues, please let us know:
> > >
> > > o When a user performs a third-party floor request the beneficiary of 
> > > the floor is not informed when the floor is granted. This may not be 
> > > a problem because endpoints using third-party floor requests probably 
> > > have different means to get in synch but we may want to add some text 
> > > about this.
> > >
> > > o We do not have errors for an unsupported version of the protocol or 
> > > for wrong message length. We do not have a general error either.
> > >
> > > o When we get more experience on queue management from real 
> > > deployments, it would be nice to explaining it further in the spec.
> > >
> > > o UserStatus
> > >
> > > UserStatus =   (COMMON-HEADER)
> > >                   [BENEFICIARY-INFORMATION]
> > >                 1*(FLOOR-REQUEST-INFORMATION) -> remove the 1
> > >                  *[EXTENSION-ATTRIBUTE]
> > >
> > > o A message may need to be longer than the maximum message length 
> > > supported by the protocol
> > >
> > > o A rather small number of typos
> > >
> > >
> > > As you can see, at this point there are not so many things to fix... 
> > > so, the simplest way forward may be to simply specify a new UDP-based 
> > > transport for BFCP. In any case, I would like to get feedback from 
> > > folks operating BFCP deployments.
> > >
> > > A different alternative (the one the P2PSIP WG is looking at) would 
> > > be to either use a UDP encapsulation for TCP or to specify a new 
> > > transport protocol... but these alternatives may be more complex than 
> > > just using UDP.
> > >
> > > Comments?
> > >
> > > Thanks,
> > >
> > > Gonzalo
>
> _______________________________________________
> XCON mailing list
> XCON at ietf.org
> https://www.ietf.org/mailman/listinfo/xcon