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

[<[e-mail]>]

Freudian slip - that should be OPS-DI*R* in the subject line ...

Thanks,
--David


> -----Original Message-----
> From: Black, David
> Sent: Friday, February 25, 2011 2:08 PM
> To: [e-mail]; '[e-mail]'
> Cc: Black, David; David Ward; Gonzalo Camarillo; Ralph Droms; [e-mail]
> Subject: OPS-DIE review of draft-ietf-hip-over-hip-05
> 
> I have performed an Operations Directorate review of draft-ietf-hip-over-hip-05
> 
> Operations directorate reviews are solicited primarily to help the area directors improve their
> efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents
> requiring their attention and spend less time on the trouble-free ones.  Improving the documents is
> important, but clearly a secondary purpose.  A third purpose is to broaden the OpsDir reviewers'
> exposure to work going on in other parts of the IETF.
> 
> Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document.
> The reviews may, however, convince individual IESG members to raise concern over a particular document
> requiring further discussion. The reviews, particularly those conducted in last call and earlier, may
> also help the document editors improve their documents.
> 
> --------------
> 
> Summary: This draft is basically ready for publication, but has nits that should be fixed before
> publication.
> 
> HIP is in a related functional space to IPsec, and in both cases IETF protocols are not typical means
> for operation and management (e.g., the IPsec SPD MIB is not widely used for configuring IPsec).  This
> draft specifies minor extensions to HIP in that it defines two additional HIP transports, so it's not
> a reasonable vehicle for a general discussion of HIP operations and management.  As a result, this
> review focuses on operational characteristics of the extensions specified in the draft.
> 
> This draft defines two new fully encrypted transports for HIP signaling messages - ESP and ESP over
> TCP.  The draft includes details on negotiation of these modes as extensions to existing HIP
> signaling, providing support for incremental deployment, a migration path and backwards compatibility.
> While it is probably best to start out with the intended transport (i.e., negotiate it in the HIP base
> exchange), means are also specified to negotiate a transport change later.  An error report is defined
> for use when a HIP node policy requires use of one of these fully encrypted transports, but none is
> offered in negotiation.  Fallback to a non-encrypted transport is specified and recommended (SHOULD)
> when the encrypted transport fails.
> 
> 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.
> 
> 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.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------