65 - jari's editorial issues

Proposed text:

>>In the current
>>   specifications, the IPsec and IKE SAs are created implicitly between
>>   the IP addresses that are used when the IKE_SA is established.
>>
>s/current specifications/base IKEv2 protocol/
>  
>
See above.

>>   user interaction for authentication (entering a code from a token
>>   card, for instance).
>>
>.... authentication, such as entering ...
>  
>
See above.

>>3.1.  Basic Operation
>>
>2nd para: it would be useful to state early that ike exchange
>initiator decides the addresses to use for that exchange. Right
>now you only talk about IPsec addresses. I know this is part of
>ikev2, but the reader may not have the background to understand
>this.
>  
>
   MOBIKE solves this problem by taking a simple approach: the party
   that initiated the IKE_SA ...

=>

   MOBIKE solves this problem by taking a simple approach
   Firstly, for every IKE exchange, the initiator of that exchange
   decides which addresses to use for IKE itself. Secondly, the
   party that initiated the IKE_SA ...

>>3.2.  Example Protocol Runs
>>
>2nd example, Step 3 needs to show that the response is lost.
>
>The 2nd example should also explain better why COOKIE2
>is needed in Step 4.
>  
>
This was already discussed in the context of issue 59 so
I won't add the text here.

>>3.4.  Limitations
>>  
>>
>Probably worthwhile to explain this earlier, maybe as Section
>1.1.
>  
>
Just move it there.

>>4.8.  NAT Prohibition
>>
>This section would benefit from a message flow example.
>
>>   The attackers in this threat can be either outsiders or even one of
>>   the IKEv2 peers.  In usual VPN usage scenarios, attacks by the peers
>>   can be easily dealt with if the authentication performed in the
>>   initial IKEv2 negotiation can be traced to persons who can be held
>>   responsible for the attack.  This may not be the case in all
>>   scenarios, particularly with opportunistic approaches to security.
>>  
>>
>s/persons/persons or devices/?
>
See above.

--Jari