On Mar 7, 2011, at 12:22 PM, Richard L. Barnes wrote: > Zhenkai, > > Thanks for following up. With regard to security/NATs: These could be > relevant in your comparison, since I would think that different proposals > would have different properties along these lines. For example, it seems > like the degree of trust placed in the HA/rendezvous function varies quite a > bit, as does the safety of the binding update mechanism (i.e., its ability to > prevent an attacker from using spoofed updates to steal traffic). > > --Richard
first, I agree that some of the solutions have different properties regarding security/NAT handling. However note that the solution approaches span a very wide range, hence the relevance degree of security/NAT also varies in a rather wide range (e.g. consider those routing based solutions like Connexions or WINMO). The center issue of mobility support is resolving the location and identity conflict, that every solution must address. We believe it makes a good tradeoff to laser focus on this center issue in a single survey, to keep it within both a well defined focus and also reasonable in size. Lixia > On Mar 7, 2011, at 2:52 AM, Zhenkai Zhu wrote: > >> Thanks for the review. >> We plan to briefly mention link layer and application layer mobility >> approaches. However, security and how they deal with NAT and firewalls are >> separate issues, as this document focuses on how the protocols handle the >> mobility. >> >> For S5.3, we agree that it is "political" and we are willing to remove it. >> >> We'll also address other minor issues you mentioned. >> >> Thanks, >> Zhenkai >> >> On Feb 28, 2011, at 5:45 PM, Richard L. Barnes wrote: >> >>> I am the assigned Gen-ART reviewer for this draft. For background on >>> Gen-ART, please see the FAQ at >>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>> >>> Please wait for direction from your document shepherd >>> or AD before posting a new version of the draft. >>> >>> Document: draft-zhu-mobility-survey-03 >>> Reviewer: Richard Barnes >>> Review Date: 2011-02-28 >>> IETF LC End Date: 2011-03-09 >>> IESG Telechat date: >>> >>> Summary: This draft is almost ready for publication as an Informational >>> RFC. Its discussion of mobility technologies is thorough, but incorrect in >>> some places, and could use some more context. >>> >>> Major issues: >>> >>> General: >>> The document hypothesizes at a few points reasons why IP mobility >>> techniques haven't caught on, without really looking at competitor >>> technologies. In particular, it would be good to spend a little time >>> talking about techniques for mobility at the link layer (such as the 3GPP >>> GTP approach) and at the application layer (SIP REGISTER, XMPP, etc.) >>> >>> General: >>> The document does not discuss security considerations at all. While I'm >>> sure these considerations are discussed in individual documents, it could >>> be helpful to pull up common high-level issues up to this document. >>> >>> General: >>> There's not really any mention here of how these technologies interact NATs >>> and firewalls, both of which could seriously limit their scope. >>> >>> S5.3: >>> I found Section 5.3 duplicative of the previous section and mainly full of >>> political, rather than technical content. Suggest removing. >>> >>> S6.2: >>> TCP is not the only transport-layer protocol! In particular, in voice and >>> video calls, the stuff that goes on for a long time is all UDP, and >>> sessions are managed through a separate signaling protocol, which can be >>> UDP or TCP. All of the discussion of session management (especially for >>> VoIP) should take into account the mobility features that are already >>> available at the application layer (e.g., SIP re-INVITEs), and discuss how >>> these features interact with mobility at other layers. >>> >>> >>> Minor issues: none >>> >>> S4.7: >>> How does NEMO relate to normal use of the routing protocols to detach and >>> reattach a network? A couple of sentences would be helpful here. >>> >>> S4.15: >>> It's not really accurate to say that global HAHA avoids "triangle routing", >>> since it actually does make a triangle. In Figure 6, there's a missing >>> arrow from the CN to the nearby HA, which completes the HA-HA-CN triangle. >>> So it's not that sufficient density avoids triangle routing, it just makes >>> it less of a big deal because the HAs are close to the endpoints. >>> >>> S4.17 P1: >>> I'm a little mystified as to how something is "published in the DNS, and >>> only accessible to the subscriber". Quick clarification would be helpful. >>> >>> >>> >>> Nits/editorial comments: >>> >>> S2, "Locator": >>> It could be helpful to note here that you're talking about *topological* >>> location, not geolocation.s >>> >>> S4.8 P1: >>> The phrase "universally deployed" is used a couple of times in this >>> paragraph; it inspires unnecessary pessimism in the reader :) You might >>> want to re-scope to say that mobility is naturally supported in domains >>> where multicast is enabled. >> > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
