Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec

From: Domagoj Premec <[email-masked]>
Date: Wed, 26 Jan 2011 15:25:33 +0100

I support this draft moving forward and becoming a WG document. IMO
the current IPSec based security for MIP6 does have its drawbacks and
this draft offers an interesting alternative. I was able to play
around a bit with a MIP6 client implementing this draft, and it worked
flawlessly and to set it up was a breeze.

Domagoj

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of marcelo bagnulo braun
> Sent: Monday, January 24, 2011 8:34 PM
> To: mext
> Subject: [MEXT] Call for WG adoption of I-D:
> draft-korhonen-mext-mip6-altsec
>
> The ID has had 3 reviews as we require.
> So, we are now  ready to ask the WG if they think we should adopt the
> document.
>
> Please express your opinion before monday 31st jan.
>
> Reviews can be found:
>
> The I-D: draft-korhonen-mext-mip6-altsec-06  has been reviewed by:
>
> 1. Jan Zorz
> http://www.ietf.org/mail-archive/web/mext/current/msg04489.html
>
> 2. Domagoz Premec
> http://www.ietf.org/mail-archive/web/mext/current/msg04457.html
>
> 3. Ryuji Wakikawa
> http://www.ietf.org/mail-archive/web/mext/current/msg04470.html
>
>
>
>
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 26 Jan 2011 13:26:50 -0800

Hello,

I would like to introduce a new approach to mobility
management, which is an in-built feature of a new
routing and addressing system known as the Internet
Routing Overlay Network (IRON):

http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt

IRON is a product of the IRTF Routing Research Group
(RRG), which was chartered to provide recommendations
on addressing the Internet routing scaling issue. While
the IRON development effort focused primarily on routing
scaling, it soon became clear that mobility management
was also naturally afforded by the base architecture
with no need for adjunct mechanisms. Also, although this
fully-integrated proposal is new many of the concepts were
motivated by earlier works. The document therefore cites
related initiatives which explored similar concepts.

The IRON mobility management approach combines the best
aspects of both proactive and on-demand route discovery.
IRON Clients (which may include mobile end systems and
mobile routers) discover topologically-close IRON Serving
routers (i.e., "Servers") and create a connection with
one of the Servers for the purpose of maintaining 
bidirectional tunnel neighbor state. The Client then
registers one or more of its interfaces with the Server
so that the Server has handles for sending return traffic
to the Client. Since the Server can observe the public-side
address(es) of the Client without the Client needing to
discover them itself, the system therefore also naturally
supports a simplified form of NAT traversal. 

When a Client connects to the Server, the Server sends a
"link up" indication via a dynamic routing update that is
propagated to a core set of Relay routers (i.e., "Relays").
In practice, there will be O(10's) of Relays while there
may be several orders of magnitude more Servers that are
topologically distributed throughout the Internet. Only
the Relays need maintain a full topology in their routing
tables; Servers need only maintain routing table entries
for their current set of connected Clients.

When a Client 'A' connected to Server 'Y' has a packet to
send to a new correspondent Client 'B' connected to Server
'Z', 'A' first tunnels the packet to 'Y' as its default
router in the overlay network. Since 'Y' has only partial
topology information, it then tunnels the packet to a Relay
'R'. Since 'R' has full topology knowledge, it then tunnels
the packet to 'Z' which in turn tunnels the packet to 'B'.
At the same time, 'Z' also returns a Redirect message to
inform 'Y' that 'Z' is a better next hop in the overlay
network to reach 'B'. If 'Y' is configured to forward
Redirects to its Clients, it then forwards the Redirect to
'A' which then populates its routing tables with a more-
specific route. Otherwise, 'Y' uses the Redirect to update
its own routing tables. Hence, route optimization is
naturally supported.

When 'A' changes its ISP points of attachement (i.e., when
'A' moves), it need not explicitly inform 'Y' of the changes
as long as it wishes to retain 'Y' as its Server, since 'Y'
will naturally discover any changes in 'A''s address(es) via
the source addresses of 'A''s packets. 'A' also need not
inform any of its recent correspondents about the changes,
since the correspondents can still reach 'A' via 'Y'. Hence,
localized mobility events are communicated implicitly and
immediately with no need for binding updates.

When 'A' moves far away from 'Y', it can leisurely discover
a new nearby Server 'W'. It can then connect to 'W' and
disconnect from 'Y' which will cause dynamic routing between
the overlay network Relays to naturally update 'A''s
Client-to-Server bindings. Hence, routing stretch is
managed without need for delay-sensitive actions.

Finally, the base system does not require Client-to-Client
binding updates. For example, if Client 'C' has a routing
table for 'A' with next-hop 'Y', but 'A' has moved to a
new Server 'W', 'C' will receive Redirect messages from
'Y' informing it that 'A' is now associated with 'W'.
Hence, 'A' need not keep track of recent correspondents,
since any correspondents will naturally be redirected to
'A's new location without risk of packet loss. (Again,
this is a coarse-grained mobility consideration, since
'A' will typically not change to a new Server unless it
moves some significant distance, e.g., 1000 miles).

Comments and questions welcome,

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 27 Jan 2011 13:00:47 -0800

Here is another aspect of the proposal that should be
of interest to this community:

http://www.ietf.org/id/draft-templin-ironmike-00.txt

This shows how the IRON approach aligns with MOBIKE to
present a system for managing VPN links that allows
clients to connect to a nearby VPN gateway that in turn
connects to a trusted and secure network. As clients
change ISP connections, the VPN gateways naturally learn
about the changes. As clients move significant distances,
they simply discover and connect to a different nearby VPN
gateway. Client-to-client communications then are conveyed
across the trusted and secure network. Very simple; very
few moving parts.

Fred
[email-masked] 

> Behalf Of Templin, Fred L
> Sent: Wednesday, January 26, 2011 1:27 PM
> To: [email-masked]
> Subject: [MEXT] IRON - a new approach to mobility management
> 
> Hello,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jan 2011 15:31:10 -0800

I should also mention that an initial implementation
is available:

http://www.ietf.org/mail-archive/web/int-area/current/msg02471.html
http://www.ietf.org/mail-archive/web/int-area/current/msg02472.html

Thanks - Fred

> Sent: Thursday, January 27, 2011 1:01 PM
> To: [email-masked]
> Subject: Re: [MEXT] IRON - a new approach to mobility management
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 31 Jan 2011 09:23:34 -0800

Here also is the way that operators/providers can make
a new business model for themselves:

http://www.ietf.org/id/draft-templin-iron-pm-00.txt

The customers get to use their same addresses even if
they use an access technology other than the native one
they get directly from the provider, and the provider
gets to market a managed service that customers will
recognize as a good value at reasonable rates.

Everybody wins, and mobility management with route
optimization over multi-access end user devices is
naturally supported.

Fred

> Sent: Friday, January 28, 2011 3:31 PM
> To: [email-masked]