Subject: Re: [Mobike] 54 - marcelo's editorial comments

From: <[email-masked]>
Date: Mon, 7 Nov 2005 23:16:06 +0200

Jari Arkko wrote:

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

Section 3.9 is about NAT prohibition, and doesn't need to be
referenced here?? In -04, Section 4.9 was about path testing, but
that's not really very closely related either. IMHO Marcelo's
original comment is already handled here: failing DPD == "IKEv2 
request has been re-transmitted several times, but no valid reply 
has been received".

My proposal: no text change.

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

The pointer to 4.6/3.5 is IMHO confusing; the real pointer is to 
the step "Updates the IPsec SAs..." step earlier in this section.

How about this?

   o  It updates the IPsec SAs associated with this IKE_SA with
      the new addresses (unless this was already done earlier
      before sending the request; this is the case when no
      return routability check was required).

> > 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/

My proposal: 

  [..], or the address can be verified by some other means 
  (e.g., a certificate issued by an authority trusted for 
  this purpose), [...]

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Nov 2005 20:03:37 +0200

Pasi,

>My proposal: no text change.
Ok.

>the step "Updates the IPsec SAs..." step earlier in this section.
Yes.

>      return routability check was required).
Ok.

>  (e.g., a certificate issued by an authority trusted for 
Ok. I think that also addressed Tero's concern with
my original text proposal.

--Jari