Subject: draft minutes

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Nov 1999 12:03:34 -0500

Folks,

Enclosed are draft minutes from the iptel session at IETF. Please send
any comments or corrections, especially if I've accidentally misquoted
you.

Special thanks to Wilhelm Wimmreuter and John Truetken for taking notes.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

Minutes for the IPTEL (IP Telephony) workgroup meeting

Place: Omni Shoreham Hotel Washington DC
Date: Nov. 08. 1999, from 19:30 - 22:00
Reported By: Wilhelm Wimmreuter, John Truetken
Prepared By: Jonathan Rosenberg

The IPTEL working group session was held on Monday afternoon. 

AGENDA:

1. Agenda bashing                     [5 min - Rosenberg]
2. TRIP Framework                     [5 min - Rosenberg]
3. CPL Framework                      [20 min - Lennox]
4. TRIP presentation and open issues  [10 min]
5. Wrap-up                            [10 min - Rosenberg]

1. Agenda Bashing

The agenda was accepted

2. TRIP Framework (Telephony Routing over IP), 

The chair presented the reasons for renaming the GLP to TRIP. 
This was the only change from the previous version. However,
the change was not made in the figures, so the draft will be
resubmitted once more, and than go to IESG. As such, this is the last
opportunity to get any comments in.

3. CPL Framework, Jonathan Lennox:

Jonathan Lennox discussed the changes in the CPL framework document
from the previous version. This includes additional discussions on
handling scripts from multiple users, discussion of script creation
and usage, and general reorganization. Discussion was also added on
the advantages and disadvantages of using traditional turing complete
languages, like Java, in a "sandbox" to introduce safety. Other
Changes included the change from "network systems" to "signaling
servers" and the change from "network model" to "interaction
model". Jonathan pointed out that the main open issue is how to decide 
where to upload scripts, but that this was not a major hurdle to solve.

Jiri Kuthan then raised the issue of whether a more powerful language
should be defined, and to leave it to the service buyer to get the
script right. He suggested that we should discuss business models of
CPL usage to help get this right. The chair objected, stating that
IETF does not discuss business models. CPL provides a service; if you
don't want it, don't use it.

Scott Petrack asked about the status of a document from two meetings
ago on how to upload CPL scripts in the SIP REGISTER method. Jonathan
R. answered that the iptel group had reached consensus
specific transport methods would be done in other groups. For example, 
if SIP is proposed as a transport for CPL, this would be done in the
SIP group. If http were to be used, the work would be done in the http 
group. Jonathan L. was encouraged to resubmit the draft to the sip
group.

James Kempf asked how a UA would know what server to send a CPL script 
to? Can it be more than one? The answer is that there is choice in
selecting a server. Some people now are using DHCP to get the nearest, 
but there are cases where picking one depends on some service
characteristic. In that case, defining a service template for SLP for
SIP servers might be a neat idea.

Jonathan R. then issued a wg last call on the CPL framework. The last
call was for 2.5 weeks. At that point, if there are no revisions, the
framework will be sent to IESG for informational.

4. TRIP presentation and open issues,
Matt Squire, Hussein Salama, and Jonathan Rosenberg

Matt Squire
-----------
Matt Squire began with the security open issues. BGP currently has an
authentication header, but there are no specified or used
authentication algorithms There is also an RFC on using a TCP MD5
checksum, but this has known security holes. IPSEC and/or TLS can also 
be used. There is also some new work on defining nested signatures for 
path attributes. This allows each provider on the path to sign an
attribute, so that the recipient can verify each hops
contribution. However, this interferes with aggregation.

So, the question is: what to do? We clearly need peer to peer
authentication. Dave Oran, wearing his IESG hat, emphasized that the
protocol must allow every implementation to run in a secure mode. He
also emphasized that we should allow TRIP to use different keys than
other applications between the same pair of hosts. The issue, however, 
is whether to mandate a specific security mechanism (IPSEC or
transport layer), or allow both. Dave pointed out that
interoperability is best achieved by choosing one.

Regarding next hop authentication, Matt indicated he thought it useful 
to have at least next hop authentication, to verify that an entity
that changed the next hop and associated attributes is who they say
they are. This is different from peer to peer authentication when the
peer doesn't change the next hop. It was pointed out that this was
basically the same as nested authentication, except with a single
layer of nesting.

Christian Huitema spoke in favor of signatures, as they help to
double-check the information that is provided to you. This can check
cases where a peer has been subverted by an attacker.

Dave Oran suggested that we take this to the list, and should talk to
experienced BGP security experts to get some input.

With that, Matt moved on to the next related issue. BGP defines a
marker field, which seems to have no purpose beyond
authentication. So, if we are not using the BGP authentication
framework, do we need this? Matt asked for input from the group.

The next issue, and the largest open issue in TRIP, is the
intra-domain synchronization. Matt first explains how flooding works,
and then pointed out that there are synchronization issues with
withdrawals. These relate to the problem of wrapping sequence
numbers. Without the assumption of non-wrapping sequence numbers, we
need to use acknowledgements and add some additional semantics to the
protocol. Both Christian and Dave Oran suggest that we should just use 
non-wrapping sequence numbers. Matt indicated that private discussions 
with the other TRIP co-authors had come to the same conclusion more or 
less. Dave suggested actually using the IS-IS mechanism, as it is well 
tested and has been proven correct.

Hussein Salama
--------------
Matt then passed the mike to Hussein, who started with his proposal
for an alternate synchronization mechanism. The basic idea is that
instead of maintaining a CRIB for each internal LS, each LS would
maintain just one for each connected peer. This would be accomplished
by not flooding routes that are not accepted. The chair clarified that 
the big idea was to use the same mechanism used in E-BGP for the
intra-domain synchronization. So long as (1) each LS within an ITAD
has the same policy, and (2) the decision process always assigns
preferences to routes, and selects one, independent of the existence
of other routes, it can be demonstrated that each LS will converge to
the same Loc-CRIB. 

Dave Oran indicated that he wants to make sure we don't violate the
BGP "barrier" feature, whereby changes in intra-domain topology do not 
get exposed in the exterior routing protocol. Peter Flien raised the
issue of how this proposal affects fault tolerance and route
flaps. Jonathan R. answered that even in current interior routing
protocols, like OSPF, there can be periods of inconsistency
inside. The trick is a hold down timer which doesn't propagate the
information until its stabilized. It was recognized by the TRIP
authors that Hussein's proposal would increase the time it takes for
routes to stabilize (Hussein presented a specific example to
illustrate this), and thus we would need to increase this timer,
although we don't know how. The proposal would also add more route
flaps.

Matt went on to the next issue, which is separation of application
layer protocols (i.e., SIP and H.323). There are three approaches:

  - Separate instances of Trip for each protocol.
  - Same Instance, separate databases.
    (Overhead of multiple databases)
  - Same instance same database.
    (search take longer)

David Oran indicated that the latency and overhead issues are an
implementation issue. 

Jim Luciani indicated that based on SCSP experience, each
advertisement received should be for a single protocol. Jonathan
R. indicated that each advertisement adds a route for a single
protocol, but might withdraw routes from other protocols. Jim
indicated that this would be fine. There seemed consensus for this,
which is what we have now.

Joerg Ott indicated that if the attributes were shared across routes
for different protocols, update volumes could be reduced by not having 
to send two separate routes. Jonathan R. indicated he doubted this
would be common, as next hop (including port number) is an attribute,
and H.323 gatekeepers and SIP servers will usually run on different
ports, likely on different machines.

Hussein then raised an issue discussed at the last IETF, of separating 
H.323 into H.323 Q.931 and H.323 RAS. He wanted to do this in order to 
support load balancing of RAS among gatekeepers. Joerg has concerns
about this, since LRQs aren't supposed to cross domain boundaries.

Another open issue is how the message is structured. The current
proposal is that everything is an attribute, and that attributes MUST
appear in ascending order of value in order to ensure grouping of
data. This in contrast to BGP which has specific fields for withdrawn
routes and new routes. The question was: is this OK? It seemed to be
OK, but additional clarification is needed in the document on this.

The final open issue discussed by Hussein was multiple TRIP
identifiers. Should we allow a machine to support multiple virtual
TRIP speakers each with a different identifier? No consensus on this.

Jonathan Rosenberg
------------------
Hussein then handed the mike to Jonathan. The first issue is
capabilities. TRIP supports general capabilities negotiation. Right
now, there is one capability, which is type of routes supported. This
includes the application layer protocol and addressing scheme (SIP and 
E.164, for example), and the address format for the next hop (IPv6,
for example). The question is: are there other capabilities? Since we
can always add others later, there seemed to be consensus to just
stick with that now.

Another open issue is the "BGP community attribute" defined in
RFC1997. Its a general policy tool. Since its not hard to specify, and 
known useful, there seemed to be consensus to stick it in.

Another open issue is on ISUP flavors. The issue is that if SIP-T is
used, and *if* SIP proxies perform flavor translation, they may want
to select next hops based on ISUP flavor support. However, we don't
yet know whether we will need this. Christian felt that you should
only send ISUP where you know it will be understood. As such, there
seemed to be consensus not to include ISUP flavor attributes in the
TRIP protocol.

Finally, Jonathan R. indicated that pricing and capacity have been
taken out of the main TRIP spec in order to advance it. Editors for
these documents who are interested in progressing the work should
contact the chair.

At this point, general questions and comments were taken. One issue
was raised on traps and notifications of route failures. For example,
if a flap causes there to be a time during which no route to some
prefix is available, how does this get propagated? The chair indicated 
that this is not an issue for TRIP itself, but perhaps for a MIB for a 
Location Server.

Another issue that was raised by Dean Willis was on the choice of 16
bits for the ITAD identifier. Dean's concern was that this limits the
number of providers to 64k, which may not be sufficient. The chair
agreed, and suggested 32 bits. Christian expressed concerns about this 
as well. Related to that, if we are not using AS numbers for ITADs
(there was consensus NOT to use AS numbers for ITADs), we will need to 
set up an entire process for ITAD number administration. Rather than
doing this, it was suggested to use domain names, or perhaps even a
UUID, as an ITAD number. It might be long, but will avoid the need for 
additional administration which can hamper deployment.

Finally, the issue of whether RoutedPath is mandatory or optional was
raised by Reinaldo Penno. Right now its mandatory, but liste as an
open issue. Reinaldo emphasized that he wants to keep it mandatory.

5. Wrap up

Jonathan Rosenberg concludes the meting and asks the attendees 
again to contribute on "Pricing & Capacity" attribues.