Subject: [Hipsec-rg] Some comments on the draft-melen-hip-nat-mm-00
From: samu.varjonen at helsinki.fi (Varjonen Samu)
Date: Tue, 28 Oct 2008 16:58:44 +0200

Hi,

Some comments for the draft-melen-hip-nat-mm-00. I have had some offline 
discussions about some of these issues with Miika Komu. First some 
smaller nitpicks, typos and stuff then to bigger issues.

- In introduction it says "The extensions use combine ICE...". "use" 
seems to be a remnant from some older version and without it the 
sentence makes sence.

- Sections 3.1.1. and 3.1.2. are labeled Make-before-break and 
Break-before-make. To me these are soft and hard handovers and MBB and 
BBM are more like electrical engineering terminology. But the point was 
should these be in the terminology parts with the soft and hard 
handover/handoff explanations.

- In section 3.1.1. it says
    "First, the phone is already transmitting data over one active 
interface. Then, the phone starts to use the other interface, but only 
after the handover procedure has been completed over the other link." 
This is a bit confusing. There is first the other interface and then 
other link and the other interface is used after handover is completed 
*over* the other link. Too many others. Does this mean that the initial 
UPDATE traverses also through the other link. For me it would make more 
sense in sending the initial UPDATE, with preferred bit saying that move 
to the other link, through the active link. And then pause in traffic 
and address verification and traffic flowing again when the SAs are 
updated. Or is it so that the initial UPDATES are done per interface and 
LOCATORs contain only addresses from that interface. But the main point 
was that it was not totally clear what is happening.

- Section 3.2.1. last paragraph "The hot backup *may* cost more 
because...". I would say it will always cost because you have to send 
keepalives etc. Also in cases where you have to *pay* for the 
connectivity this is not so nice feature, like 3/4G radio links as 
backup links may be not what is wanted because its more expensive in 
monetary means and in power consumption. So should this be corrected to 
*will* and a mention on the 4G stuff as they were already used as example.

- Section 3.3. second paragraph first sentence contains double "the".

. Section 3.3. second paragraph in the end it is mentioned HIP return 
routability. NAT traversal draft does not mention this and RFC 5206 
mentions this ones in section where "address verification" is discussed. 
I know this is the same thing but return routability is taken from MIPv6 
(?). So should this be clarified in section Terminology also?

- Section 4. start about the locator reachability status. RFC 5206 
defines two state for the address, ACTIVE and UNVERIFIED. Would these 
reachability related ones be actually new address states and be 
somewhere between ACTIVE and UNVERIFIED?

- Section 4. monitoring connection and failure detection. I have 
implemented and tested with heartbeats (ICMPv6) sent through the tunnel. 
I think these heartbeats could be used as keepalives for the channel and 
so on. I am not sure does the heartbeat issues inside or outside HAs 
belong to this draft but had to mention this anyway.

- Section 4. at the end where it is discussed about using multiple 
locator pairs at the same time when sending traffic. Should asymmetric 
routing be mentioned and discussed in some detail. It is not mentioned 
in RFC 5206 other than as a experimental curiosity. Hmm, how about 
separating control messages to their own link and data to another 
(mindfart)?

- Section 4. second to the last paragraph "The Old SPI value of the 
ESP_INFO parameter are equal to the current SPI value.". There is only 
on SPI value here that is compared so "is" not "are".

- Same section as above, this paragraph starts to talk about locator 
verification and not reachability tests or connectivity tests or return 
routability. ICE has to be its own term but some uniformity to the HIP 
side.

- This states that the RFC 5206 defines a fault tolerance scenario :)

- Section 4. last paragraph "SPI value value", double value two times in 
the paragraph.

- The paragraph needs clarification on the SPI usage. Is it the ESP_INFO 
old and new? If it is then how can it be set so that it does not mean 
all locators in the following LOCATOR? If it has something to do with 
type 2 locator it should be clarified.

- Section 5.1. fifth bullet Execute *ICE* connectivity tests and 
optionally *HIP* return-routability.

- About the "-" in return-routability. In the draft this term is written 
with it and with not. Choose one way and stick with it.

- 5.1.2. second paragraph "direcly", should be directly.

OK, this was all I had to say about the draft on the first read. 
Hopefully the comments are useful :)

BR,
Samu Varjonen