Subject: Re: [Hipsec] OPS-DIR review of draft-ietf-hip-over-hip-05

From: <[email-masked]>
Date: Tue, 1 Mar 2011 09:44:23 -0500

Hi Ari,

> If we explicitly prevent a policy that would not allow un-encrypted connection re-establishing
> UPDATEs, I think we have this fixed, and we would not need to use error messages for informing about
> this. I would change the text in section 5 into (added the last sentence and changed the second-to-
> last one):
> 
>    [...] If encryption was
>    previously used, hosts SHOULD send outside of the encrypted
>    connection only HIP messages that are used to re-establish the
>    encrypted connection.  Especially, messages for which the policy is
>    to send them only encrypted (e.g., DATA messages using an encrypted
>    transport mode) MUST be sent only using the encrypted connection.
>    Note that a policy MUST NOT prevent sending un-encrypted UPDATE
>    messages used for re-establishing the encrypted connection, since
>    that would prevent recovering from failed encrypted connections.

That proposed change looks good to me, as the immediately following sentence in Section 5 points back to Section 3.2 for the re-negotiation, from which the reader will proceed to Section 3.3 on handling the error that occurs if the re-negotiation fails to propose an encrypted HIP transport.

Please wait to hear from Ralph (AD) before submitting a revised draft, as an RFC Editor Note may suffice to make this change.

Thanks,
--David

> -----Original Message-----
> From: Ari Keränen [mailto:[email-masked]]
> Sent: Monday, February 28, 2011 8:11 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Hipsec] OPS-DIE review of draft-ietf-hip-over-hip-05
> 
> Hi David,
> 
> Thanks for the review!
> 
> On Feb 25, 2011, at 9:07 PM, <[email-masked]> <[email-masked]> wrote:
> [...]
> > Summary: This draft is basically ready for publication, but has nits that should be fixed before
> publication.
> [...]
> > I have one recommendation for change - this draft is somewhat inconsistent about support for a HIP
> node policy that requires use of an encrypted transport for HIP signaling.  Section 3.3 provides an
> essential building block, the error signaling mechanism to indicate that an encrypted transport is
> required and none was proposed.  On the other hand, Section 5 is unclear with respect to this class of
> policy in that it strongly recommends (SHOULD) fallback to a non-encrypted HIP connection but requires
> (MUST) that "messages that are intended to be sent only encrypted" not be sent unencrypted.  If the
> "messages that are intended to be sent only encrypted" are all HIP messages after the base exchange,
> these two requirements appear to be in conflict.
> 
> That's a valid point. A policy that would prevent sending the re-establishing UPDATEs un-encrypted
> after a failed encrypted connection would be unreasonable since then one could never re-establish such
> a connection or even close it properly. This is already explicit for the receiving end (MUST accept
> without encryption), but making it explicit also for the sender makes sense.
> 
> The first SHOULD refers to the fact that one may also do something else than re-establish the
> connection (e.g., close it).
> 
> > I suggest adding a short explanation to Section 5 of what would be reasonable vs. unreasonable
> policy for "messages that are intended to be sent only encrypted", and how to use the Section 3.3
> error report when a failed encrypted connection is recovered by attempting to fall back to an
> unencrypted connection when HIP node policy requires encryption of all signaling after the base
> exchange.
> 
> 
> If we explicitly prevent a policy that would not allow un-encrypted connection re-establisihing
> UPDATEs, I think we have this fixed, and we would not need to use error messages for informing about
> this. I would change the text in section 5 into (added the last sentence and changed the second-to-
> last one):
> 
>    [...] If encryption was
>    previously used, hosts SHOULD send outside of the encrypted
>    connection only HIP messages that are used to re-establish the
>    encrypted connection.  Especially, messages for which the policy is
>    to send them only encrypted (e.g., DATA messages using an encrypted
>    transport mode) MUST be sent only using the encrypted connection.
>    Note that a policy MUST NOT prevent sending un-encrypted UPDATE
>    messages used for re-establishing the encrypted connection, since
>    that would prevent recovering from failed encrypted connections.
> 
> 
> Cheers,
> Ari

---

From: Ari Keränen <[email-masked]>
Date: Tue, 1 Mar 2011 17:43:26 +0200

Hi David,

> That proposed change looks good to me, as the immediately following sentence in Section 5 points back to Section 3.2 for the re-negotiation, from which the reader will proceed to Section 3.3 on han…

Thanks! I'll use that text in the next revision.

> Please wait to hear from Ralph (AD) before submitting a revised draft, as an RFC Editor Note may suffice to make this change.

OK, although there will be at least one more change due to Lars' review, so it probably makes sense to submit a revised version after I've fixed all the comments and discusses.

Cheers,
Ari