Re: 54 - marcelo's editorial comments
<[email protected]> Mon, 7 Nov 2005 23:16:06 +0200
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
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