Comments to draft-ietf-mobike-design-02.txt
Tero Kivinen <[email protected]>
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
I decided to start reading the protocol draft, by first reading the design draft... that way I can see we keep those two in sync. Here is my comments to the design draft: > 5.2.1 Storing a single or multiple addresses ... > The single IP address approach will not work if both peers happen to > loose their IP address at the same time (due to, say, the failure of > one of the links that both nodes are connected to). It may also > require the IKEv2 window size to be larger than 1, especially if only > direct indications are used. This is because the host needs to be > able to send the IP address change notifications before it can switch > to another address, and depending on the return routability checks, > retransmissions policies etc, it might be hard to make the protocol > such that it works with window size of 1 too. Furthermore, the > single IP address approach does not really benefit much from indirect > indications as the peer receiving these indications might not be able > to fix the situation by itself (e.g., even if a peer receives an ICMP > host unreachable message for the old IP address, it cannot try other > IP addresses, since they are unknown). This paragraph here refers to direct and indirect indications, which are defined only in the next section 5.2.2. > 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection Should we have a section about "connectivity tests using completely new protocol (or exchange)"? The current protocol uses that, but we do not have any reason or rational for that, or even mention that as an option... > 5.4 NAT Traversal ... > There is no way to distinguish the cases where there is NAT along the > path that modifies the header information in packets or whether an > adversary mounts an attack. If NAT is detected in the IKE SA > creation, that should automatically disable the MOBIKE extensions and > use NAT-T. I think the last sentence does not anymore reflect the current status of the working group concensus... Perhaps change to "One option would be that if NAT is deteced ..." Btw perhaps it would be also good to check the issue tracker and see if all decided issues there are reflected in this draft too (i.e. add and paragraph at the end of sections saying that "working group decided to select option xxx", as is already done for some sections). -- [email protected]