rfc3002.txt

Overview of 2000 IAB Wireless Internetworking Workshop

   There seems significant issues for continued investigation related to
   enabling continual usage of a device during roaming ("micro
   mobility") and the ability to retrieve previous connections after a
   roaming event.

3.2.2 Discussion on Mobility and Roaming Protocols

   Selection between cellular and IP protocols in support of roaming
   provided another topic for significant discussion.  Cellular
   operators have already deployed protocols providing significant
   support for roaming.  This has led several efforts, such as 3GPP and
   3G.IP, toward architecture relying on telephone system for all
   mobility support, hiding roaming from the IP layer.

   Arguments for cellular-based roaming centered on concerns about the
   mobile IP model.  There was concern that home agent and foreign agent
   involvement in delivery might introduce bottleneck, and the
   perception that mobile IP handoff is too slow.  A rebuttal offered
   was that IETF mobileip working group is introducing hierarchy and
   route optimization to improve performance and robustness [50], and
   there was disagreement on the point regarding slow handoff under
   mobile IP.

   Detriments to the cellular-based roaming include the lack of IP
   support out to the mobile device and the added tunneling protocols
   and overhead required.  Additionally, roaming is less well defined
   when traversing service provider boundaries and may involve highly
   non-optimal forwarding path.  There appears significant work
   remaining to reach convergence on opinions, and additional
   investigation to support roaming across cellular, WLAN, and IP
   boundaries.




Mitzel                       Informational                     [Page 11]

RFC 3002                 IAB Wireless Workshop             December 2000


3.2.3 Discussion on Mobility and Roaming Services

   3G.IP mobility model is primarily focused on providing ubiquitous
   service across a range of access media.  However, the presentation
   also highlighted a desire to develop new "location based" services.
   Examples presented include locating nearby services or receiving
   advertisement and solicitations from nearby business.

   There are several Internet protocols defined, such as anycast service
   [47] and SLP [28], that may aid in developing location based
   services.  However, there was considerable frustration on the part of
   3G.IP in that there appears little commercial support of these
   protocols, and even less direction on how to assemble and coordinate
   the required protocols to deploy the desired services.

   This exchange illustrated the disconnect between interpreting
   Internet standards and telephony service profiles.  First, in the
   Internet many protocols are defined but many are optional.  Protocol
   support is typically driven by market demand, which can lead to
   "chicken and egg" problem.  Secondly, individual protocols and
   applications are developed rather than complete profile to compose a
   commercial service.  For this service, evaluating the usage and
   scalability of service discovery protocols appears to be an area open
   for further investigation.

3.3 Discussion on Security Model

   Mobility and wireless environments introduce many complexities and
   potential attacks to user authentication and privacy.  In addition to
   the discussion presented below, there was an overriding statement
   made regarding the methodology that must be followed for all security
   protocol development.  It was felt quite strongly that the only
   chance for success is that the definition be done in a public forum,
   allowing full disclosure of all algorithms and thorough review by
   security experts.  Stated an alternate way, defining protocols in a
   closed forum relying on cellphone manufacturers, or other non-experts
   on IP security, is very likely to create security exposures.

3.3.1 Discussion on User Identity

   Storage of user identity can have significant effect on device usage
   and device portability.  Discussion focused on whether identity
   should be tied to the mobile device or a transferable SIM card.
   Fixing identification with the device may simplify manufacture and
   provide some tamper resistance, however it makes it very difficult to
   deploy a public device taking on the identity of the user.  These
   alternative also affect transfer of identity and configuration state
   on device replacement or upgrade.



Mitzel                       Informational                     [Page 12]

RFC 3002                 IAB Wireless Workshop             December 2000


   A related topic revolves around the user desire to employ a single
   device but to take on a different identity and privilege based on the
   usage at hand (e.g., to gain corporate access, home access, or
   Internet access).  The ability and ease of assuming these multiple
   identities may be highly dependent on the model of identity
   integration, as discussed above.  Discussion highlighted potential
   pitfalls based on tieing of device and user identities.  IPsec use of
   device IP address inhibits roaming capabilities as the address may
   change based on location, and precludes distinguishing identity and
   capabilities for current usage.  IPsec requires additional work to
   accommodate this added flexibility.

   A final topic of discussion on user identity establishment was
   whether possession of the device is sufficient, or whether the user
   should be required to authenticate to the device.  In the real world
   the first alternative is exemplified by the credit card model, while
   the second is more analogous to the ATM card where the user must also
   provide a PIN code.  Both models seem useful in the real world, and
   it's likely both will have uses in wireless networking.

3.3.2 Discussion on WAP Security

   WAP wireless transport security (WTLS) is based on TLS [20], with
   optimized handshake to allow frequent key exchange.  The security
   service employs a "vertical" integration model, with protocol
   components throughout the network stack.  Some argued that this is
   the wrong model.  A better approach may have been a security layer
   with well defined interfaces.  This could allow for later tradeoffs
   among different protocols, driven by market, applications, and device
   capabilities.

   Additional statements argued that the WAP security model illustrates
   dangers from optimizing for a limited usage domain ("walled garden").
   Content provider systems requiring security (e.g., banks) must deploy
   a special WAP proxy, which breaks the model of a single WAP "domain".
   Similar issues are inherent in gatewaying to the Internet.

3.3.3 Discussion on 3G Network Security

   The existing GSM/GPRS model uses long term shared secrets (embedded
   in SIM card) with one-way authentication to the network, and with
   privacy only provided on the access link.  This is an example where
   the "walled garden" service model has an advantage.  Complete control
   over the service access devices and network greatly reduces the range
   of security concerns and potential attacks.






Mitzel                       Informational                     [Page 13]

RFC 3002                 IAB Wireless Workshop             December 2000


   Future 3GPP and 3GPP2 plan to push IP all the way out to the wireless
   device.  An observation is that this results in more potential for
   exposure of signaling and control plane to attacks.  Desire is to
   perform mutual authentication and securing of the network.  This is a
   difficult problem with additional issues remaining to be solved;
   however the statement was made that relying on IP and open standards
   is more likely to produce a provably secure network than former
   reliance on SS7 protocols and obscurity.

   Completing support for the security requirements of the 3GPP/3GPP2
   network seems to require resolving issues in two primary areas, AAA
   services and mobile IP.  AAA is required for authentication,
   authorization, and billing.  Remaining issues center around cross
   domain AAA, authentication using PKI, and there was considerable
   aversion to use of IPsec and IKE protocols due to perceived overhead
   and delay.  Mobile IP issues revolve around solutions to reduce the
   security associations required between mobile node and home agent,
   mobile node and foreign agent, and the home and foreign agent.  An
   interim solution being investigated involves use of a RADIUS server
   [56]; however, there are concerns with repeated dynamic key
   generation on each handoff or hiding some details of handoffs, which
   may violate assumptions in mobile IP protocol [48].  Evaluating
   requirements and addressing all of these open issues appears to be an
   excellent opportunity for mutual cooperation on open standardization
   and review.

3.4 Discussion on Transports

   Discussion on transport protocols touched on a broad range of issues.
   Concerns ranged from the effects of wireless link characteristics and
   mobility effect on TCP, to development of new transport protocols
   such as WAP Wireless Transaction Protocol (WTP).  In addition, a
   significant amount of time was spent reviewing ongoing efforts within
   the IETF on TCP transport enhancements and investigation of new
   transports.

3.4.1 Discussion on Link Characteristics and Mobility Effect on
      Transport

   TCP makes assumptions on loss as congestion indication.  The
   statement was made that TCP was designed for links with about 1%
   corruption loss, and provided that constraint is met then TCP should
   function properly.  Presentation on IS-95 CDMA-based data service
   showed that it conditions line to provide 1--2% error rate with
   little correlation between loss.  Similar conditioning and Forward
   Error Correction (FEC) mechanisms may be appropriate for other
   wireless and satellite systems [4].  This may not be true for all
   wireless media, but it was interesting in the fact that it indicates



Mitzel                       Informational                     [Page 14]

RFC 3002                 IAB Wireless Workshop             December 2000


   TCP should work properly on many wireless media.  However, the amount
   of discussion and suggestions on TCP performance optimizations showed
   that there can be a considerable gap between merely working and
   working well.

   One issue raised several times was related to the effects of non-
   congestive loss on TCP performance.  In the wireless environment
   non-congestive loss may be more prevalent due to corruption loss
   (especially if the wireless link cannot be conditioned to properly
   control error rate) or an effect of mobility (e.g., temporary outage
   while roaming through an area of poor coverage).  These losses can
   have great detrimental effect on TCP performance, reducing the
   transmission window and halving the congestion window size.  Much of
   the discussion focused on proposing mechanisms to explicitly indicate
   a non-congestive loss to the TCP source.  Suggestions included a
   Non-Congestive Loss Indication (NCLI) sent for instance when packet
   corruption loss is detected, or sending a Source Encourage (SE) to
   stimulate source transmission at the end of an outage.  In addition
   to data corruption, wireless links can also experience dropouts.  In
   this situation any active TCP sessions will commence periodic
   retransmissions, using an exponentially increasing back-off timer
   between each attempt.  When the link becomes available it may be many
   seconds before the TCP sessions resume transmission.  Mechanisms to
   alleviate this problem, including packet caching and triggered
   retransmission were discussed.  The more generic form of all of these
   mechanisms is one that allows the state of the layer two (datalink)
   system to signal to the TCP session its current operating mode.
   Developing a robust form of such a signaling mechanism, and
   integrating these signals into the end-to-end TCP control loop may
   present opportunities to improve TCP transport efficiency for
   wireless environments.

   TCP improvements have been incorporated to support "long" links
   (i.e., those with large delay and bandwidth characteristics) [36],
   however considerable expertise may still be required to tune socket
   buffers for maximum performance.  Some work has been done on auto-
   tuning buffers, which shows promise [58].  An additional problem with
   large windows and auto-tuning is the added header overheads.  This
   may exasperate the problems of running TCP over low bandwidth links.
   Suggestions included to explore dynamic negotiation of large window
   extensions in the middle of a connection to alleviate these issues.
   A final issue raised with regardport (see discussion below in section
   3.4.3).

   There was also concern regarding mobility effects on TCP performance.
   TCP has implicit assumptions on bounding propagation delay.  If delay
   exceeds the smoothed round trip time plus four times the round trip
   variance then the segment is considered lost, triggering the normal



Mitzel                       Informational                     [Page 15]

RFC 3002                 IAB Wireless Workshop             December 2000


   backoff procedures.  Could these assumptions be violated by segment
   loss or duplication during handoff? Work on D-SACK [25] may alleviate
   these worries, detecting reordering and allowing for adaptive DUP-ACK
   threshold.  Finally, there was suggestion it might be appropriate to
   adapt (i.e., trigger slow start) immediately after mobile handoff on
   the assumption that path characteristics may differ.

3.4.2. Discussion on WAP Transport

   WAPF considered TCP connection setup and teardown too expensive in
   terms of bit overhead and latency when required for every
   transaction.  WAPF developed the Wireless Transaction Protocol (WTP),
   with some inspiration from T/TCP [12].  WTP offers several classes of
   service ranging from unconfirmed request to single request with
   single reply transaction.  Data is carried in the first packet and
   3-way handshake eliminated to reduce latencies.  In addition
   acknowledgments, retransmission, and flow control are provided.

   Discussion on WTP centered on assessing details on its operation.
   Although it incorporates mechanisms for reliability and flow control
   there was concern that it may miss critical or subtle transport
   issues learned through years of Internet research and deployment
   experience.  One potential area for disaster appeared to be the use
   of fixed retransmission timers and lack of congestion control.  This
   gave rise to suggestions that the IETF write up more details on the
   history and tradeoffs in transport design to aid others doing
   transport design work, and secondly that the IETF advocate that the