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

[Joerg Ott <[e-mail]>]

Hi Carlos,

thanks for the update.  I checked and, well, I was hoping for more than
just a few statements in the text reflecting my comments below.
Actually, I was wondering if some of the protocol mechanisms would need
updating to make sure that everything works.

Given that the target of the document is experimental, missing bits may
not be such a big deal, it is for experimentation after all.  Still, for
example, pacing could be spec'ed more precisely.  And I am not sure how
much you guys thought about security associations altogether (I am not
a security person and I don't play one on TV either).  The secdir review
provided other comments.  Are all those taken care of now?

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
>