Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User"

["Templin, Fred L" <[e-mail]>]

Hi Alex and Alper,

> -----Original Message-----
> From: dmm [mailto:[e-mail]] On Behalf Of Alexandru Petrescu
> Sent: Thursday, September 04, 2014 2:50 AM
> To: [e-mail]
> Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User"
> 
> Le 04/09/2014 08:47, Alper Yegin a écrit :
> > Hi Fred,
> >
> > Can this scenario not be realized by simply placing an HA in the
> > enterprise network and using Mobile IP?
> 
> I guess yes and no.
> 
> YEs, in that it is a typical Mobile IP scenario with handovers
> WiFi/4G/Ethernet.

Handovers between diverse access technologies is one aspect of the
proposal, yes. The ability to coordinate multiple access technologies
simultaneously is also included as part of the architecture, but some
future work needs to be done to put that into practice.
 
> No, in that "VPN" is cited in the scenario and VPN+Mobile IP are not
> working well together.

Right - switching between VPN and non-VPN will be important for
enterprise network mobile device users.

> No, in that TIP (DHCPv6 Prefix Delegation?) is not clear how to work
> with a EUD device ID?  Is it Ethernet's, WiFi's or 4G's interface MAC
> address?

The mobile device applies the TIP to its downstream-attached
interfaces and not to the access technology interfaces over
which the prefix delegation was received. So the mobile device
is really a mobile router.

But, maybe you are asking where does the mobile device get its
Device-Unique Identifier (DUID) so it can talk to the DHCPv6
server? The DUID need not be based on a MAC address, but could
be some other unique ID assigned to the mobile. So, there is
no confusion about which MAC address to choose.
 
> No, in that Mobile IP and prefixes are not known to lead to optimal
> routes, whereas the scenario says "optimal routes".

Route optimization is indeed a key aspect of the proposal, and
in fact hard-coded into the name "AERO". Another key aspect is
the in-built distributed mobility management (dmm) architecture.
The enterprise can from day one deploy hundreds or even
thousands of AERO servers, and the mobile devices simply
associate with one or more that are close by. Beyond that, it
doesn't matter which server the mobile associates with - it
will get the same service as from any other server.
 
> No - but this is a stretch - the scenario does not mention the
> neceessity of user typing secure  information on a screen (authenticate
> to web page on a public hotspot prior to ability to Mobile IP, or use
> One-Time Password tokens for VPN connections); any "seamless" mobility
> mechanism will need to automate this step; this is even more needed when
> considering devices without user interfaces, such as Mobile Routers
> using Mobile IP for a vehicle.

Aspects of how the VPN link is established (enter password,
insert active badge, etc.) are not discussed, but not really
relevant to the way in which AERO can provide the mobile with
a stable TIP that never changes. Just that the faster the VPN
link can be established, the faster the mobile device can resume
service as if it were still coming in through an on-campus
enterprise network access link.

There is still more to this, such as how AERO can provide an
assured path MTU over the tunnel, etc. There should also be
an expanded use case analysis. I have been coming at this from
an enterprise network viewpoint, but as far as I know AERO
could also be applied in the traditional use cases envisioned
for MIPv6 and its derivatives. So, it would be good to have
some of the experts from this community examine the proposal
and provide a comparative analysis. 

Thanks - Fred
[e-mail]

> Alex
> 
> >
> > Alper
> >
> >
> > On Sep 3, 2014, at 7:37 PM, Templin, Fred L wrote:
> >
> >> Hi,
> >>
> >> The specific passage from the new draft that I wanted the wg to
> >> see is the following (with references to AERO removed). Please
> >> review and send questions or comments.
> >>
> >> Thanks - Fred [e-mail]
> >>
> >> ---
> >>
> >> 3.  A Day in the Life of an Enterprise Mobile Device User
> >>
> >> An enterprise network mobile device user ("Bill") begins his
> >> workday by seating his primary end user device (EUD) (e.g., a
> >> laptop computer, a tablet, a smart phone, etc.) in a docking
> >> station at his office desk and turning the device on.  The docking
> >> station connects Bill's EUD to the enterprise wired LAN, and the
> >> EUD receives a Topologically-Fixed Address (TFA) from the
> >> infrastructure.  Bill's EUD further discovers the DMM service
> >> within the enterprise network and requests a Topology Independent
> >> Prefix (TIP)delegation.  Bill's EUD receives the same TIP
> >> delegation it gets every time it connects to the enterprise
> >> network, because the DMM service has an administratively set
> >> mapping between the TIP and Bill's EUD device ID.
> >>
> >> Bill's EUD can then access topologically-fixed enterprise services
> >>  using its TFA directly, and can access DMM services by using an
> >> address from its TIP as the source address for tunneling over the
> >> enterprise network.  As Bill's workday unfolds, his EUD uses the
> >> DMM service to correspond with other EUDs in peer-to-peer
> >> sessions, join lengthy virtual conferencing sessions, access
> >> enterprise fileshares, etc.  The DMM service ensures that optimal
> >> routes are maintained so that tunneled communications flow over
> >> direct paths and network infrastructure elements are not
> >> unnecessarily over-burdened.
> >>
> >> While communications sessions such as the video conference are
> >> still in progress, Bill leaves the office to attend a meeting in a
> >> nearby conference room.  He disconnects his EUD from the docking
> >> station and in the process drops his connection to the wired LAN.
> >> The EUD quickly enables a WiFi interface that searches for a
> >> Service Set Identifier (SSID) that can provide wireless access
> >> within the enterprise network.  The EUD authenticates itself to
> >> the network via the SSID using its pre-loaded certificates, and
> >> uses a securing mechanism such as IEEE 802.1x to assure
> >> Confidentiality, Integrity and Availability (CIA).  The EUD
> >> receives a new TFA from the network, then communicates its new
> >> TIP-to-TFA association to the DMM service and any active peer
> >> correspondents.  Any ongoing communications sessions will continue
> >> to see the same (stable) TIP.
> >>
> >> Bill then leaves the enterprise campus to attend an off-site
> >> customer meeting with his EUD still powered on and actively
> >> seeking to maintain network connectivity.  As Bill departs from
> >> the building, the WiFi signal fades until it can no longer support
> >> communications, and the EUD quickly enables a 4G cellular wireless
> >> interface that connects Bill's EUD to a cellular service provider.
> >> The EUD then locates the Internet address of an enterprise network
> >> security gateway and initiates a VPN session with the gateway
> >> (which also acts participates in the DMM service).  The DMM
> >> service updates the routing system, and Bill can continue to use
> >> the same TIP that was assigned to his EUD when he started his
> >> workday even though the EUD is now communicating over a VPN
> >> configured over the public Internet instead of over the secured
> >> campus LAN.
> >>
> >> Bill subsequently arrives at the customer meeting at a public
> >> restaurant with a WiFi hotspot.  His EUD quickly powers up its WiFi
> >> interface and powers down the 4G interface.  The EUD uses DMM
> >> signaling to communicate the new TFA to the security gateway and
> >> the VPN survives the mobility event.  Moreover, the EUD can
> >> continue to use the same TIP it received at the beginning of the
> >> workday, and ongoing communication sessions can continue until
> >> Bill explicitly discontinues them.
> >>
> >> After the customer meeting, Bill leaves the restaurant and
> >> subsequently passes through several additional transitions from
> >> WiFi hotspots to 4G wireless.  Again, the DMM service keeps the VPN
> >> session alive, and the TIP assigned to the EUD remains in
> >> continuous use in active communication sessions as well as to
> >> allow Bill to receive notifications and process urgent requests.
> >> When Bill returns to his office, the EUD discontinues use of the
> >> VPN while keeping its TIP active after re-attaching to the campus
> >> LAN.
> >>
> >> Bill ends his workday, powers down his EUD and returns home.  Bill
> >>  powers on his EUD to check e-mails, and connects to the enterprise
> >>  network via a VPN configured over his home ISP service.  The EUD
> >> again receives the same TIP that it used within the enterprise
> >> network domain, and Bill can access DMM services the same as if he
> >>  was in the office.  Bill finally shuts down for the evening, and
> >> begins his next workday in the same fashion.  Again, the EUD
> >> receives the same TIP as always regardless of the access network
> >> point of connection over which the EUD enters the enterprise.
> >>
> >>> -----Original Message----- From: dmm
> >>> [mailto:[e-mail]] On Behalf Of Templin, Fred L Sent:
> >>> Tuesday, September 02, 2014 11:05 AM To: [e-mail] Subject:
> >>> [DMM] FW: I-D Action: draft-templin-aeroent-00.txt
> >>>
> >>> Hello,
> >>>
> >>> During the call today, there was some interest expressed in
> >>> learning more about the enterprise network mobility use case. I
> >>> have submitted a new brief document called "AERO Enterprise
> >>> Network Profile" (below) that provides a discussion of
> >>> distributed mobility management needs for enterprise networks.
> >>> Although the document specifically cites AERO, the use case
> >>> applies to any solution alternative that could meet the
> >>> requirements. Also, I am not asking this document be considered
> >>> as a dmm wg item at this time, but rather offering it for
> >>> informational purposes. Please let me know if there are any
> >>> questions or comments.
> >>>
> >>> Thanks - Fred [e-mail]
> >>>
> >>> -----Original Message----- From: I-D-Announce
> >>> [mailto:[e-mail]] On Behalf Of
> >>> [e-mail] Sent: Tuesday, September 02, 2014 10:51
> >>> AM To: [e-mail] Subject: I-D Action:
> >>> draft-templin-aeroent-00.txt
> >>>
> >>>
> >>> A New Internet-Draft is available from the on-line
> >>> Internet-Drafts directories.
> >>>
> >>>
> >>> Title           : AERO Enterprise Network Profile Author : Fred
> >>> L. Templin Filename        : draft-templin-aeroent-00.txt Pages
> >>> : 12 Date            : 2014-09-02
> >>>
> >>> Abstract: Enterprise networks provide a secured data
> >>> communications infrastructure built for the purpose of
> >>> information sharing and increased productivity for end users
> >>> within the organization. Enterprise networks are often organized
> >>> as private Internets unto themselves that connect to the global
> >>> Internet either not at all or via firewalls, proxies, and/or
> >>> other network securing devices.  This document discusses an AERO
> >>> enterprise network profile that outlines new and more flexible
> >>> methods for connecting, tracking and managing mobile
> >>> organizational assets.
> >>>
> >>>
> >>> The IETF datatracker status page for this draft is:
> >>> https://datatracker.ietf.org/doc/draft-templin-aeroent/
> >>>
> >>> There's also a htmlized version available at:
> >>> http://tools.ietf.org/html/draft-templin-aeroent-00
> >>>
> >>>
> >>> Please note that it may take a couple of minutes from the time
> >>> of submission until the htmlized version and diff are available
> >>> at tools.ietf.org.
> >>>
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> ftp://ftp.ietf.org/internet-drafts/
> >>>
> >>> _______________________________________________ I-D-Announce
> >>> mailing list [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/i-d-announce
> >>> Internet-Draft directories: http://www.ietf.org/shadow.html or
> >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>
> >>> _______________________________________________ dmm mailing list
> >>>  [e-mail] https://www.ietf.org/mailman/listinfo/dmm
> >>
> >> _______________________________________________ dmm mailing list
> >> [e-mail] https://www.ietf.org/mailman/listinfo/dmm
> >
> > _______________________________________________ dmm mailing list
> > [e-mail] https://www.ietf.org/mailman/listinfo/dmm
> >
> >
> 
> 
> _______________________________________________
> dmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmm