[Hipsec-rg] comments on draft-heer-hip-middle-auth-01

[samu.varjonen at helsinki.fi (Varjonen Samu)]

Hi,

Sorry this took so long but I had "few" comments :)

Joakim Koskela wrote:
 > On Wednesday 24 September 2008 12:43:21 Ren? Hummen wrote:
 >> Hi,
 >>
 >>> As a matter of procedure, there are a few directions the RG can take
 >>> with respect to this or any draft within scope of our charter:
 >>> 1) agree to take on the draft as a RG item and try to publish it as 
a RG
 >>> draft, according to the process being defined in
 >>> http://tools.ietf.org/id/draft-irtf-rfcs-01.txt
 >>> 2) recommend to the HIP WG that they take the draft
 >>> 3) decline to take the draft and recommend to the authors to publish it
 >>> as an independent submission
 >>>
 >>> If we agree to 1), we will need to come to some RG consensus on the
 >>> draft and willingness to work on it through the publication process.
 >>>
 >>> Comments?
 >> I recommend it as a WG draft as the security enhancements described in
 >> there are necessary for providing secure middlebox functions like 
the HIP
 >> relay, which e.g. is used in the NAT traversal draft.
 >>
 >
 > Hi,
 >
 > +1 for the same reasons.
 >
 > br,
 > Joakim Koskela

Ok here are the comments, some might sound like nitpicks but in my 
opinion they make the draft more readable/understandable and some of the 
  comments overlap each other in various degrees.

1. References to BASE, ESP, MM ... have to be changed to RFCs as we have 
them.

2. In Abstract HIP is referenced to RFC2119 which is the usage of 
keywords RFC

3. Section 1.1. third paragraph in the middle ""fake" ESP packets with 
valid ESP numbers" probably should be SPI numbers

4. Section 2.1. end of second paragraph. "end-hosts sign with public-key 
(PK) signatures". Would it be better if it was "end-hosts integrity 
protect with PK signatures". Because I do not sign with a signature I 
sign with my private-key.

5. Next paragraph, "The middlebox adds an ECHO_REQUEST_M
    parameter to the first HIP control packet that contains a nonce". 
This was probably meant as "The middlebox add an E_RQ_M to the first HIP 
control packet that contains a D-H nonce.". Hmm, why not just say R1 
control packet?

6. Section 2.1.1. "E_RQ_M parameters to the the R1, I2 and to any UPDATE 
packet". First there is a double "the". Secondly, for example in the 
UPDATE procedure (3-way) using E_RQ_M in the last UDPATE would result 
into extra UPDATE just for the middlebox. The other end would not know 
what to do with the UPDATE, mbox could just drop the UPDATE and not send 
it through if it is just an extra UPDATE with E_R_M with no other 
content. This is relevant also to 2.1.3. first paragraph and 2.2.2. 
RESPONSE RULE mentions this extra packet also. In cases where there is 
three packets, like mobility, so why add it to the last, you can but 
there is no point. Should it be clarified that instead of any UDPATE 
that E_RQ_M/P_M would be inserted into the first UPDATE going to proper 
directions according to which is authenticated, Initiator or Responder.

7. 2.1.1. first paragraph "maximum of 32 bytes". Where does this limit 
come? it should be mentioned also/or in the parameter definition 2.5.1.

8. Reference to R'FC2460 for the 1280 minimum MTU for IPv6 section 2.1.1. 
first paragraph.

9. section 2.1.1. end of second paragraph "MAY also rewrite the 
ECHO_REQUEST_UNSIGNED parameter as specified in [I-D.ietf-hip-base]" 
this is written in RFC 5201 like " It is possible that middleboxes add 
ECHO_REQUEST_UNSIGNED parameters in HIP packets passing by". If I read 
this I understand it like this, the middlebox ADDS E_RQ_UNSIGNED to the 
packets and does not rewrite/modify existing parameters. Clarification 
what is meant, please.

10. Next paragraph, request comes before response, so the they 
(parameters) should be listed in such order. Matter of opinion and mine 
is that they should be listed in order of use.

11. Section 2.1.2. first paragraph, middlebox expects to see E_R_M to 
E_RQ_M in subsequent packet. I understand this like, middlebox expects 
to see E_R_M in some following packet. I think it should say in the next 
control packet. Because middlebox may drop the traffic when E_RQ_M is 
missing.

12. All the parameters could be combined into two parameters, like I 
have presented in earlier mails commenting this draft sent to this list. 
Was there some reason why this is not done? I do not remember this been 
explained. If the decision is to keep two parameters (request/response 
and puzzle/solution as separate parameters) then why not remove the 
opaque from the puzzle. It is mentioned as inadequate in some 
situations, so why not use the request/response pair always when needed 
and not the opaque in puzzle/solution.

13. 2.1.3. second paragraph "must solve", should this be "MUST solve" 
because if you do not you might face a stop to your traffic

14. Next paragraph, how does the middlebox notice it is under attack or 
just under heavy load. Puzzle could also be used as a load "alleviating" 
solution where it could slow the creation of new connections and hoping 
that in the time it takes to solve the puzzle someone goes away and 
gives the bandwidth to the new one. This might be just a mindfart :)

15. Figure numbering Starts from 2 and text starts from fig 1 and some 
of the references to figs seem to be out of sync with the numbering of 
the figs. Check all of them because some seem to point correctly and 
others not.

16. It would be cleaner and easier to read if the labels of fig where 
like this "Figure 2: Middlebox authentication of a HIP BEX" and not the 
way it is now, "figure 2" below fig and explanation on top of fig.

17. Section 2.2.2. it says NATted environments are left to future 
revisions of this draft. Should it be explained in the NAT draft 
instead. At least on the list it is said that this draft is already used 
in the NAT draft... see start of this mail.

18. 2.2.2. end of second paragraph "in figure 3 I)" is the "I)" a left 
over from earlier versions or does it point to the two middlebox fig?

19. Clearly separate the RULE from other text.

20. Hey, now it says that with updates the E_RQ_M must be in the next 
packet see this mail 11.

21. 2.2.2. reference to a fig when mentioning middlebox 1. There is two 
figs with middlebox 1. Why the other one says middlebox 1 there is no 
other middleboxes so it could be just middlebox.

22. 2.2.2. second to last paragraph, how does the middlebox know if 
something is missing if it has not seen U1 message.

23. 2.2.2. last paragraph seems like repetition mentioned already in 
2.1.2. last paragraph.

24. 2.2.3. "Figure 4 I) and II)". I) is a repetition of the last fig. Or 
is the last fig unnecessary... Move II) to later where the text talks 
about middlebox 2.

25. in fig 4 (currently) II) U1 passes the middlebox 2 is this a case 
where the U1 is UPDATE LOCATOR with one locator with preferred bit set 
leading to U2 coming through different route or is this something 
related to asymmetric routes which usage, to my knowledge, is not defined?

26. Fig 4. (currently) in the second last packet ER1, ans SM1 resurface 
when they should be ER4 and SM4.

27. 2.2.4. Is it not sufficient to say that use HOST_ID always when the 
locator pair is unused?
With BEX HOST_IDs are already in the packets and with UPDATE only 
relevant case is the mobility update, covered by "unused locators" 
sentence. Otherwise we know the HI already. I cannot figure a case where 
you could not know HIs without the changing locators. Clarification to 
the why.

28. 2.3. "sender of BEX" ... sender?. It is initiator if only initiator 
is authenticated and responder if responder is autenticated or both.

28. 2.3. Other reasons should be covered somehow. Because it can be that 
credentials delivered by CERT parameter are not sufficient... so, other 
reasons depending on the policies of the middlebox maintainers can lead 
to failure signaling and it should be mentioned.

29. In the parameters 2.5.1. and 2.5.2. explain more clearly the length 
of the opaque data. Currently it needs to be len mod 32 == 0 bits 
otherwise padding is needed. Only related value to the length is the 32 
byte maximum mentioned far away in 2.1.1.

30. 4.1.1. End of the first paragraph, in the current version attacker 
is able to replay closing of the channel, because it is stated that its 
protection is future work.

31. 5. second paragraph, responder can send the puzzle to the initiator 
as I have shown in earlier mails commenting this draft. But it results 
into more packets sent on the wire.

Keep up the good work, I support this work :) Reasons are the same as 
stated in the earlier mails from Rene and Joakim...

BR,
Samu Varjonen