jari's review of protocol-04

Here are my LC comments. Overall, I'm quite happy with
specification as it is. Some technical and editorial issues
are listed below, however.

I have added names for technical issues to
assist in keeping track of what issues we have.

Technical:

*imprecise explanation of what nat cases are not supported*

>   "Does not fully support" means that no special effort is made to
>   support this functionality.  However, if the alternative is losing
>   connectivity completely, the responder can still attempt to proceed
>   with the change, and depending on, e.g., the exact type of NAT, it
>   may succeed.  However, analyzing the exact circumstances when this
>   will or will not work is not done in this document.
>  
>
I'm OK with the text being vague about the type of
scenarios supported beyond the basic client-inside-NAT
case. However, the above text appears to say that the
responder is capable of detecting such situations,
which I don't think is at least always true.

*certain vs. possible changed address info*

>   o  An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS
>      notifications is received.  This means the peer's addresses may
>      have changed.
>  
>
I think we have two cases: the list (and source) either
contains the addresses that we currently know of and
use, or they don't. In the former case addresses may
have changed, but in the latter case they surely have.
For instance, if the peer sends us a message saying
that its now in address B instead of A, we really need
to take that into account, rather than continuing to
use A.

Suggestion: explain this in the bullet item, or split the
item in two.

*minimal conformance requirements*

>   Note that both peers can have their own policies about what addresses
>   are acceptable to use.  A minimal "mobile client" could have a policy
>   that says that only the responder's address specified in local
>   configuration is acceptable.  This kind of client does not have to
>   send or process ADDITIONAL_*_ADDRESS notifications.  Similarly, a
>   simple "VPN gateway" that has only a single address, and is not going
>   to change it, does not need to send or understand
>   ADDITIONAL_*_ADDRESS notifications.
>  
>
I think we discussed this previously (and I have not
yet checked what the result of that discussion was).
However, the above client text sounds a bit too flexible
in my opinion.

*RR requirements according to earlier decisions*

>   Both parties can optionally verify that the other party can actually
>   receive packets at the claimed address.  This "return routability
>   check" can be done before updating the IPsec SAs, immediately after
>   updating them, or continuously during the connection.
>
>   By default, the return routability check SHOULD be done before
>   updating the IPsec SAs.  In environments where the peer is expected
>   to be well-behaved (many corporate VPNs, for instance), or the
>   address can be verified by some other means (e.g., the address is
>   included in the peer's certificate), the return routability check MAY
>   be omitted or postponed until after the IPsec SAs have been updated.
>  
>
I think we decided earlier that the RR checks are by default
on, and that they are by default done before updating the
SAs. The above text seems to omit the former default. Suggested
fix:

   Both parties can optionally verify that the other party can actually
   receive packets at the claimed address.  By default, this "return
   routability check" SHOULD be performed. In environments where the
   peer is expected to be well-behaved (many corporate VPNs, for instance),
   or the address can be verified by some other means (e.g., the address is
   included in the peer's certificate), the return routability check MAY
   be omitted.

   The check can be done before updating the IPsec SAs, immediately after
   updating them, or continuously during the connection. By default, the
   return routability check SHOULD be done before updating the IPsec 
   SAs, but in some environments it MAY be postponed until after the
   IPsec SAs have been updated.

*meta issue about specification completeness*

Pasi, as you have edited ikev2-clarifications, what kind of
issues have you seen that have caused so many clarifications
needed? If you have a list of these issue types, can we go
over our spec to ensure that we don't introduce the same
unclarities?

I'm asking because the specification style is close to what
we had in IKEv2. Do we need add tables of what attributes
are possible in what messages, state machines, or spend
more effort in detailed processing algorithms?

(But I did not see anything on my review that would
be obviously prone for interpretation.)

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