Update on Mobility Services Framework Design Document

1
Update on Mobility Services Framework Design
Document

• Gabor Bajko, Subir Das, Nada Golmie, Telemaco
  Melia, JC Zuniga

IETF-72, Dublin, Ireland
2
Outline

• Update on draft-ietf-mipshop-mstp-solution-05
• Update of draft-ietf-mipshop-mos-dhcp-options-04
• Update of draft-ietf-mipshop-mos-dns-discovery-01
• Few words about draft-stupar-dime-mos-options-00

3
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

4
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
• Gorrys comment on backoff mechanism was already
  included in version 05 (Ref Gorrys email from
  8/6/2008)
• DHCP Authentication
• Link layer security clarification
• Integrated scenario support (NAS/DHCP)
• 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

5
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 to be associated with a visited
  network than home?
• Modified Text (Section 3.3)
• 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.

6
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

7
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.

8
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

9
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

10
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.

11
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.

12
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

13
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.

14
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.

15
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/h
  tml/draft-ietf-tsvwg-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.

16
draft-ietf-mipshop-mstp-solution (cnted)

• 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.

17
draft-ietf-mipshop-mstp-solution (cnted)

• 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

18
draft-ietf-mipshop-mstp-solution (cnted)

• Issue 14 Security recommendation on TLS/DTLS
• Comment The explanation on how to use TLS 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?
• Remedy
• Text reworked and modified in Section 8

19
Draft-ietf-mipshop-mstp-solution Remaining
Issues from AD review

• Issue 1 Back-off retransmissions
• Comment 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.
• Suggested Remedy
• Already addressed (Issue 11)
• Gorrys comment Sounds fine (10 seconds seems
  large enough to me). I suggest you add your text.

20
Draft-ietf-mipshop-mstp-solution Remaining
Issues Contd..

• Issue 2 DHCP authentication
• Comment I think the overall recommendation is
  good, but practically no 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.
• Suggested text (colored)
• 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.

21
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 lets discuss

22
Integrated Scenario Current State
Visited Home


-------
-------

AAAV -------------------AAAH



------- -------





--------

MoSh
----- ------
-------- ----
DHCP MN ------
NAS/----Server ----
DHCP
Relay
----- ------
AAAv -- Visited
AAA AAAH -- Home AAA NAS --
Network Access Server
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?
23
Integrated Scenario Approach I
Visited Home


-------
-------

AAAV -------------------AAAH



------- -------





--------

MoSh
-----
-------- ----
MN ------ NAS
----
-----

AAAv -- Visited AAA
AAAH -- Home AAA NAS --
Network Access Server
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
24
Integrated Scenario Approach II
Visited Home


-------
-------

AAAV -------------------AAAH



------- -------





--------

MoSh
----- ------
-------- ----
DHCP MN ------
NAS/----Server ----
DHCP
Relay
----- ------
AAAv --
Visited AAA AAAH -- Home AAA
NAS -- Network Access Server

• - 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

25
Draft-ietf-mipshop-mstp-solutionRemaining
Issues Contd..

• Additional Issue Number of Ports
• Problem 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.
• Suggested Remedy
• Update the ID and register one default port
  number with IANA for all services

26
Update of draft-ietf-mipshop-mos-dhcp-options-04

• Version -04 is available at http//tools.ietf.org/
  html/draft-ietf-mipshop-mos-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

27
Update of draft-ietf-mipshop-mos-dhcp-options-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

28
Update of draft-ietf-mipshop-mos-dns-discovery-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

29
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

30
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

31
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