-------------------- Jari Arkko (2005-10-19): https://www.machshav.com/pipermail/mobike/2005-October/001133.html Editorial: >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/ > user interaction for authentication (entering a code from a token > card, for instance). > .... authentication, such as entering ... >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. >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. >3.4. Limitations > > Probably worthwhile to explain this earlier, maybe as Section 1.1. >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/? -------------------- Jari Arkko (2005-10-23): https://www.machshav.com/pipermail/mobike/2005-October/001171.html 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. -------------------- Pasi Eronen (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001186.html > 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 ... How about just adding "This approach applies to the addresses in the IPsec SAs; in the IKE_SA case, the exchange initiator can decide which addresses are used." to the end of that paragraph? > >s/persons/persons or devices/? Hmm... IMHO "held responsible" is something that mostly applies to people, and using it with devices doesn't sound too good to me.. -------------------- Jari Arkko (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001187.html >How about just adding "This approach applies to the addresses >in the IPsec SAs; in the IKE_SA case, the exchange initiator can >decide which addresses are used." to the end of that paragraph? > > Sure. True. OTOH, the most likely case is that the person isn't really responsible, but his device has some malware. I'm not sure I have a better text suggestion for you. Let it be. --------------------