Re: [DMM] [Tsv-art] Tsvart last call review of draft-ietf-dmm-pmipv6-dlif-04

[Joerg Ott <[e-mail]>]

Hi Carlos,

thanks much, will review shortly, but this will take about a week
and a bit.

Best,
Jörg

On 02.11.19 12:45, CARLOS JESUS BERNARDOS CANO wrote:
> 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 
> <[e-mail] <mailto:[e-mail]>> 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
>     <[e-mail] <mailto:[e-mail]>> 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
>         [e-mail] <mailto:[e-mail]> 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
> 
> 
> _______________________________________________
> Tsv-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art
>