Hi Joerg, We've just posted a new revision addressing your comments.
Thanks, Carlos On Fri, Oct 18, 2019 at 1:24 PM CARLOS JESUS BERNARDOS CANO <[email protected]> wrote: > Thanks a lot Joerg for your very comprehensive review. > > We will carefully look at your comments and provide responses (with > proposals of text changes) in the next few days. I prefer to take some time > to properly address all your points. > > Thanks! > > Carlos > > On Mon, Oct 14, 2019 at 10:49 PM Joerg Ott via Datatracker < > [email protected]> wrote: > >> Reviewer: Joerg Ott >> Review result: Ready with Issues >> >> Hi, >> >> this document has been reviewed as part of the transport area review >> team's >> ongoing effort to review key IETF documents. These comments were written >> primarily for the transport area directors, but are copied to the >> document's >> authors and WG to allow them to address any issues raised and also to the >> IETF >> discussion list for information. >> >> When done at the time of IETF Last Call, the authors should consider this >> review as part of the last-call comments they receive. Please always CC >> [email protected] if you reply to or forward this review. >> >> The draft defines extensions to Proxy Mobile IPv6 to support a more >> distributed >> variant of mobility management. In essence, as a mobile node moves from >> one >> point of attachment (Mobility Anchor and Access Router, MAAR) to the next, >> its routing prefix with the previous MAAR(s) remain(s) and ongoing >> transport >> layer connections remain active and routed indirectly via the previous >> MAAR, >> while new ones will use the present MAAR. The interactions of MAARs are >> managed via a Central Mobility Database (CMD). >> >> The draft is well written and good to follow, describing the protocols and >> extensions clearly. I just have two transport-specific concern and two >> general >> operational issues that require further clarification in the draft. >> >> The transport issues: >> >> T1. Section 3.2. When the CMD acts as a relay for Proxy Binding Updates >> (PBUs) >> and Proxy Binding Acts (PBAs), the CMD may act as a relay of a single PBU >> to >> multiple previous MAARs. If multiple previous MAARs exist, say k, (and >> there >> may be numerous in case of many fast handovers, e.g., with vehicular >> networks), >> the CMD creates k outgoing packets from a single incoming packet. This >> bears >> a certain amplification risk (which may also need to be addressed in the >> security >> considerations section) but it also may lead to packet bursts originated >> from the >> CMD, albeit to different targets. Other protocols start introducing >> pacing to avoid >> bursts on the outgoing link, even if the packets do take different paths >> in the end. >> This may be worthwhile considering. >> >> T2. Also in section 3.2, when relaying PBAs, the CMD serves as a >> transport or >> application endpoint and should have a way to deal with missing responses >> (after all, this is a connectionless protocol on top of an unreliable >> Internet). >> A timeout is only mentioned for aggregation, but even there there the >> timeout >> is not specified, nor is a reference to, e.g., RFC 5213 or so to infer a >> timeout >> used elsewhere. >> >> General issues: >> >> G1. Section 3.2 (again) specifies that responses are aggregated on p.10. >> How >> does response aggregation work? How is error handling done? >> >> Moreover, also on p.10, further below the draft states that if a timer >> expires, >> the requests already received are forwarded. The missing ones come later. >> This seems to contradict aggregation because the originator (the currently >> server MAAR) does not expect more than a single response if it sent out a >> single update. This may thus require updated processing in the MAAR. >> >> G2. Sect. 3.3 suggests that PBAs could be sent straight from the previous >> MAAR >> to the current MAAR. How does this work if security associations are >> supposed >> to be applied? It would seem that, when following the security >> considerations, >> such cases are not covered. At least, this would warrant further >> explanation as >> in this case we suddenly have three involved security associations, which >> would >> also need to be established. >> >> G3. Sect 3.5 discusses deregistration and suggests that this can only be >> done by >> timeout; I understand the rationale but can any risks arise on continued >> resource >> consumption (DoS attacks)? >> >> G4. Sect. 6.: As alluded to above, the security considerations may need >> expanding. >> >> Nits: >> p.12: "information are" -> "information is" >> p.12: "influence on" -> "influence" >> >> > > -- > Special Issue "Beyond 5G Evolution": > https://www.mdpi.com/journal/electronics/special_issues/beyond_5g > > -- Special Issue "Beyond 5G Evolution": https://www.mdpi.com/journal/electronics/special_issues/beyond_5g
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
