draft-ietf-mobileip-vpn-problem-solution-02

Sami Vaarala

Netseal

Outline

• Design team conclusions and rationale

• Three layer solution

• Summary and status of solution draft

• Optimizations and improvements

Design team conclusions and rationale

• Decided to document base approach– Favor solution with minimal changes to standards– Optimizations considered (but postponed)

• We need an internal home agent– The MN needs to be able to move inside– But overhead of always tunnelling to the DMZ was considered to

be too high• We need an external mobility agent

– IPsec does not have standardized mobility (SA endpoint update), and we want ”seamless” mobility even when outside

– We need to support FAs in the external networks => the lowest layer must speak MIP

• Some problems left out of scope for now– E.g. networks with only HTTP access

Three layer solution – Topology

FirewallExternal

Home Agent

InternalHome Agent

VPN

External network Internal network(e.g. corporate network)

MNMN

CN

Internal MIPv4 tunnel

IPsec tunnel

External MIPv4 tunnel

DMZ

Three layer solution – MN inside (1)MNExt. HA Int. HAVPN GW CN

RRQRRQRRP

RRPRRQ (dereg.)

Internal MIP tunnel OK

RRP

Data traffic (w/ reverse tunnelling)

If external HA responds, deregister

Three layer solution – MN inside (2)MNExt. HA Int. HAVPN GW CN

RRQRRP

Internal MIP tunnel OK

Data traffic (w/ reverse tunnelling)

Data traffic (w/ reverse tunnelling)

MN moves and gets a new care-of address

RRQ

Three layer solution – MN outside (1)MN Ext. HA Int. HAVPN GW CN

External MIP tunnel OK

:

IPsec tunnel OK

Internal MIP tunnel OK

RRQRRQ

RRP

IKE+ VPN address assignment

RRQRRP

Data packets(w/ reverse tunnelling)

All data goes through the internal HA, even if CN is outside

Three layer solution – MN outside (2)MN Ext. HA Int. HAVPN GW CN

External MIP tunnel OK

RRQ

RRP

Data packets(w/ reverse tunnelling)

MN moves and gets a new care-of address

Data packets(w/ reverse tunnelling)

RRQ

Three layer solution – Pros and Cons

• Pros– Only mobile node aware of solution– No changes to IPsec or Mobile IPv4 standards– Existing VPN, HA, FA boxes can be used

• Cons– Overhead (latency, packet size)– Three layers to manage (e.g. authentication)– Software complexity

• Three layers != three boxes– Combined VPN+HA box possible

Summary of the solution draft

• Solution draft– Applicability statement of MIPv4 & IPsec– for enterprise mobile users– only imposes requirements on the mobile node

• What’s there in addition to standards?– Scenarios, message and packet diagrams– Network detection requirements and basic algorithm

• important because has major security impact!• double registration, trust (only) internal HA reply

– Other security considerations

Solution draft status

• -02– Missing minor comments from design team– Security review by Radia pending

• Plan– Final design team round => -03– Working group review => -04– Last call

Optimizations and improvements

• Scoped outside base solution draft– Interesting because of base solution overhead– Worst case – 129 octets / packet

• Really the worst case, NAT on each layer

• Approaches collapse tunnelling some way– Combined VPN/FA device– IPsec mobility

• SA endpoint update

– Zero-overhead MIP tunnelling• address switching

• Improve security of network detection

Thank you!

Questions ?