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

This slipped away from my processing queue
too, sorry Francis. Many thanks however for
your careful review, it seems that you caught
many issues that will lead to a document
change.

Here are some comments and suggested
changes, embedded in Pasi's comments.

>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.
>  
>
Here's a suggested edit:

   ... MOBIKE is making it possible for a remote access VPN user to move
   from one address to another while keeping the connection with the VPN
   gateway active.

=>

   ... MOBIKE is making it possible for a remote access VPN user
   to maintain a single VPN connection with a gateway, despite
   moving from one address to another or having multiple addresses.

Similar change in Section 1.1. Is there anything else Francis?

>>- 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... ?
>  
>
The charter indeed limits us to "failover" semantics
of multihoming. But perhaps this is about IPsec
SA movement granularity? But we already discussed
that earlier and arrived at a conclusion.

>>- 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...
>  
>
Sounds clear.

>>- 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...
>  
>
I tend to agree that its better to have a single mechanism
that simply replaces the set, rather than a "diff" scheme.
The latter would work better when there's a very large
set of addresses, but I think simplicity is more valuable
than covering that case. In any case, we know that there
are other limitations in our technology for dealing with
large address sets, e.g, ability to probe for a working
address pair.

>  
>
>>- 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...
>  
>
I'm not sure I understand how Section 2.2 specifically
helps this, but I think our plan is to work on the transport
mode document once we finish this one -- and we are
hopefully not too far off from this. I'd like to do a WGLC
in September, and if all goes well we might be finished
prior to Vancouver -- so get your transport mode document
polished so that we'll have something to discuss there!

>>- 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").
>  
>
Hm. I'm not sure I understand this. I thought SPD
deals with the unprotected packets, rather than the
outer addresses, which I think we are working with.
I would understand the SPD entry update if we
were talking about transport mode, however.

>>- 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 document does not appear to say this explicitly,
or did I miss something? Add text...

>>- 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?
>  
>
I think the link is explained. 2.2 says: "The recipient
stores this information, but no other action is taken
at this time." Presumably somewhere else we have
text about what to do when you fail.

Suggestion: unless we can see a more specific
case where there's a problem, I don't see a need
to change the document on this point.

>>- 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).
>  
>
Yes. Btw, we do intend to be fairly strict about
re-opening issues. (We will re-open an issue only if
we detect a new and/or serious technical problem.)

>> - 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..
>  
>
Ok.

>>- 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...
>  
>
Ok.

>  
>
>>- 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.
>  
>
Ok.

>  
>
>>- 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.
>  
>
Good.

>  
>
>>- 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.
>  
>
Right.

>  
>
>>- 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.
>  
>
We have existing consensus on this issue. Lets
work with that and not re-open that one.

--Jari