1. Introduction *

2. SIP Activity *

3. Security *

4. Mobility *

5. IPv6 Transition *

6. Multicast *

7. E-Business *

8. IRTF *

9. IP Storage BOF *

10. Sessions *

1. Introduction

This report provides a summary of discussions that took place during the 47th IETF meeting, held between 26th and 31st March 2000 in Adelaide, Australia. The contents of this document are based on personal notes taken during the meeting, and do not provide an official record of the meeting. The official proceedings are available from the IETF web site.

The opinions and interpretations expressed herein are those of the author, and do not necessarily represent those of the IETF, the working group chairs, or other persons mentioned herein. If this document differs in its record of events from the official proceedings of the meeting, then those proceedings should be considered accurate.

The remainder of this document is organised according to working group or BOF title.

The meeting covered many areas, but we were not able to cover more than a small part. In Section 2, Here we consider the Session Initiation Protocol; this has a wide relevance to many areas – not only the multicast conferencing for which it was invented. Much of this work was discussed in Colin Perkins report. There were many sessions on security; I consider mainly in Section 3 the IPSEC sessions; in fact it was agreed that Authorisation, Authentication and Accounting (AAA) was the greatest need for many things – particularly mobile and IP telephony. There are many documents on it, but we did not attend the meetings. We spent considerable time at the Mobile sessions as mentioned in Section 4; Mobile IP was only one of the areas considered. Of considerable importance were the sessions on IPv6 transition, considered in Section 5; the operational transition has been slow, but most of the problems have been considered carefully. Some of the multicast sessions are considered in Section 6; most were treated in the report by Colin Perkins. E-business is considered in Section 7; the sessions were not very deep, and were at a different level of depth than the others. Sessions on the Internet Research Task Forces (IRTF) could have been important; the short part considered in Section 8 was the only part that we mention. The IP Storage BOF is considered in Section 9, and a few of the other sessions in Section 10.

2. SIP Activity

There was a large amount of activity. There was a lot of discussion on the SIP extensions; this should be out soon, and then be maintained in the light of experience. Third party control is important. There was a lot of activity on SIP resources; QoS is still being considered; SDP needs extension. For privacy, one needs header privacy. They must somehow trust proxies. This needs a Remote-Party ID and some options. So far they are considering security only for the user, not necessarily the device.

There were number papers on SIP extensions. Others treat SIP security.

3. Security

1. PKI

Many documents are being progressed, but they are not very interesting. There was a deprecation of DES. While this might apply in general, it was stated that one should consider whether the information is sensitive compared to the threat.

2. Intrusion Detection (idwg)

Most of the meeting was spent discussing the message format draft, an eXtended Markup Language Document Type Definition.

Clients should not need to manage distributed IDs: too much state is required, and they could be overwhelming under a high-volume attack. So the query and response DTD elements were deleted. They are also better discussed in the transport part of the WG. For this reason, the heartbeat element was also removed.

• Authentication of messages: the transport protocol authenticates messages as they arrive, but longer-term authentication is needed for using messages as trial evidence, for example. The output of the XML digital signature group could be useful here. However, public-key operations may be too expensive when monitoring a high-bandwidth link; hash signatures could be used. XML digsig support will be made optional in this draft. Alternatively, authenticated arriving messages could be stored in a trusted manner: the secure system log group's work will be relevant.

• IDMEF Wrapper: Should the draft keep the top-level IDMEF wrapper? As the WG agreed to delete the query, response and heartbeat elements, only alert remains and could be top-level itself. No -- IDMEF gives flexibility to introduce other elements later.
• OS-Specific Needs: Are OS-specific process-ids, names, usernames etc. needed? Should lowest-common denominator formats be used? More discussion is needed on mailing list.

1. IP Security extensions (IPSEC)

There is not too much of interest from IPSEC, but lots from SPKI.

• Drafts update

• Explicit Congestion Notification and gss-auth about to expire -> ripe-md in IESG queue
• WG members are not interested in implementing Certicom's Elliptic Curve draft if patent licenses are necessary

• Draft in preparation by Steve Bellovin on IPSEC compatibility with output of sigtrans group (SCTP, new transport protocol). Internet Key Exchange protocol must be extended to support multi-home systems as SCTP allows connections to be maintained over several IP addresses and multiple Security Associations are too expensive to set up. Draft would add support in the Domain of Interpretation and Security Policy Database.

• Public Key Suites Hillary Orman requested comments on her draft describing appropriate suites of public-key and symmetric algorithms and hash sizes that are of equivalent strength for use together. WG felt draft was useful and should be published as informational RFC.
• Advanced Encryption Standard options were discussed for inclusion as an IPSEC cipher. Cipher Block Chaining mode with 128-bit default keys and variable rounds should be base. Private algorithm IDs are being chosen. Diffie-Hellman (key exchange) modulus and exponent lengths need to be selected to match cipher strengths given various values of those options.
• Heartbeat Functionality Two proposals made for adding heartbeat functionality to IKE. Requirements are detection from seconds to minutes, scalability, and simplicity. WG felt they added overhead for little gain; discussion will continue on mailing list.
• Need and methods for fixing the IKE authentication were discussed. Exchange types, flags and extra payloads are not authenticated in RFC 2409, leaving protocol open to minor attacks. WG decided hash must include all packets sent and received, including Internet Security Association Key Management Protocol headers. The logical location for this was the Security Association payload. No consensus could be reached on whether to fix the hash in a backward compatible way, or create a simpler IKE 2 where other problems could also be fixed. Further discussion will take place on the mailing list.
• A draft to allow IPSEC transport mode in overlay networks by de-coupling routing and keying using IP-in-IP was discussed. Tunnel IPSEC interferes with these networks too strongly. The proposal was very controversial as the WG felt that other, simpler methods existed to provide this functionality.

1. IP Security Policy (ipsp)

• IPSEC configuration policy model draft: describes UML-based policies, conditions and rules, Internet Key Exchange phase 1 and Domain of Interpretation settings. WG were asked to consider whether policy and implementation should be split and policy directionality on mailing list.

• Security Policy Specification Language is a vendor-independent way to control objects. Draft has now been updated to better match the Policy WG's output.
• IPSEC policy compliance checking: Matt Blaze described his work in a fast, verifiable policy-checking module. It allows a small, formally designed verifier to be split off from the main IPSEC code, including speed and security. IPSEC already does packet filtering to maintain policies, but this work manages Security Association verification using a 'meta-filter'. IKE negotiates policies then passes them over for checking. A KeyNote checker has been implemented in OpenBSD 2.6 and can also be used to distribute policies.

1. Open Security Area Directorate meeting (saag)

• Common Authentication Technology (cat) is dormant. A new Kerberos group is being chartered with Doug Engert as chair.
• Secure System Log (syslog) WG will be chartered before next IETF meeting. It is concerned *only* with a protocol and not specific events and data formats.

• Use of DES Scott Bradner and William Simpson have written a draft deprecating the use of DES in *all* IETF standards. Should it be accepted? Jeff Schiller (Security Area Director) felt that DES is strong enough to last until the Advanced Encryption Standard is chosen by NIST at the end of this year. While its security is relatively weak, almost all systems implementing it will anyway have far more glaring problems with OS and application security issues. An engineering trade-off decision should be made rather than a theological security one. Moving over all protocols to Triple DES now would be a waste of time given its inefficiency and the length of time the changeover would take. This point was controversial, given that 3DES performance is now where DES performance was a few years ago (due to CPU speedups). A compromise that seemed to be accepted was that any new security functionality in ANY IETF draft should support AES; we already know roughly what its blocksize and keysize will be since all candidate ciphers are similar in those regards.
• IETF Support for NIST How can IETF support NIST in moving AES process along in a timely way? Should Schiller write a letter to the Department of Commerce (NIST's parent) asking for current timetable to be adhered to? Some cryptographers felt we shouldn't hurry the process so it can receive full scrutiny; AES will have to last 20 years or more. Meeting was undecided whether there should be one or two AES ciphers: two provide potentially weaker security (attacker will go for weakest one) but encourage applications to allow alternate ciphers, easing changeover process in future. Agreed compromise was that Schiller would write to DoC simply emphasising how important the AES was to the IETF, e-commerce and Internet security, and that standards are waiting to use it.

6. ICMP Trace-back BOF

Some papers:

http://www.cs.washington.edu/homes/savage/traceback.html
ftp://ftp.tislabs.com/pub/IDIP/DISCEX_IDR-Infrastructure.pdf
ICMP Traceback Messages

<draft-bellovin-itrace-00.txt
Bellovin, AT&T labs

There were Questions whether ISPs will permit a mechanism that will express topology, on the privacy implications, and on what Authentication mechanism is best

Marcus leach has a Linux implementation using libpcp  + GNU MP. Itrace packets are generated one in every 20,000 packets. Partial deployment would be useful. Doc editor choosen: Jayhawk

3. Mobility

1. IAB Workshop, Nokia, Mountain View, February 29 – March 2, 2000

1. Introduction

This was a meeting held by the IAB, to consider what needed to be done. The attendance was by invitation. ATT was considered as an example of what an operator needed to do. Nokia was well represented. They considered especially Transport Issues, mobile IP and the impact of the wireless technology. The complete presentations are on the Web.

2. Hinden – Summary

There will be very large numbers of devices. What will be the impact on IP protocols, look at WAP, and mutually education. They will make recommendations to IAB, IESG, IETF, and IRTF.

Did 802.11 and Bluetooth, WAP, air traffic, transport and QoS, current WWW protocols over small screens, addressing requirements, compression and bit errors.

The main subjects were what can one learn, cost of staying with Ipv4, compare Ipv4 and IPv6, what is needed to make IPv6 work well. The outline is provided in www.iprg.nokia.com/-hinden/IAB-workshop/.

3. Chih Lin, ATT

They are concerned with the future. The Carriers care for seamless working over cable, DSL, etc. They want seamless mobility support. 3G.IP formed in May 99; 10 operators (ATT, BT, TIM/CSELT, Telenor, T-Mobil, SBC Bell South, NTT), 7 suppliers (Ericsson, Nokia, Lucent, Nortel, Motorola, Siemens, Alcatel). 3GPP Release 2000 uses GPRS. They care that there can be input from many mechanisms. They care on convergence from anywhere – including international. Also important is a Virtual Home Environment as in the home office. They expect first IP and GPRS, with a gateway between them – this may need Mobile IP and a GPRS tunnel. There are still outstanding problems in Architecture and services, Call control, Connectivity management - QoS (RTSVP, DIFFSERV) and routing (including tunnel concatenation, MIPv4 versus MIPv6). Directories, location, AAA, trust.

4. Phil Karn/Sally Floyd, ATT

There has been lots of work with TCP over satellite and networks. There are many like RFC 2488, 2760, asymmetry, performance enhancing proxies, advice for subnet designers, extension to Selective Acknowledgement (SACK), end-end implications of errors, explicit information of congestion and error. Most is done in pilc wg. Many solutions are out there now.

5. Charlie Perkins (Nokia)

Talks about how Mobile IP fits into wireless. It provides mobility between subnets. It needs AAA, multi-level mobility management Mobile IPv6. There are several AAA meetings here. AAA uses C/o address, they need to interact with AAAF and AAAH (to Foreign and Home Agents). Needs authorisation and accounting. This is a major part – and it will have to go forward. It must have security association with home AAA server rather than Home agent. This is needed also for access to RADIUS. The AAA must supply the security information. Needs a new security model for key distribution; needs many new activities. They need a broker to deal with large number of domains. This is same as NAI and Radius servers. Needs handoff between foreign agents – from previous agents. They need hierarchical Foreign Agents. Mobile node registers only once with home agent. Usually only one level of hierarchy is considered. This can make it look like GPRS. It can also be done with an all-IP model. One also needs micro-mobility. These are being put on mobile IP v6. It has enough addresses, security, address auto-configuration, route optimisation, destination options, and reduced soft state. Suggests putting AAA in router. IPv6 is better because of the cut through.

Deering said that the addition of AAA in the middle seems a bad idea.

6. Phil Karn (QUALCOMM) IP over CDNA Digital Cellular

This needs no change in cellular sites – like IS-95 CDMA. Hopes that Globalstar will survive. It was developed for voice channels. Typical loss rates in design was 1-2% for voice, needs low delay for voice. This has very small bytes – with low acknowledgement times and a reliable stack. IP/PPP/RLP/IS-95. This works well. Emphasised that political arguments are the most important. They are now developing High Data Rate (HDR); it does not care about voice. It is more like ADSL I a throughput depending on load and distance. It can talk only to base stations. Data rat3e 38.4 – 24000 Kbps; in reverse they use 53 ms frames – 48 – 307 Kbps. They still need ARQ, but have an IS-707/IS-95. There is no ad hoc mode, centrally managed. The role of cellular data versus 802.11 is still unclear.

7. Chris Burke (Motorola) WEIRD Wireless

Looks for the inter-relation to other http://home.earthlink.net/~serotonin/Hot Topic.htm. They say that applications, transport, security, internet, general, user services operations, routing and BOFs. PILC and ROHP are examples of new working groups. Wireless is needed in 60% of the existing WGs. Important considerations are bandwidth scarcity, unpredictable, mobility+security+QoS.

8. Brian Carpenter – Draft Recommendations

Needs communications between WAPF, MWIF, 3GPP, and 3G.IP. Probably not joint working groups, but mutual document review and IETF should give rationale for their choices.

He felt the IETF should target open – not walled garden – model. They should make things work through the garden wall, and neighbour discovery. There was consensus that NAT is bad at that scale, RSIP is dubious, and IPv6 is the way to go – which also makes NAT for IPv6 is also bad. We may have to deal with application level gateways for some time. This requires that one must provide enough addresses. Encourage Mobile IPv6 and needs NGTRANS (has not worried about mobile), and needs AAA solution also. One must document Internet Transport, get requirements from wireless people, putting them into TSV in particular. Investigate mechanisms for improving performance in non-congestive loss, transport set up, and other improvements. Routing needs getting BGP to support IDRP particularly for te Aeronautical Communications system.

One must look at the last hop for mobile Host QoS, particularly if there is a mixed wired/non wired last hop. One should look at applications mobility, IP/Bluetooth, TCP/IP stack performance in WAP-like environment, Inter-domain AAA, recommend proxy architectures, investigate tokenised protocol encoding (intelligent compression).

9. Questions and Answers

There was a strong statement of 3GPP collaboration not being good enough – but now this is going forward. They say that they are working hard on it from the radio side to collaborate. TRW mentioned the importance of machine-machine communications – that is why space and near traffic control were needed. These are important on the medical side?? There is a deliberate attempt to have this happen through 3GPP2 for IMT2000. They have adopted Mobile Ipv4 for the time being. Some wanted dual stacks. There was an agreement that they will put in IPv6 later into their stacks. There was still a question of how AAA should be put in. They needed to be able to reference RFCs.

On IPv6, it is clear that they will go to IPv6 soon – the question is how soon. They think NATs are bad, but are needed. There are interactions of QoS at different levels. There will be some text on QoS hints for subnet designers from the PILC group.

There was mention of SIP useful for signalling – and possibly for mobility. There may be a BOF on Bluetooth. They also want to see how mobility is better managed on SIP vs H.323. There is a question of Application and Network mobility; they must be considered at different levels.

1. Mobile IP IPv4

1. Introduction

All the mobile IP sessions were very well attended. Alan O’Neill (BT) and Scott Carson (Maryland U) stated that Mobile Enhanced Routing seems to be better than Mobile IP. MANIC seems to be another view. They want to have a hierarchical tree – one for each host. They seem to need make before break to new access routers. They do local updates and tunnels to individual access routers (core router, intermediate router, edge router and access router – to mobile host). They must eventually return used addresses.

There is a lot of work on mobile IP and security. There is a problem because there are both authorisation and encryption headers. There are problems on whether duplicate address detection is needed; this is partly where the address comes from. There is also a question how it can be optimised. Can one overlap it with transmission? There is also a question whether there is something different between mobile and fixed nodes for mobile hosts. There is a serious problem in supporting telephone calls with these delays. Dynamic Home Agent Address Discovery is supported differently.

There was a major discussion of how to manage mobility. The present working group of Mobile IP had some discussions of whether hard and soft hand-off should be discussed by the working group. Particularly the 3GPP2 group thought it should be considered. There were considerable discussions of mobile regional registration. They have now put in challenge-response; they have introduced a regional foreign agent, and some authentication changes. They can have multiple hierarchies – without going up to a gateway foreign agent.

There was a major discussion on fast hand-off in mobile IPv4 and IPv6. There was some question whether one has to have mobile-IP hand-off versus doing things at the radio level. There is a need also to de-register also. There are also mobility anchor points – for registering. You need home and care of addresses. There was interest by many in optimising hand-offs with changes to mobile-IP. There were also strong objections to making changes to Mobile-IP. It is clear that any such changes will be resisted. Other drafts discussed include GRE keys and sequence number conflicts for the wireless IP (. This RFC 2784 is now a Standard. There is a question whether one should re-order – because of clashes between the same at the higher level. A major problem is to reduce latency. There are often secure tunnels – then one should use an aggressive IKE mechanism. You need to establish keys via IKE, KDC or AAA. There are HA and FA registration.

Sidemen’s was concerned with handling private addresses and disparate address realm (2344bis describes how they be used). However others felt this problem is not a mobile IP one (PIPE). It wants to have a separate VPN space – to give an extra an extra address space. Clearly the management is particularly important. There is no attempt to tackle the NAT routing problem – which is the hard one.

There were a number of comments on route optimisation and updates. This is like registration. They felt that binding updates should be rationalised between binding updates and registrations. There is need for security associations provided both the FA and HA have keys. There is discussion of using elliptic curve groups. There is also discussion of with and without AAA – the last giving keys. This is in other drafts. The security questions are very important. Again the Public Key Infrastructure is not really understood by the mobility group.

There was a discussion on 3G technology. They field ubiquitous, multimode, efficient, high QoS (at least wired); best efforts were claimed not to be good enough. Wants personalised mobility. The slide showed there was a major difference still between the mobile and Internet community.

There was discussion of a network access identifier. This was needed in 2794 and others they need mobile, foreign, home and previous Foreign. They think more are needed. It was not agreed how this should be treated.

Another discussed the session ID extension – home address allocation. SIP through Firewalls and Gateway registration is problems.

There was a discussion on WAP. This talked about wanting to work over all links layers. They wanted to work across all the link layers, but be able to work with most single contents. Where link layer supported IP, used UDP. Otherwise a specific new message-orientated transport level. They have their own session protocol and everything above it. They also wanted to support different message centres for SMS in particular. There was discussion on the WAP IPR issue; no comment was made on the outstanding patent issue. There is a major problem of SMS addressing versus IP addressing. There was a discussion on how much WAP depends on hand-held sizes. He thinks that this will stay relevant.

Now there was a discussion on DoCoMo’s I-mkode3 by Max Hatta. It is a wireless IAP, 71g, 2.5z. It has a subset of HTML 3.0 with specific tags. It has 5M users and 7.5K service providers. He is showing the direction they are going. Their latest 502 LCD has a colour display – 1M per two months in Japan – coming up now to 2M users. They had 17M Internet users, 3M personal PCs. They had 28M cellular phone users – out of a total of 48M phone users (125M population). They first have voice, then e-mail, information services, then transaction (airline, finance, etc), and then information (guides, restaurants) finally entertainment (karaoke, radio, etc). Finally it has normal Internet access. They provide a very personal Internet Web and mail service on a digital cellular phone network. Packet mode is charged only on amount of data charged. There is a push mail delivery (with personalised audio on arrival). There is a subset of HTML to lower the entry barrier. There is a subset of HTML, and uses standard IP technology (SMTP, HTTP). They have a packet layer direct on the personal network. It has the normal protocols where possible. They use phone numbers and PMAP for now, with a cellular-Internet gateway. They are moving now over to full IP in the radio side. They use QPSK (42 Kbps) in the link layer, with a 1/100 to 1/10,000 error; it also has a 14.2 Kbps ARQ. The final error performance is 1/1,000,000. They have a simple ARQ transport – giving 9.6 Kbps in 1400 B packets. They limit a web page to 5IB – limited normally to 2 KB recommended 94x72 pixels – using HTTP. The limit of messages is 500B (250 Japanese characters), working at 800 MHz. One can click on small thing like a phone number. They expect to use JAVA in the fall of 2000 (including games), and go to the 3^rd generation in the spring 2001. Higher speed digital will start in spring 2001 – up to 384 Kbps; they are then working on music and video – followed by conferencing. They will move further to Internet standards – particularly the IETF.

There was an Ericsson discussion on the telephones. He admits the end-end transparency problem (RFC 2775). Clearly he disagrees with walled garden and single service. They are going packet-switched via GPRS now. Better support for QoS, new spectrum, better cellular technology. However, there are issues on applications, IPv6, DNS, mobility, TCP performance over wireless LAN, cellular, satellite. There would be deployment problems in going to 500M subscribers, and header compression. They should concern themselves on how wireless affects the drafts. Some are going to be considered in the BOF tomorrow. IP tunnelling is already there in GPRS. IP is fully in the plan for 3G – though it is not there yet. There was a specific comment that phone system could be earlier if radio was put in Pads directly.

Latif, from Ericsson, sponsored a Connectathon meeting in U of New Hampshire that did a lot of IPv6 testing including Mobile IP. It included Tahi, Sun. ESP is easier than AH. Mutable bits, routing headers, chained headers and multiple AH headers cause problems with RFC 2402. TAHI IPSec IPv6 is at http://www.tahi.org/ipsec-demo/ ; they did mainly manual keying. Johnston (CMU) talked of mobile IPv6. Versions 10 and 11 have now come. There were some changes because of the Connectathon. Duplicate address detection (DAD) is vital; it must use the same procedure as at home, asking the Home Agent to do it. Another is performing DAD for Care of Addresses. This must be done every time one moves, but it may take a long time. It is specified in RFC 2462; this must be looked at again for mobile IP. Movement detection for mobile nodes is very difficult, and must be changed. Finally Dynamic Home Agent Address Discovery had to be changed. Mobicom 2000 in Boston is next

2. Routing zones and bordercasting

<draft-ietf-manet-zone-zrp-03.txt
http://www.ee.cornell.edu/~haas/wnlprojects.html#RWN
ZYGMUNT J. HAAS,  Cornell University

The hybrid Zone Routing Protocol (ZRP) can adapt to a wide variety of network scenarios by adjusting the range of the nodes' proactively maintained routing zones.  Large routing zones are preferred when demand for routes is high and/or the network consists of many slowly moving nodes. On the other hand, smaller routing zones are appropriate in situations where route demand is low and/or the network consists of a small number of nodes that move fast relative to one another.

The global reactive component of the Zone Routing Protocol (ZRP) uses the unicast/multicast based "bordercast" mechanism to propagate route queries throughout the network, rather than neighbor-broadcast based flooding found in traditional reactive protocols. Bordercasting leverages knowledge of local network topology to direct route queries away from the source, thereby reducing redundancy.

The ZRP consists of two components, the proactive IntrAzone Routing Protocol (IARP), and the reactive IntErzone Routing Protocol (IERP). The ZRP philosophy allows for a great degree of flexibility in the implementation of either component.

Using OPNET link state and distance vector versions of the IARP have been developed. Their basic operation is similar to traditional protocols like OSPF [G] and RIP [H], except that the propagated route information is restricted to the scope of a routing zone (controlled by means of a hop count field).

3. Ad Hoc On-Demand Distance Vector (AODV) Routing - Update

<draft-ietf-manet-aodv-05.txt
Charles Perkins, Nokia

The Ad Hoc On-Demand Distance Vector (AODV) algorithm enables dynamic, self-starting, multihop routing between participating mobile nodes wishing to establish and maintain an ad hoc network.

There was an update that covered a problem when participating systems reboot and forget routing info causing routing loops. To prevent this possibility, each node on reboot waits for a DELETE_PERIOD. In this time, it does not respond to any routing packets.

For IP address auto-configuration the comparison was made with zeroconf use of 169.254/16 and Duplicate Address Detection (DAD). AODV does not provide ARP so instead the use of RREQ (route request) using the selected source address (from 169.253/16). It retries and takes the address if no RREP is received.

Other issues:

• IPv6 version
• Should RREQ/RREP contain source routes (if so how long should they persist)?
• Rethink service discovery extensions

2. Optimised Link State Routing Protocol (OLSR)

<draft-ietf-manet-olsr-01.txt

The protocol is an optimisation of the pure link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs).

Implementations:

• HIPERLAN project at INRIA for WaveLAN 802.11 10 Mb/s 2.4GHz, on Linux2.2.12, FreeBSD3.3 and WinNT4/98 http://donald2.inria.fr/hiperlan/hiperlan.html
• IP level OLSR at University of Aalborg
• PRIMA project
• COMPAS project http://menetou.inria.fr/compas using Multicast OLSR

2. Edge Mobility Architecture

<draft-oneill-ema-01.txt
Scott Corson, University of Maryland Alan O'Neill, BT

The context is that a special form of routing is required when there are stable networks in the core but mobile nodes on the edges.

This draft concurs with the authors of Cellular IP and HAWAII regarding the need for domain-based routing support in handling edge mobility.  It suggests that a general routing solution might be advantageous and presents the loose framework of a possible routing architecture. It also suggests a specific protocol based on TORA for the implementation of such architecture.

The protocol based on TORA exploits soft hand-over on CDMA.

3. IP Mobility Support for IPv4, revised

<draft-ietf-mobileip-rfc2002-bis-00.txt
Charles Perkins, Nokia

Updates:

• Agent Advertisements may be made more times per second
• SPI must be included in authentication Extension

MN must not use ARP when away

7. Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network

<draft-ietf-mobileip-3gwireless-ext-03.txt

This document defines extensions to the Mobile IP protocol to allow mobility management for the interface between a radio network and a packet data network in the third generation cdma2000 network.

It defines how mobility is managed over the RP interface (between the Radio Network Node (RNN) and the Packet Data Serving Node (PDSN)). Uses port number 451 for access to RP.

8. Route Optimisation in Mobile IP

<draft-ietf-mobileip-optim-09.txt

The Route Optimisation Authentication Extension now includes subtype when authenticator value is computed:

• Smooth Handoff authentication type
• Binding warning authentication type

7. Registration Keys for Route Optimisation

<draft-ietf-mobileip-regkey-01.txt

Route optimisation defines extensions to Mobile IP Registration Requests that allow datagrams in flight when a mobile node moves, and datagrams sent based on an out-of-date cached binding, to be forwarded directly to the mobile node's new binding.  These extensions for smooth handoff require a registration key to be established between the mobile node and foreign agent.

The ways to get the keys are:

• Set-up an SA with FA and HA
• Get public keys for FA or MN
• Use Diffie Hellman (standard or elliptic curve) it is a lot faster.

AAA is not considered. They use Generic key distribution extensions.
 

7. Universal Mobile IP (UMIP) Location Management

<draft-wang-mobileip-umip-00.txt

A system for avoiding triangle routing in Mobile IP by providing location registration (LR) nodes. This was presented at the Washington IETF - it was decided that is was too big a redesign and thrown out.  

8. Generalised NAI Extension (GNAIE)

<draft-mkhalil-mobileip-gnaie-00.txt

The Mobile IP Extensions Rationalisation (MIER draft-mkhalil-mobileip-mier-03.txt) specification defines a new extension header format that is intended to extend the Mobile IP extension address space. The Generalised Network Access Identifier (NAI) extension  should be used by any Mobile IP extension specifying an extension containing an NAI.
 

2. Mobileip - IPv6

<draft-ietf-mobileip-ipv6-11.txt
Charles Perkins, Nokia

Updates:

• Completed WG last call
• Mobile node must use care-of address in ISAKMP exchanges - otherwise it may be denied access.
• Problems with ESP for Binding updates. There are two alternatives:

• Only use AH and not ESP
• Repeat critical fields inside binding update

• Duplicate Address Detection bit is set by sending mobile node to request HA does DAD on MN home link. Only valid when Home Registration (H) and Acknowledge (A) bits are also set.
• IPv6 Stipulates DAD for new IPv6 addresses - DAD can take a while...(complains that rfc2462 is ambiguous and contradictory)
• Dynamic Home Agent address discovery - New ICMP messages
• Sequence number increment in Binding updates

1. Reverse Tunnelling for Mobile IP, revised

<draft-ietf-mobileip-rfc2344-bis-01.txt

Updates:

• New Appendix: Disparate (or private) Address Space (DAS) Support
• Supports DAS

1. AAA Registration Keys for Mobile IP

<draft-ietf-mobileip-aaa-key-01.txt
C. Perkins, Nokia

MN can not communicate with AAA to get keys - Need HA to send keys from AAA to MN. The document specifies extensions to the Mobile IP Registration Reply packet that can be used to distribute such security information to the mobile node.

FA keys encoded as Opaque tokens for use in hand-off process
Problem: Getting AAA keys, either:

• Get new keys (expensive)
• Get the keys from a previous FA

1. Private IP Encapsulation within IP (PIPE)

<draft-petri-mobileip-pipe-00.txt
Petri Bernhard

It is an extension of IP in IP from rfc2003. Adds the use of realms by way of a vpn-id (rfc2685):

• VPN OUI (IEEE 802-1990 Organisationally Unique Identifier http://standards.ieee.org/regauth/oui/index.html)
• VPN-index

5. Mobile IP Session Identifier Extension

<draft-ietf-mobileip-sessionid-00.txt

• The Network Access Identifier can be added to a Mobile IP registration request to identify the user and to allow the assignment of a dynamic home address. However, users may want to open several simultaneous sessions using the same NAI from the same or different devices and to obtain a unique IP address for each session.  The Mobile IP Session Identifier Extension defined in this draft can be used to distinguish registration requests belonging to these various sessions. It's like a remote DHCP.
• IPv6 support updated: better interaction with IPSEC (use of home address for Security Association fine for use with Authentication Headers). There is still a problem with ESP that the Home Agent address is exposed so AH must be used for binding updates. This doubles the cryptographic overhead if encryption is needed. Group will work with IPSEC WG on possible solutions.

• Duplicate Address Detection bit has been added to binding update messages so that the Home Agent can do DAD explicitly rather than impose the overhead of checking every time a care-of address changes.
• Dynamic Home Agent discovery is now done using 2 new ICMP packets.
• Minor updates have been made to the new version of the main Mobile IP RFC (2002bis).
• Draft of update to RFC 2344 discussed that allows reverse tunnelling with private addresses. This draft should soon be ready for last call.
• Authentication, Authorisation and Accounting requirements draft has had minor updates and will be ready for last call soon. Two uncontroversial drafts that allow a Home Agent to supply AAA keys to mobile nodes have had interoperability tests done, and should be moved forward on standards track.

4. IPv6 Transition

1. Introduction
2. IPv6 MIBs

Dave Thaler noted that RFC2465 defines an IPv6Address type. For IPv6 specific MIBS and draft-ops-endpoint-mib-07.txt  a protocol independent InetAddress type is defined.

3. Transition

1. Transition Mechanisms

There was a session on this, but it was not very informative. Carpenter discussed the current state of the transition document; it concentrated on 6-4 Conversion. It mentioned that it would be set up so that 4-6 was mandatory, 4-6 optional, and also did 4-4 and 6-6. He also discussed the need for DHCPv6, and where DNS needed to be modified for IPV6. The activity of tunnel brokers was considered. Both Fujitsu and NEC have implementations of these – and have set up about 5K per year. There were also discussions of changes needed in the TCP and UDP forwarding drafts. It was not obvious that much transition had happened yet.

There are a lot of documents under way. Various things about addressing are ready for draft standard – but need experience first. The same applies for the re-numbering draft. . The documents for DNS extensions need some experience. Separating Ids and locators, and the TLA assignments are ready. The case for IPv6 is nearly ready; great interest was raised by the IPv6 Forum at Telluride. Now that document is nearly ready. There is a lot of IP/ox that are nearly ready for Draft Standard (this includes Ethernet, FDDI, Token Ring, ARCNET, PPP) and ICMP Name Look-up for experimental.

There are problems in secure Neighbour Discovery. This can use IPSEC with IKE and policy; specific parts are still needed. Any Host can be a router. This makes mobile nodes very much slower. This is a problem – which must be addressed. Unicast IKE and a KDC is a generally interesting mechanism. They want a lightweight authentication – including source address. There is already link security in 802.11, so it should be possible what the "link 255" hack (whatever that is).

Haberman is concerned with neighbourhood listener discovery (NLD). Its MIB comes from IGMPv2. The latter is ready also. They still want source filtering and versions based on IGMPv3; they also want Generic Group Management – we must look into this for SPAR.

There is a lot of work with Authentication etc with AAA servers. There must be an AAA protocol between Host and AAA (Authentication, Authorisation and Accounting). There are already some servers for this. There is a lot of work in local registration and new connections. There is also a major question where the charges are made – via global roaming, local charging, and eventual home AAA if needed. This should be discussed in AAA working group. There is also a question of hiding names of users. Keys can be handed down. They need DHCP and neighbour discovery extensions.

There is a new NGI transition overview, which still has security issues. It should be out soon. There will be a workshop to discuss transition at the end of May or early June in the Bay area. SLAC has done some very careful measurements – mainly by Pings. Warren Mathews described it, and it uses small bandwidth – Poland has a good site. The system is much simpler than the Surveyor project – which is much more expensive. They have set up a 6Bone registry by Kessens – now from Nokia. This is working with around 539 sites, 740 persons on the Mbone. There was a discussion on root DNSs; these can use the normal IPv6 set. The new B IND 9.00b2 will be important here.

Itojin (WIDE) discussed how some of the transition technologies could be abused. This may already be RFC 2553, but looking at some other ones. One possibility is if you set up a server for one say IPv6; if you have dual stacks, you may have access from IPv4 without opening the socket.

2. Draft on Abuse of IPv6

http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-00.txt
Jun-ichiro itojun Hagino, Research Lab, IIJ

There were complaints about no checking of source and destination addresses in host implementations when doing automatic conversion of embedded IPv4 addresses and 6 to 4 packets 2002::xx . Referred to rfc 2267 for protection: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.
    Transition Mechanisms for IPv6 Hosts and Routers

<draft-ietf-ngtrans-mech-04.txt >

When doing Neighbour Discovery over Tunnels not LLA options should be sent and those that are received should be silently ignored.

After the decapsulation of an IPv6, in IPv4, the node should silently discard a packet with an invalid IPv6 source address, including:

• IPv6 Multicast loopback
• IPv4 Multicast, broadcast, all-zero
• Should apply rules for filters (rfc1812 "Requirements for IP Version 4 Routers" and RFC 2267 "Network Ingress Filtering:..")

1. Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels

<draft-ietf-ngtrans-6to4-04.txt
Brian Carpenter

A question was raised as to whether there should be a link local addr on 6to4 interface. Concluded that since it wasn't really used it was not needed.

Question as to how to do Multicast - Use PIM-SM. However any form of flooding cannot be used, as this would require all existing 6to4 routers to consider themselves as neighbours simultaneously i.e. it is like an NBMA network.

Host only 6to4 will be a separate draft.

2. Dual Stack Transition Mechanism (DSTM)

<draft-ietf-ngtrans-dstm-01.txt

It is now in BSD stack from INRIA:

• Dynamic Tunnelling Interface (DTI) works on same link.
• Tunnel End Point (TEP) works with Dynamic tunnelling

DHCPv6 is being worked on concurrently.

1. A SOCKS-based IPv6/IPv4 Gateway Mechanism

<draft-ietf-ngtrans-socks-gateway-04.txt
H. Kitamura, NEC Corporation

This is available from http://www.socks.nec.com, which has apparently had 5000 downloads.  

2. Overview of Transition Techniques for IPv6-only to Talk to IPv4-only Communication

<draft-ietf-ngtrans-translator-03.txt

Three translation mechanisms are described. From the address mapping point of view, the translators are categorised into four types and the feasibility of each is considered.

Out of scope: SOCKS, Stateless IP/ICMP Translation Algorithm (SIIT), BIS. 

3. An IPv6-to-IPv4 transport relay translator

<draft-ietf-ngtrans-tcpudp-relay-00.txt

The draft describes an IPv6-to-IPv4 transport relay translator.  It
enables an IPv6-only node to exchange TCP or UDP traffic with IPv4-only
nodes.  A transport relay translator box, which sits in the middle, will
take care of the protocol translation. It uses a 'dummy prefix' in a modified DNS, which hosts use when attempting to talk to an IPv4 host.

This has been implemented in KAME.

4. Tunnel endpoint discovery

Granularity of tunnel end point discovery mechanism:

• Auto tunnels: 1 host  is /128 address
• 6over4: 1 host  is /128 address

Tunnel broker:

• 6to4: 1 site is /48 address

DNS is the natural distribution model but DNS shouldn't be overloaded. However it was suggested that with the creation of a tunnel6.int top-level domain it could be used for lookups.

<draft-ietf-ngtrans-broker-02.txt
Alain Durand

Suggests a new 'Tunnel Broker' to automatically manage tunnel requests coming from the users.

1. IPNG

Going to last call:

• Router renumbering for IPv6 (draft-ietf-ipngwg-router-renum-10.txt)
• DNS support for IPv6 (draft-ietf-ipngwg-dns-lookups-07.txt)

Going to last call informational:

• Initial IPv6 Sub-TLA ID Assignments (draft-ietf-ipngwg-iana-tla-03.txt)
• Method for flexible IPv6 address assignment
• IAB: The case for IPv6 - waiting on S. Deering

Ready for last call:

• IPv6 over Ether, FDDI, Token Ring, ARCNET, PPP
• ICMP name lookup (experimental)

1. Default Address Selection for IPv6

<draft-ietf-ipngwg-default-addr-select-00.txt
R. Draves, Microsoft Research

This uses a default policy table. For multihomed hosts choosing their source address, there are two models; these were discussed as outgoing, but each has a version for incoming too:

• Strong: the source address MUST belong to the originating interface

• Redirect ND
• Mcast routing - RPF checking vital for some protocols e.g. PIM

• Weak: the source address MAY belong to any interface of the originating host

• application/upper layer override

Not clear which approach to take. MUST or SHOULD (probably).
Privacy and source address selection - when to use public versus anon address options:

• Depreciate all pub address
• Use universal EUI-64 bit
• Remember address genesis.
• Add a role preferring anon address

Integration with IPv4

• Assign scopes to IPv4
• combine IPv6 and IPv4 address selection
• add to default policy table

13. IPv6 hooks for AAA registration and "host routing"

<draft-nordmark-ipv6-aaa-hooks-00.txt

ISP might want one or more A's from AAA. Registration request sent to AAAL address
 

14. AAA for IPv6 Network Access

<draft-perkins-aaav6-00.txt
Authenticated net access for ipv6. Where to: address of AAA from routers
This document proposes a way for IPv6 nodes (clients) to offer credentials to a local AAA in order to be granted access to the local network.  Whereas for IPv4 it is not clear that routers and DHCP will be equipped to handle such functions, we believe that it is more efficient and thus reasonable to expect such access controls to be exerted by IPv6 routers, possibly as part of performing their role as DHCPv6 relays.  DHCPv6 servers and routers are expected to work in conjunction with AAA servers to determine whether or not the client's credentials are valid.

So AAAF(foreign) talks to AAAH(home), sending solicitation with credentials & MN-NAI Router returns Router Advertisement.

Issues:

• Generated key extensions 'a la' MIER
• Advertisements need for AAA
• relationship with AAA hooks
• relationship with DHCPv4 + AAA

6. Multicast

<draft-aboba-dnsext-mdns-00.txt
Bernard Aboba, Dave Thaler, Microsoft

Multicast DNS (mDNS) is an extension to the DNS protocol, which consists of a single change to the method of use, and no change to the format of DNS packets. Basically hosts send and respond to queries on port 53. DHCP precludes mDNS.

• This proposal is not supposed to supplant Dynamic DNS, which is better suited to moderate to large networks.
• mDNS is only valid out to local scope for IPv4 and IPv6.

This draft does not prescribe a means of securing the multicast DNS mechanism.

2. Inter-Domain Multicast Routing WG (idmr)

1. Mtrace

<draft-ietf-idmr-traceroute-ipm-06.txt Bill Fenner mtrace goes to last call.(bogons documented)  

2. IGMPv3

<draft-ietf-idmr-igmp-v3-02.txt
Isidor Kouvelas, Cisco

An updated spec missed the I-D deadline. A new version should be ready for last call.
Updates:

Query packet format, new fields for:

• Suppress router-side processing flag
• Queries robustness variable
• Queries query interval

Host side changes

• Explicit host membership tracking removed.
• EXCLUDE mode reports truncated to packet size
• Actions on change of interface state
• Actions on reception of a query
• point to API spec draft (idmr-msf-api-00.txt)

Router side changes

• Group timer maintained only in exclude mode
• Actions on reception of reports

• table entries corrected
• Timers no longer lowered on reception of report

• Timer updated on reception of Queries

• controlled by SRSP flag
• Group specific query

1. Socket Interface Extensions for Multicast Source Filters

<draft-ietf-idmr-msf-api-00.txt
Dave Thaler, Microsoft

Goals - to present a version independent API not present in 2553.

The basic API uses delta operations {ADD, DROP}_MEMBERSHIP, ALLOW

The Advanced API allows multiple source in an atomic operation.

There was a question over whether to use setsocketopt() or ioctl() for
SIO_GET_MULTICAST_FILTER: to retrieve the list of source addresses that comprise the source filter along with the current filter mode.

(Can not use setsocketopt() as it doesn't provide a method to return information in the call so ioctl has to be used although its not quite 'correct').

For proto-independent API, one should use Interface index - this will be present in IPv4 as well as IPv6.    

6. E-Business

1. E-Business BOF

There was a BOF on e-business, but this is not really a function of the IETF, and was not very good. The main subject was the interest in XML – and how it could be used in general. There was much made of the fact that XML was extensible, internationalised, and verifiable. It was industry supported, had transformation rules (XSL), and included application-level topology, security, net transport and QoS. It was very important that it included the ability to add application-specific messages to a general framework. For integrating in major applications, it was important that there was the possibility of loose coupling. While some businesses would use on-line synchronous responses, some could use only e-mail responses.

2. Internet Open Trading Protocol (iotp)

• Draft status:

• IOTP 1.0 drafts in RFC editor queue since November -- nearly ready to be issued as RFCs
• HTTP and detector drafts almost at WG last call
• SET and architecture drafts just released

• Current implementers: Hitachi (with some funding from Japanese government), Royal Bank of Canada (using for ATM network) SIZ (German Savings Banks), Cybersource, Brokat...
• Requirements for Digital Rights Trading draft discussion:

• Provides a unified system for issuing and redeeming gift certificates, coupons, loyalty points, etc.
• Better name is needed to avoid confusion with copyright rights management
• Could these issues be resolved by a more general concept of 'cash' in the main IOTP drafts? Difficult but not impossible for options like a '50% off' voucher, would simplify protocol suite.
• Should this draft be specific to loyalty schemes or generalise to other bearer instruments like derivatives, bonds etc.? No consensus.

• Group charter has been updated:

• XML messaging split off into separate WG -- may be taken on by EDIINT WG
• Electronic Commerce Mark-up Language 2 has been added as a work item. It is also being considered under P3P by W3C
• Server-to-server issues will now be considered

7. IRTF

The routing research group will start again. Services management, reliable multicast, network management, end-end, interplanetary, AAA, building DIFFSERV. Now working on NASREQ and Mobile-IP.

8. IP Storage BOF

• Goal of WG would be to remove the need for hosts to access and manage network storage.
• Three current examples were described:

• ISI Netstation found only a 25% penalty in accessing a SCSI decide using TCP/IP rather than a native interface.
• IBM iSCSI and Seagate's SCSI Encapsulation Protocol found similar results.

• Charter would require a simple, layered solution that leveraged SCSI, TCP and other bodies' efforts.

• Meeting felt a tightly drawn applicability statement was required discussing LAN versus WAN and block versus file issues. Security is obviously of paramount importance.
• Most meeting attendees felt a working group should be chartered, none were against. Further discussion will take place on mailing list.

10. Sessions

There was a discussion on the utility of SLP (Service Location Protocol) in zeroconf environments.

• Useful  for policy based use
• Decided to investigate its impact on zeroconf

2. Dynamic Configuration of IPv4 link-local addresses

<draft-cheshire-ipv4-linklocal-00.txt
Stuart Cheshire, Apple Computer

When a host wishes to configure a link-local address, it selects an address at random from 169.254/16 (IANA allocated). It uses ARP to resolve conflicts to find or reallocate new address. Win98 and MacOS 8.5 (and later) use a scheme similar to this draft (see also rfc2563.txt and draft-ietf-dhc-ipv4-autoconfig-05.txt). It is less well defined for with machines that have multiple interfaces and/or multiple addresses per interface. Steve Deering raised the point about source address selection when more than once address was assigned to an interface or machine and suggested they look over the work in IPNG.
 

3. Application Protocol BOF

On the Design of Application Protocols

<draft-mrose-blocks-appldesign-01.txt
M.T. Rose

Introduced the topic by trying to categorise protocols into different groups based on their behaviour as regards: framing, encoding, Error reporting, multiplexing, user Authentication, and Transport Security. Three examples were brought out: SMTP, FTP, HTTP and broken down according to how they faired in each category.

Based on this a generic application protocol BXXP that exhibit certain features:

• they are connection-oriented;
• they use requests and responses to exchange messages; and,
• they allow for asynchronous message exchange.

4. Performance Implications of Link Characteristics (pilc)

• SLOW, ERROR drafts are in working group last call until April 7 – any last comments were solicited for mailing list. WG felt text that explanatory text that had been pasted into SLOW from the LINK draft should be removed for document length and intended audience reasons. The appendices should not have Best Current Practice status.
• RFC 2757 was published January 2000
• Performance Enhancing Proxies draft was discussed. Any further types and environments should be mailed to the authors for inclusion. Implications of running proxies at network borders needs fleshing out.

Advice for Internet Subnetwork Designers draft updates was described. Sections on Quality of Service, compression, mobility, multicast, link asymmetry and framing have been refined. End-to-end philosophy and fundamental link design are done. More work is needed on QoS, congestion control, delay and variance characteristics, routing and mobility and multicast.

4. Uni-Directional Link Routing (udlr)

As regards security, it was pointed out that effective ingress filtering could not be done as traffic may be legally sourced from anywhere.

Various implementations were mentioned from: Alcatel, Sony, and Hitachi

The working group will be 'put to sleep' whilst draft is finished and other items are tidied up.