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

Joerg Ott <ott@in.tum.de> Sun, 03 November 2019 13:48 UTC

Return-Path: <ott@in.tum.de>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8411200EC; Sun, 3 Nov 2019 05:48:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cPaPN1xKdCa; Sun, 3 Nov 2019 05:48:42 -0800 (PST)
Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.in.tum.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07DF3120089; Sun, 3 Nov 2019 05:48:41 -0800 (PST)
Received: by mail.in.tum.de (Postfix, from userid 107) id 4C7C81C0403; Sun, 3 Nov 2019 14:48:39 +0100 (CET)
Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 1F0841C03FD; Sun, 3 Nov 2019 14:48:35 +0100 (CET) (Extended-Queue-bit tech_dnhcj@fff.in.tum.de)
To: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>, Joerg Ott <jo@acm.org>
Cc: draft-ietf-dmm-pmipv6-dlif.all@ietf.org, tsv-art@ietf.org, ietf@ietf.org, dmm <dmm@ietf.org>
References: <157108615425.24656.12786623966649135975@ietfa.amsl.com> <CALypLp-sHu4-GM6MqCHwGAGhkp8Bb-0GcTQeB=VMO8yiCi6Z1g@mail.gmail.com> <CALypLp9WtOSCH-jiWsV_SDedicsoqS_-a2MUWXzwOCN5hG22zQ@mail.gmail.com>
From: Joerg Ott <ott@in.tum.de>
Message-ID: <33569fa4-6bfb-782c-d6a5-2f25b7a4fced@in.tum.de>
Date: Sun, 3 Nov 2019 14:48:35 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CALypLp9WtOSCH-jiWsV_SDedicsoqS_-a2MUWXzwOCN5hG22zQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/ZWlSlS_fQDzrd9SW2MeG8K0ML_M>
Subject: Re: [DMM] [Tsv-art] Tsvart last call review of draft-ietf-dmm-pmipv6-dlif-04
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Nov 2019 13:48:46 -0000

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 
> <cjbc@it.uc3m.es <mailto:cjbc@it.uc3m.es>> 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
>     <noreply@ietf.org <mailto:noreply@ietf.org>> 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
>         tsv-art@ietf.org <mailto:tsv-art@ietf.org> 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
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art
>