[hiprg] comments on HIP for RF-ID

"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Wed, 14 April 2010 17:00 UTC

From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: 'Pascal Urien' <pascal.urien@gmail.com>
Date: Wed, 14 Apr 2010 10:00:33 -0700
Thread-Topic: comments on HIP for RF-ID
Thread-Index: Acq6O9fOKx+0JAVLSdSTMKmztk1mbAhsgx+Q
Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CE8C2727D@XCH-NW-10V.nw.nos.boeing.com>
References: <Acq6J2P4xWlUrxk8RK+1eGLyYthwow==> <7CC566635CFE364D87DC5803D4712A6C4C1F48A838@XCH-NW-10V.nw.nos.boeing.com> <788eb8c41003021107g525180eaqce4659212236b8ca@mail.gmail.com>
In-Reply-To: <788eb8c41003021107g525180eaqce4659212236b8ca@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "hiprg@irtf.org" <hiprg@irtf.org>
Subject: [hiprg] comments on HIP for RF-ID
Precedence: list

Pascal,

I reviewed your draft again yesterday:
http://tools.ietf.org/html/draft-urien-hip-tag-03

and had some questions and comments for the next revision. As Andrei announced in March, we would like the RG to work on this topic.

- in Section 1.1, can you please describe a little bit more about the motivation for your draft. Why doesn't the existing ONS and EPCIS provide adequate security services?

- in the first bullet under Figure 1, suggest to change "but don't include IP resources" to "but don't require end-to-end IP transport."

- HAT is described as a translator, but it says that HIP messages are encapsulated. Is it a translator or encapsulator?

- in section 1.2, can you succinctly summarize the technical differences between RFC5201-based HIP, and HIP tags?

- in section 1 (perhaps a new section 1.3), can you differentiate HIP-tags from related work, such as BLIND?

- section 2, it is not clear who initiates the communication. It describes that actions start when a reader detects the tag, but the I1-T is sent from the tag.

- section 2, it may help to either specify the encapsulation of the HIP messages (in a non-IP transport) or else state that it is out of scope

- what is used for signature of these initial packets?

- in section 2.2, can you explicitly state what values are used for HIT-I and HIT-R?

- in section 2.3, it would help to clarify exactly what is the security technique used to prevent the reader from interposing itself as a man-in-the-middle in this exchange. what are the shared secrets that allow the security keys to be known only by the portal and tag?

- in section 2.4, R2-T is listed as optional, but this is a required packet in the base exchange. If ESP is being used, is this R2-T required? Can you clarify somewhere in the draft an example of a non-ESP use case?

- in section 3.1, it states that checksum is null but later examples show it being non-null-- please clarify. Do you mean rather that HIP-Tags signs

- section 3.7, can you please clarify with technical details about how the signatures work in your protocol?

- I'd really like to see some material in the Security Considerations section. What is the security model and threat model? What is the risk of compromised shared secret and how mitigated? What is the level of security (protection against brute-force attacks)? Is there any protection against resource-depletion DoS attacks?

- (minor nit)-- section 8.1, the title for the normative reference is wrong

[hiprg] agenda requests Henderson, Thomas R
Re: [hiprg] agenda requests Pascal Urien
[hiprg] comments on HIP for RF-ID Henderson, Thomas R