Mobile IPv4 Traversal across IPsec-Based VPN Gateways
RFC 5265

Note: This ballot was opened for revision 05 and is now closed.

(Jari Arkko) Yes

(Ron Bonica) No Objection

Comment (2007-11-28 for -)
No email
send info
Also agree with Lisa's DISCUSS

(Ross Callon) No Objection

(Lisa Dusseault) (was Discuss) No Objection

(Lars Eggert) (was No Record, No Objection) No Objection

Comment (2007-11-27 for -)
No email
send info
I agree with Lisa's DISCUSS, and will let her hold it.

Turning off IPsec when the mobile host is deemed to be within the security perimeter requires an absolutely bulletproof mechanism of detecting whether this is the case as well as a mechanism to monitor whether this remains to be the case. The suggested mechanism depends on the correct configuration of firewalls (which isn't verifiable by the mobile host) as well as reliable and trustworthy connectivity status changes, which aren't a feature of many networks. This is far from bulletproof.

(Sam Hartman) (was Discuss) No Objection

Comment (2007-11-28)
No email
send info
I'd like to throw my opinion into the raging network detection debate.

First, I think that some sloppiness in detecting when you have left to
home network is acceptable, particularly when the I-HA rejects any
packet coming in from the outside.  So you could send packets, but you
could not receive anything and your packets would be discarded which
for many classes of connection will limit the number of packets that
get sent.

However I think that once detection is triggered it needs to be
bullet-proof.  I disagree with Lars that the MN is the critical party
here though.  It is the enterprise that wants to set and audit its
security policy, so the enterprise needs to be the primary party
responsible for enforcing the security policy.  So, I think it is the
I-HA that needs to confirm this policy not the MN.  I think that
mandating I-HAs need to reject traffic from outside trusted networks
and need to maintain a list of trusted networks is critical.  It may
also be important for an MN to know whether it is talking to an I-HA
that is maintaining such a list of trusted networks.  Doing so could
be done by adding a MIP4 option.  I think we're going to have to give
up on the idea that the I-HA doesn't need to change in order to get a
secure solution to this problem.

(Russ Housley) (was Discuss) No Objection

Comment (2007-11-27)
No email
send info
  Based on Gen-ART Review by Suresh Krishnan.

  Section 3.3, Bullet  2: The following text is redundant since it is
  covered by bullet 3:
  > If a previous registration reply from the x-HA
  > has been received, the MN SHOULD de-register with the x-HA.

  Section 3.4: It is not clear which party this required to ensure this
  requirement is met:
  > Therefore, it is required that x-HA and i-HA addresses MUST
  > be different

  Section 3.6: It is not clear what "inside" means here:
  > The registration process can be improved in many ways.  One simple
  > way is to make the x-HA detect whether a registration request came
  > from inside or outside.  If it came from inside, the x-HA can simply
  > drop the registration request.

(Cullen Jennings) (was No Record, No Objection) No Objection

(Chris Newman) No Objection

Comment (2007-11-29 for -)
No email
send info
Other ADs have discusses that cover my concerns.

(Jon Peterson) No Objection

(Tim Polk) (was Discuss, No Objection, Discuss, No Objection, No Record, Discuss) No Objection

(Dan Romascanu) No Objection

Comment (2007-11-29 for -)
No email
send info
From the Introduction section: 

      must ensure that traffic is not routed through the DMZ when the
      mobile node is inside (to avoid scalability and management

It is not clear what kind of 'management issues' are refered here. I suspect that these are related to security and access management which are mentioned later, but the text does not say this. I suggest to clarify.

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection