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 ?