Transcript Update on Mobility Services Framework Design

Update on Mobility Services
Framework Design Document
Gabor Bajko, Subir Das, Nada
Golmie, Telemaco Melia, JC
Zuniga
IETF-72, Dublin, Ireland
Outline




Update on draft-ietf-mipshop-mstpsolution-05
Update of draft-ietf-mipshop-mos-dhcpoptions-04
Update of draft-ietf-mipshop-mos-dnsdiscovery-01
Few words about draft-stupar-dimemos-options-00
2
Terminology







MoS – Mobility Services
MIH – Media Independent Handover
MIHF – Media Independent Handover
Function
MSTP – Mobility Services Transport Protocol
MSFD – Mobility Services Framework Design
MoSh – Mobility Services at Home network
MoSv – Mobility Services at visited network
3
Draft-ietf-mipshop-mstp-solution:
Summary

ID status
 Most of the AD review addressed



Next few slides
Draft v05 already reflects these changes
Few remaining issues from AD review

Back-off retransmission


DHCP Authentication


Link layer security clarification
Integrated scenario support (NAS/DHCP)


Gorry’s comment on backoff mechanism was already included in version
05 (Ref: Gorry’s email from 8/6/2008)
Need to gather WG consensus to finalize the document
Additional issue

Number of Ports for MIH Services

Driven by implementation experience in Rogers, Vodafone networks
4
Draft-ietf-mipshop-mstp-solution
(contd..)
Issue# 1: The assumption about MoS location

Comment: Is there a need to state that ES/CS is more likely

Modified Text: (Section 3.3)
to be associated with a visited network than home?

This document does not make any assumption on the
location of the MoS (although there might be some
preferred configurations), and aims at flexible MSFD to
discover different services in different locations to
optimize handover performance. MoS discovery is
discussed in more detail in Section 5.
5
draft-ietf-mipshop-mstp-solution
(contd..)
# Issue 2: MoS configuration
 Comment: Text needs to be written in a much more
detailed and specification-like manner

Remedy:

Text reworked and modified in Section 4
6
draft-ietf-mipshop-mstp-solution
(contd..)
Issue #3: MoS authorization
 Comment: Can we end up in a situation where DHCP
discovery delivers a server address which refuses to talk to
us, for instance?

Modified text: (Section 5)

In case future deployments will implement authorization
policies the mobile node should fall back to other learned
MoS if authorization is denied.
7
draft-ietf-mipshop-mstp-solution
(contd..)
Issue #4: Scenario 2 (DHCP + DNS)

Comment: A lot of complexity

Modified text: (Section 5.2)

Text reworked and modified in Section 5.2
8
draft-ietf-mipshop-mstp-solution
(contd..)
Issue #5: MoS in 3rd party networks
 Comment: Can this document point to specific attributes
defined in IEEE that would carry such information?

Modified text: (Section 5.3)

IEEE 802.21 defines information elements such as
OPERATOR ID and SERVICE PROVIDER ID which can be a
domain name. Text reworked and modified accordingly in
Section 5.3
9
draft-ietf-mipshop-mstp-solution
(contd..)
Issue #6: MIH MoS capabilities
 Comment: The document does not talk about how
servers know the capabilities of clients that send
event/command services to. Is this a part of the IEEE
definitions, and you subscribe to a particular event stream? In
any case, the document should talk about this and point to
the relevant other specifications where needed.

Added text: (Section 6)

Once the Mobility Services have been discovered, MIH
peers may run a capability discovery and subscription
procedures as specified in IEEE 802.21 if not discovered
via either DNS or DHCP.
10
draft-ietf-mipshop-mstp-solution
(contd..)
Issue #7: MoS message framing
 Comment: The document is very silent on how MIH
messages are carried on a given transport protocol. At the
very least the draft should indicate that no extra framing is
needed because IEEE specs already contain a length field.

Modified text: (Section 4)

The usage of transport protocols is described in Section 6 and
packing of the MIH messages does not require extra framing
since the MIH protocol defined in IEEE 802.21 already contains a
length field.
11
draft-ietf-mipshop-mstp-solution
(contd..)
Issue #8: MIH message size/fragmentation
 Comment: be more specific about MIH message
size/fragmentation

Remedy:

Text reworked and modified in Section 6.1
12
draft-ietf-mipshop-mstp-solution
(contd..)
Issue #9: TCP and fragmentation of MIH
messages

Comment: True, TCP can split the message, but is this
really the cause of delay. If one uses the PUSH bit, then the
records should be sent, even when no more data follows?

Added text: (Section 6.1)

The use of the PUSH bit can alleviate this problem by
triggering transmission of a segment less than the SMSS.
13
draft-ietf-mipshop-mstp-solution
(contd..)
Issue #10: Token bucket parameters


Comment: I think this commentary effectively says very little,
and so leaves it for operators to choose to do what they like.
I'd suggest this is not good practice. It seems to recognize a
problem, but be unwilling to address it.
Modified text: (Section 6.2)
 Recommendations for token bucket parameter settings
are as follow:


If MIHF knows the RTT, the rate can be based upon this
If not, then on average it SHOULD NOT send more than one
UDP message every 3 seconds.
14
draft-ietf-mipshop-mstp-solution
(contd..)
Issue #11: Back-off retransmissions


Comment: So, is the UDP retransmission backed-off at all,
as recommended in: http://tools.ietf.org/html/draft-ietftsvwg-udp-guidelines-07 - If the number of retransmissions is
limited, what specifies this limit?
Modified text: (Section 6.3)
 The default number of retransmissions is set to
2 and retransmissions are controlled by a timer
with a default value of 10s. No backoff
mechanism is specified.
15
draft-ietf-mipshop-mstp-solution
(cnt’ed)
Issue #12: Keep alive messages

Comment: This is too vague.

Added text: (Section 6.4)

Re-registration or Event indication messages as
defined in IEEE802.21 MAY be used for this purpose.
16
draft-ietf-mipshop-mstp-solution
(cnt’ed)
Issue #13: Security recommendation on
IPsec
 Comment: I do not see a particular requirement for IPsec
here, why do we need to include it?

Suggested Remedy:

Removed recommendation for IPsec from the
document
17
draft-ietf-mipshop-mstp-solution
(cnt’ed)
Issue #14: Security recommendation on
TLS/DTLS

Comment: The explanation on how to use TLS

Remedy:
and DTLS seems thin. Is there something to be
said about what type of certificates or
infrastructure is needed, what modes of operation
are allowed, etc?

Text reworked and modified in Section 8
18
Draft-ietf-mipshop-mstp-solution:
Remaining Issues from AD review
Issue #1: Back-off retransmissions

Comment:

Suggested Remedy:
In Gorry's review he pointed out that the UDP usage guidelines
document recommends an exponential back-off mechanism. The mstp draft
deviates from this, and I'm not sure its appropriate to do so. Note that the
guidelines had only a recommendation, not a requirement. But its not clear
that you actually want to avoid an exponential back-off. Its easy to think of
situations (such as the base station going down) where there would be a
significant amount of retransmission traffic from a large number of hosts.

Already addressed (Issue #: 11)

Gorry’s comment: “Sounds fine (10 seconds seems large enough to me). I
suggest you add your text.”
19
Draft-ietf-mipshop-mstp-solution:
Remaining Issues Contd..
Issue #2: DHCP authentication

Comment: I think the overall recommendation is good, but practically no

Suggested text (colored):
one is going to deploy RFC 3118. With this in mind, I would like to see the
above paragraph explain in more detail the security implications of relying on
link layer security.

In the case where DHCP is used for node discovery and authentication of the
source and content of DHCP messages is required, network administrators SHOULD
use DHCP authentication option described in [RFC3118], where available or rely
upon link layer security. This will also protect the DHCP server against denial of
service attacks since [RFC3118] provides mechanisms for both entity authentication
and message authentication. In case where DHCP authentication mechanism is not
available administrators may need to rely upon underlying link layer security. In
such cases the link between DHCP client and server may be protected but the
source and DHCP messages can not be authenticated unless there exits a security
binding between link layer and DHCP layer.
20
Draft-ietf-mipshop-mstp-solution:
Remaining Issues Contd..
Issue #3: Roaming MoS scenario
 Comment: But the big question for me was whether it is
appropriate to employ DHCP-AAA binding so that per-MN information
can be provided. I realize that we have done it once in the context
of the Mobile IP bootstrapping work. But frankly, that sets a very
high bar for deployment in a given access network and introduces
dependencies and complexity that is undesirable. In general, if every
application that wants to avoid configuration needs to have special
support in DHCP relays, it becomes very hard to deploy anything
new.

Suggested Remedy:

See next few slides and let’s discuss
21
Integrated Scenario: Current State
Visited
Very similar to the MIP6 integrated scenario
Convey MoS information to the
NAS during network authentication
Store the information into the DHCP relay
Provide the MN with the assigned MoS
(network based) during IP address
Configuration
Do we want a method to configure MNs
in visited networks with (MoS) services
provided in the home network?
|
Home
|
|
+-------+
|
+-------+
|
|
|
|
|
|AAAV
|-----------|--------|AAAH
|
|
|
|
|
|
|
|
|
|
|
+-------+
|
+-------+
|
|
|
|
|
|
|
|
|
|
+--------+
|
|
|
|
|
|
| MoSh |
+-----+
+------+ |
+--------+
+----+
|
|
|DHCP | |
| MN |------| NAS/|----|Server| |
+----+
| DHCP|
|
| |
|Relay|
|
| |
+-----+
+------+ |
|
AAAv -- Visited AAA
AAAH -- Home AAA
NAS -- Network Access Server
22
Integrated Scenario: Approach I
Visited
Convey MoS information to the
NAS during network authentication
NAS delivers the MoS information via link
layer or other mechanisms that are out of
scope of this document
Note: It does not provide a complete solution
since there will be no IETF specific solution
to deliver the MoS information from the NAS
to the MN
|
Home
|
|
+-------+
|
+-------+
|
|
|
|
|
|AAAV
|-----------|--------|AAAH
|
|
|
|
|
|
|
|
|
|
|
+-------+
|
+-------+
|
|
|
|
|
|
|
|
|
|
+--------+
|
|
|
|
|
|
| MoSh |
+-----+
|
+--------+
+----+
|
|
| MN |------| NAS |
|
+----+
|
|
|
+-----+
|
AAAv -- Visited AAA
AAAH -- Home AAA
NAS -- Network Access Server
23
Integrated Scenario: Approach II
|
Home
|
|
+-------+
|
+-------+
|
|
|
|
|
|AAAV
|-----------|--------|AAAH
|
|
|
|
|
|
|
|
|
|
|
+-------+
|
+-------+
|
|
|
|
|
|
|
|
|
|
+--------+
|
|
|
|
|
|
| MoSh |
+-----+
+------+ |
+--------+
+----+
|
|
|DHCP | |
| MN |------| NAS/|----|Server| |
+----+
| DHCP|
|
| |
|Relay|
|
| |
+-----+
+------+ |
|
- This option is currently in the Annex of v05 and
can co-exist as an option in addition to solution I
- Conveys MoS information to the
NAS during network authentication
- Store the information into the DHCP relay
- Provide the MN with the assigned MoS
(network based) during IP address
Configuration
Note: This is not specific to MSTP and MoS
discovery, seems to be a general issue
within IETF
Visited
AAAv -- Visited AAA
AAAH -- Home AAA
NAS -- Network Access Server
24
Draft-ietf-mipshop-mstp-solution:
Remaining Issues Contd..
Additional Issue: Number of Ports

Problem:

Suggested Remedy:
Current specification mandates the
use of three different ports, keep-alive messages
for NAT traversal on three different ports are an
issue. Too many messages to send.

Update the ID and register one default port
number with IANA for all services
25
Update of draft-ietf-mipshop-mos-dhcpoptions-04



Version -04 is available at
http://tools.ietf.org/html/draft-ietf-mipshopmos-dhcp-options-04
Changed from multiple DHCPv4 options to one
DHCPv4 option and added several sub-options
Encoding types are kept unchanged

‘enc’ byte ‘0’  Domain name list

‘enc’ byte ‘1’  IPv4 address list
26
Update of draft-ietf-mipshop-mos-dhcpoptions-04

DHCPv6 has two Options

IPv6 MoS Identifier Option

IPv6 MoS information Option

MoS Information Option has several sub-options

Moved all Relay Agent options to Appendix

May be removed depending upon the outcome of the
discussion of Integrated scenario
27
Update of draft-ietf-mipshop-mos-dnsdiscovery-01


Defines new application tags to discover
MIH services (IS, CS, ES) accessible using
certain transport protocols (e.g., UDP, TCP,
SCTP)
Currently the draft says that new services
and new transports may be registered with
IANA on an FCFS basis
28
Comment # 1

Yoshihiro Ohba:



New transports may be registered on an FCFS basis, but
new services should be defined by standards track RFCs
Clarify that messages belonging to ‘Service Management’
type are considered ES or CS types when L3 transport is
used
The new version will incorporate the
proposed changes
29
Comment # 2




Review received from Thomas Narten on 7/24
Comments mainly on the exceptions to the rule
defined in the doc, some of them being added as a
result of previous comments
The comments are going to be discussed on the
mailing list and the draft will be updated accordingly
No additional comments were received
30
Draft-stupar-dime-mos-options



Addresses AAA extensions required for Integrated
Scenario defined in the solution draft
Defines AVP extensions to convey Mobility Services
information and its capability
ID presented in DIME, to be considered for DIME
charter, if required by MIPSHOP
31