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
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
