54 - marcelo's editorial comments

Hi all,

I'm looking at the editorial issues and trying to see
what exactly needs to be changed.

First the ones that I think need a text change:

>9. In section 4.4 i think that the Dead Path Detection indication should 
>be mentioned as one of the events that should lead to an address change 
>(perhaps a reference to section 4.9 would be useful too) along with
>  
>
Suggested change:

   o  An IKEv2 request has been re-transmitted several times, but no
      valid reply has been received.  This suggests the current path is
      no longer working.

=>

   o  An IKEv2 request has been re-transmitted several times, but no
      valid reply has been received.  This suggests the current path is
      no longer working. See also Section 3.9.

>10. In section 4.4, it is stated that:
>
>  o  It updates the IPsec SAs associated with this IKE_SA with the new
>      addresses (unless this was already done before sending the
>      request).
>
>As i understand it, the reason for updating the addresses here is 
>because the reply plays the role of a return routability check, right?
>It would make sense to state so, for instance adding something like
>
>  o  It updates the IPsec SAs associated with this IKE_SA with the new
>      addresses (unless this was already done before sending the
>      request i.e. no return routability check was required, see 4.6).
>  
>
Ok. The current Section that this text is in is by the way
3.5.

> 12. In section 4.6 it is stated that:
>
>   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 am not sure that the example of the certificate is a good example... 
>what if the certificate is self signed? (i don't know if those are 
>supported) but in any case, i don't know how simple is that certificates 
>can prove address ownership (this depends of the checks performed by the 
>CA about address ownership)
>
Right. Suggested text change: s/the address is
included in the peer's certificate/the address is
included in a certificate given to the peer by a trusted
authority/

Then the ones that do not appear to need a text
change:

>1. I think that in the Introduction, a comment about what is the 
>difference between mobike and what can be achieved with MIP is. I mean, 
>after reading the spec, the difference is clear, but stating it in the 
>introduction would make things easier to understand, especially since 
>the mobility scenario is described there. In particular, stating the it 
>is not a goal of mobike to make changes in the IP address transparent to 
>the upper layers (as stated in the charter for instance) would be useful.
>
The new introduction makes it quite clear that we are talking
about tunnel mode, so the payload traffic & address effects
appear to be obvious. We could of course describe what the
differences to various other mobility and multihoming protocols
are, but I'm not sure that text is easy to write and get
consensus on.

>6. In section 3.2. it would make clearer to me if the messages and 
>extensions introduced by mobike (i.e. the actual mobike protocol) where 
>highlighted somehow in the examples (so that it can be distinguished 
>from general IKE exchange)
>  
>
But I believe hiding this is actually useful for the overview,
as people don't have to understand in detail the work split
between IKEv2 and MOBIKE. And the information is very
explicit in subsequent sections.

>13. Later on, in this section 6.3 it is stated that:
>
>   It should also be noted, as shown in [Bombing], that without ingress
>   filtering in the attacker's network, such attacks are already
>   possible simply by sending spoofed packets from the attacker to the
>   victim directly.
>
>But the whole point of this attack is to achieve amplification, right? I 
>mean, the story that an attacker using a 56kbps starts a download from a 
>heavy server and the redirects it towards a victim flooding it. The 
>point is that the attacker could only send 56kbps, while in this attack, 
>it could redirect the whole server flow through the victim. So, i don't 
>agree with this comment i would suggest to remove it.
>  
>
The current text already talks about amplification in
the same paragraph. The point is that mere flooding
without amplification would not be a problem.

>14. In section 6.4 it is stated that:
>
>   Attackers may spoof various indications from lower layers and the
>   network in an effort to confuse the peers about which addresses are
>   or are not working.  For example, attackers may spoof link-layer
>   error messages in an effort to cause the parties to move their
>   traffic elsewhere or even to disconnect.  Attackers may also spoof
>   information related to network attachments, router discovery, and
>   address assignments in an effort to make the parties believe they
>   have Internet connectivity when, in reality, they do not.
>
>   This may cause use of non-preferred addresses or even denial-of-
>   service.
>
>As i understand this, all non verifiable indications should be used 
>merely as hints. When such a hint is received, the node should perform a 
>Dead Peer Detection, verifying securely, that the path is no longer 
>working.
>  
>
Well, this isn't strictly speaking true. There are non-verifiable
indications that we HAVE to take into account. Or at the very
least we know that for such an indication, DPD will surely
fail too. For instance, if L2 decides that the link is down,
IP and upper layers have way of reversing that decision
even if decision was originally based on unverifiable
indications.

--Jari