[Hipsec-rg] Some comments on the draft-melen-hip-nat-mm-00

[miika.komu at hiit.fi (Miika Komu)]

Varjonen Samu wrote:

Hi,

> 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.

your comments will be addressed in the next preversion. I didn't include 
the comments here that I agree with, just the ones that deserve more 
discussion.

> - 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.

Agree that the text is unclear, but isn't it irrevant which interface to 
use for the UPDATE as long as the path works? Remember that this is just 
a scenario, not section describing exact protocol flow diagrams.

And pausing is unnecessary in this particular scenario because it talks 
about simultaneous multihoming.

> - 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.

Some operators provide flat free and the keepalives etc don't really 
cost anything. Hence, I would keep the "may" there.

> . 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?

The term address verification should be used.

> - 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?

No, they are the same states as in RFC5206.

> - 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 5.2 says:

Keepalive are send in periods of 20 seconds, but MUST be omitted if some 
other traffic (e.g.  ESP) occupies the corresponding transport-layer 
connection.

Nothing prevents the HIP daemon from periodically sending ICMPv6 
messages to the tunnel to avoid the STUN based keepalives to get 
triggered. After all, the HIP daemon is just an application running on 
the end-host.

The design team discussed this issue a while ago and the opinion was to 
avoid mentioning this explicitly. You can see this "hidden" information 
in both drafts.

> - 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)?

The abstract says:

The focus of the extensions in this document is on fault-tolerance with 
*symmetric* locator pairs, and load-balancing is also discussed.

To be honest, the asymmetric routes would be just too much to handle for 
now. The draft is still sketchy here and there.

> - Section 4. last paragraph "SPI value value", double value two times in 
> the paragraph.
> 
> - The paragraph needs clarification on the SPI usage.

Where, more explicitly, or everywhere?

>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.
>.. 
> OK, this was all I had to say about the draft on the first read. 
> Hopefully the comments are useful :)

Thanks for comments, I found them very useful!