Re: [DMM] DMM Interim call #2 - agenda forming

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

Hi Sri,

See below for some follow-up:

> -----Original Message-----
> From: Sri Gundavelli (sgundave) [mailto:[e-mail]]
> Sent: Thursday, September 11, 2014 12:28 AM
> To: Templin, Fred L; Jouni Korhonen; [e-mail]
> Cc: Dapeng Liu; [e-mail]
> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
> 
> Hi Fred,
> 
> The below comment from you made me thinking. I must admit I'm not much
> familiar with Aero, have not seen its references in CDMA, WiMAX,
> CableLabs, WLAN or LTE architectures.  But, if it has all the mobility
> features and you believe this can conclude the WG, I thought I will
> explore this a bit. I started reviewing the charts that you sent and
> started browsing some of the specs. Few high-level questions, if you can
> answer or point me to some documents, it will be great.
> 
> 
> 1.) What is the interface between the Aero Server and the client ? Is it
> just DHCPv6 ? There is no other signaling interface ?

DHCPv6 is used for PD as well as mobility signaling. IPv6 ND messaging
is used for NUD, route optimization, and the functional equivalent of
a "binding update" via the use of unsolicited Neighbor Advertisements.
 
> 2.) What is the service authorization model for a Aero client ? How is the
> client identified by the server ? What is the security model ?

The Client is identified by the server via the DHCPv6 DUID. The DUID
is most likely based on some serial number or ID that is assigned to
the Client by the AERO service administrative staff.

The security model is based on a multi-tiered layered security approach.
First, the Client must authenticate itself to the network using whatever
access layer securing mechanisms that are available, e.g., IEEE802.1x.
For Clients that are coming into the network from the Internet, the
Client establishes a VPN link to a security gateway at the network
border.

Second, the Client must prove to the Server that it is authorized to
perform DHCPv6 signaling using DHCPv6 Auth or some other DHCPv6
securing mechanism. This is only to protect against an "insider
attack" in which a different Client pretends to be the authorized
Client in order to hijack the authorized Client's prefix, siphon
traffic, etc. Hence, a "better than nothing" authentication such
as DHCPv6 Auth is really all that is needed.

Third, the network must ensure that link-layer addresses cannot
be spoofed. Here, the "link-layer address" is the IP source
address of the encapsulating tunnel header. This is typically
done through proper application of BCP ingress filtering
practices.

Finally, the AERO Server/Relay infrastructure provides a trust
anchor to facilitate Client-to-Client route optimizations. In
particular, Clients trust their Servers but cannot trust each
other initially. If a Client receives a route optimization
signal from its trusted Server, however, it can safely engage
in the route optimization since a chain-of-trust was followed. 

> 3.) Can the Aero solution support IP nodes that do not have Aero client
> stack ?

Proxy AERO could be applied in the same manner as for PMIP,
but the document does not fully investigate that option at
this time.

> 4.) If a mobile or a cable SP deploys Aero, where is their point of
> control ? Where can they do Accounting, Lawful interception ?

Lawful intercept, accounting, etc. can be done at the AERO Servers.
In case these functions are mandatory, direct Client-to-Client route
optimizations would not be permitted in those environments. However,
Client-to-Server-to-Client route optimizations would still be used
to reduce path stretch and reduce load on critical infrastructure.

> 5.) I assume Aero client can be IPv4 or an IPv6 device ? For an IPv4-only
> legacy device, is the interface DHCPv4 ?

The AERO data plane can be either IPv4 or IPv6, and can be tunneled
over either IPv4 or IPv6 access networks. The AERO control plane is
always DHCPv6 and IPv6 ND. In particular, DHCPv6 PD can be used to
delegate IPv4 prefixes in the same way that it can delegate IPv6
prefixes. So no; DHCPv4 is not used in the control plane.

> 6.) Can an operator enable location-based services for a Aero client ?

AERO Clients discover and associate with AERO Servers that are
"nearby". They discover nearby Servers by resolving the DNS
FQDN "linkupnetworks.[domain]" where "[domain]" is a link-
specific DNS suffix. This would provide topological proximity
and I guess most often also geographic proximity. Is that what
you were asking?

> 7.) How can an operator enable IP Flow Mobility type features in an Aero
> system ?

I am not familiar with IP Flow Mobility, but does it mean spreading
traffic load across multiple access links? Like maybe sending streaming
video across WLAN while posting short text messages via 4G? If so,
AERO supports the use of multiple simultaneous access links - like,
keeping both the WLAN and 4G interfaces active at the same time. Or
maybe I am mis-understanding IP Flow Mobility?
 
> 8.) Taking a mobile router scenario, how does Aero client support
> multi-tenancy ? Is there a single tunnel between the client and the server

Again, I am not familiar with the term multi-tenancy, or at least not
with its use within this context. In terms of tunnels, however, the
tunnel is non-broadcast, multiple access (NBMA) and not point-to-point.
So each AERO node sees other AERO nodes as neighbors on the NBMA link.
The AERO interface therefore maintains a neighbor cache the same as
any IP interface, and uses the neighbor cache entries to track the
current L3/L2 address mappings. These mappings may change over time,
e.g., as the result of a mobility event.

Thanks - Fred
[e-mail]

> ?
> 
> 
> Regards
> Sri
> 
> 
> 
> 
> On 9/10/14 11:43 AM, "Templin, Fred L" <[e-mail]> wrote:
> 
> >Hi Jouni,
> >
> >I'd like to propose a slightly different charter:
> >
> >  "AERO already solves distributed mobility management and provides a
> >   a comprehensive mobility solution for any mobile device. AERO should
> >   therefore be approved as the mobility management solution for DMM.
> >   Publication of AERO will therefore conclude the working group's
> >   activity."
> >
> >Can we have this on the agenda?
> >
> >Thanks - Fred
> >[e-mail]
> >
> >> -----Original Message-----
> >> From: dmm [mailto:[e-mail]] On Behalf Of Jouni Korhonen
> >> Sent: Wednesday, September 10, 2014 11:37 AM
> >> To: [e-mail]
> >> Cc: Dapeng Liu; [e-mail]
> >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
> >>
> >>
> >> What do you mean by no agenda? To me it clearly says we use the call #2
> >> for setting up the work split.
> >>
> >> - Jouni
> >>
> >> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti:
> >> > Jouni, why don't we cancel this one (#2) and do the next one (#3) with
> >> > an agenda?
> >> > I hope Alper can attend :-)
> >> >
> >> > Regards,
> >> >
> >> > Behcet
> >> >
> >> > On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen
> >><[e-mail]> wrote:
> >> >>
> >> >> It seems I sent this to a wrong receiver.. that explains why it did
> >>not
> >> >> appear on the list.
> >> >>
> >> >> - Jouni
> >> >>
> >> >> -------- Alkuperäinen viesti / Orig.Msg. --------
> >> >> Aihe: DMM Interim call #2 - agenda forming
> >> >> Päiväys: Mon, 08 Sep 2014 23:43:24 +0300
> >> >> Lähettäjä: Jouni Korhonen <[e-mail]>
> >> >> Vastaanottaja: [e-mail]
> >> >> CC: [e-mail], Dapeng Liu <[e-mail]>
> >> >>
> >> >> Folks,
> >> >>
> >> >> The next interim is close. Assuming there are no overwhelming amount
> >>of
> >> >> comments to the re-charter text, we are ready to start setting up the
> >> >> work split on the solution space! Remember the discussion and the
> >> >> minutes from the IETF#90 Friday session. No other agenda items are
> >> >> planned for the next interim.
> >> >>
> >> >> - Jouni & Dapeng
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> 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