RE: about draft-ietf-mobike-protocol-01.txt (issue 40)

My apologies for the long delay (I was on vacation most of
August, and your email somehow slipped through my mind).  I've
now filed your comments as issue 40 (although since you had
quite many comments, some of them might need separate issue
numbers later).

> - IMHO the WG should pay (again) more attention to its
> charter: multihoming support is in it and to mention
> multihoming just before explaining it has nothing to do with
> the main scenario (and in fact with the document) is not
> right. So please really fix the Abstract!

Ok, I'll try to rephrase this in the next version.

> - motivation 2nd paragraph: the "another example" is a very
> limited view of what multihoming support needs. I'd like to
> see the mobike protocol supporting simultaneous multiple peer
> addresses.  (I use the term "peer address" from pki4ipsec
> documents because it could not confused with addresses in
> traffic selectors).

Since the first version of MOBIKE only deals with the outer
(tunnel header) addresses, using multiple addresses for an IPsec
SA simultaneously would probably mean either load balancing
(explicitly ruled out in the WG charter) or sending copies of a
single ESP packet over several paths (nobody has expressed any
interest in this so far).

But this is probably not what you meant... ?

> - in 2.1 the NAT_XXX_IP notifications are mandatory because it
> is the way the IP addresses in the IP header can be protected
> against en route modification (what I called the transient NAT
> attack). As the NAT_DETECTION_* could be interpreted as NAT-T
> is supported the NAT prevention stuff was introduced... This
> doesn't matter as soon as the IP addresses which will become
> the initial peer addresses are reflected in an integrity
> check.

You're right, I forgot to show the NAT_PREVENTION notification
in Section 2.1 (Section 2.6 did say that it's also included in
IKE_SA_INIT). I'll fix this...

> - in 2.2 why the ADDITIONAL_*_ADDRESS are limited to IKE_AUTH?
> (2.4 is too far, please add a pointer to it)

Ok, I'll add a pointer.

> - IMHO we need the capability to remove addresses too. Some
> care should be taken if we remove all or "important"
> addresses.  (same: pointer to 2.4)

We already have the _capability_ to remove addresses (you send a
new address list that does not contain the address you want to
remove).  The same capability could be implemented by more
complex protocol mechanisms, but I don't currently see any
reason to do so...

>- 2.2 is enough to make the transport mode with mobike I-D 
> applicable, so we should progress it?

A good question, I'll leave this to the WG chairs...

> - in 2.3 the SPD entries have to be updated too or expired SAs
> will be renewed with wrong addresses.

I'll add a clarification about this (where exactly the
addressses have to be updated depends a lot on the
implementation; e.g. the VPN client I have on my PC treats the
IPsec tunnel as a virtual interface, and stores some of the
information RFC 2401 would call "SPD" in what the implementation
calls "routing table").

> - in 2.3 it should be clearer that NAT_XXX notifications are
> mandatory.

Do you mean the NAT_DETECTION_*_IP or NAT_PREVENTION
notifications?

Currently the idea is that if you support NAT-T, you include
NAT_DETECTION_*_IP payloads; if you don't want NAT-T and do want
the "NAT prevention" feature, you include NAT_PREVENTION (but
not NAT_DETECTION_*).

> - the link between 2.2 and 2.3 is not explained because the
> new addresses are taken from the IP header. BTW I am afraid
> the main scenario is the only supported scenario as a
> consequence...

Could you give a concrete example of a scenario that can't be
done currently?

> - another limitation of 2.3 is it cannot update selectively a
> subset of SAs: again a case only is handled!

Yes, and this is intentional (there was rough consensus in issue
8 to do it this way -- if you want to update a subset of SAs,
you need to have several IKE_SAs).

>  - in 2.4 the case where there is a UPDATE_SA_ADDRESSES before
>  should be explained. I propose to explain that the current
>  peer addresses are IKE_SA parameters and the
>  UPDATE_SA_ADDRESSES echange defines their initial values.

I'll try to clarify 2.4 in the next version..

> - the address update by the responder is a bit complex. It
> seems to work but I am afraid it should be hard to explain, so
> I'd like to get a simpler mechanism (IMHO this is again a
> symptom of mobility vs multihoming problem of the document).

I agree the explanation is quite complex. I'll try to simplify
it in the next version...

> - 2.7 is not sound with 2.3 (IMHO the problem is in the
> wording because the way a NAT_PREVENTION can be associated
> with a UPDATE_SA_ADDRESSES is clear but is not as described in
> 2.7).  BTW I agree with the TBD (:-).

Quite right. I'll work on this for -02.

> - section 4 misses one of the mobility specific points: the
> initiator peer address (the MN care-of address) is
> dynamic/unknown so could not be verified by the responder (VPN
> server). This is why the protection performed by NAT_XXX
> notifications are necessary (BTW I have no concern to make it
> mandatory even in pure multihoming cases).

I'm updating the security considerations section in the next
version (see also issues 27 and 28), I hope the new text better
takes this into account.

> - the fact the ingress filtering works for UPDATE_SA_ADDRESSES
> because the new addresses are from the IP header should be
> mentioned (as a justification of this choice or as a
> point-to-solve if the choice will be changed).

Good point, I'll add this to the security considerations
section.

> - requires != SHOULD. BTW I am against the idea to make MOBIKE
> less efficient than mobility just because of the FUD of third
> party flooding attacks.

I fully agree that these flooding attacks are mostly FUD, and I
would not mind changing the "return routability check SHOULD be
done before updating.." to a MAY or something. But on the other
hand, you can ignore the SHOULD if want, too.

Best regards,
Pasi