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

[<[e-mail]>]

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:[e-mail]]
> Sent: Monday, February 28, 2011 8:11 AM
> To: Black, David
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> 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, <[e-mail]> <[e-mail]> 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