[Mip4] AD review of draft-ietf-mip4-vpn-problem-solution

[Jari Arkko <[e-mail]>]

I have reviewed this document. Overall, its well written and ready to
move forward. The one issue that I worry about is what kind of warning
labels we should we should attach to a network detection and VPN
on/off procedure that has potential failure modes resulting in believing
that VPN need not be on. The security and VPN community may have
something to say about that. It is possible that tightening the language
about what types of networks the procedure is applicable suffices, if
there is an issue. In any case, I believe the right thing is to take this
document to the greater community and see what they say. So, we
are going to Last Call.

A few other notes below. These should be dealt with, but it is OK to
incorporate them in the revision needed as a part of Last Call or
IESG review, or in AUTH48 if no revision is needed.

>    Reverse tunneling in the inner Mobile IPv4 layer is often required
>    because of IPsec security policy limitations.  IPsec selectors define
>    allowed IP addresses for packets sent inside the IPsec tunnel.
>    Typical IPsec remote VPN selectors restrict the client address to be
>    VPN-TIA (remote address is often unrestricted).  If reverse tunneling
>    is not used, the source address of a packet sent by the MN will be
>    the MN's home address (registered with i-HA), which is different from
>    the VPN-TIA, thus violating IPsec security policy.  Consequently the
>    packet will be dropped, resulting in a connection black hole.
>   
>    Some types of IPsec-based VPNs, in particular L2TP/IPsec VPNs (PPP-
>    over-L2TP-over-IPsec), do not have this limitation and can use
>    triangular routing.

This is not strictly speaking true. Even PPP links can have ingress
filtering
turned on (and often do, at least when run outside L2TP). Please rephrase.

> Firewall state considerations
>    A separate firewall device or an integrated firewall in the VPN
>    gateway typically performs stateful inspection of user traffic.  The
>    firewall may, for instance, track TCP session status and block TCP
>    segments not related to open connections.  Other stateful inspection
>    mechanisms also exist.
>
>    Firewall state poses a problem when the mobile node moves between the
>    internal and external networks.  The mobile node may, for instance,
>    initiate a TCP connection while inside, and later go outside while
>    expecting to keep the connection alive.  From the point of view of
>    the firewall, the TCP connection has not been initiated, as it has
>    not witnessed the TCP connection setup packets, thus potentially
>    resulting in connectivity problems.

All this depends on the placement of the firewall. Presumably firewalls
in external networks are not  a problem, because they only see IPsec.
Firewall placement within the internal network determines whether the
session has been seen before after a movement occurs.

>    technlogy.  For instance, some mobile nodes may be implemented as

Typo.

Jari



-- 
Mip4 mailing list: [e-mail]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/