Re: Tsvart last call review of draft-ietf-dmm-pmipv6-dlif-04
CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Sat, 02 November 2019 11:45 UTC
Return-Path: <cjbc@it.uc3m.es>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222C5120A90 for <ietf@ietfa.amsl.com>; Sat, 2 Nov 2019 04:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
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 h_jzFyrCUQFm for <ietf@ietfa.amsl.com>; Sat, 2 Nov 2019 04:45:18 -0700 (PDT)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C75121397 for <ietf@ietf.org>; Sat, 2 Nov 2019 04:45:18 -0700 (PDT)
Received: by mail-ed1-x535.google.com with SMTP id l25so9461075edt.6 for <ietf@ietf.org>; Sat, 02 Nov 2019 04:45:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x2BYLZxIxSAdt8ypoIQIORGGOqYh56gnCIuumwf7wWQ=; b=nAV7SZSZaSaY0VhNCfKKiX576UJLCpjr4GQ9tNwhj9/MQ67e/QlXz6rLSA7xlph/UT 3VazXn3X6drNshoFhh6l6XYkNj1ApGKcR8jkJu0kSJl9vGYobK16Sl96NYbNVSUNGNNN aADqe8ubLHwhhMMWmPiSOy7UyYUA93cGwDR6J4cSdV0TkfKYY3p5EmQ7btwPbdTpyPyB Ju1661iNirywP/e26zxX8mUig5TxRb7x0XH2K1HZlOyx9LOgnSTjxArEkwcVFsg9c779 qz4tAC2g2fiBxdrHLI5gi1PQJzKo6xMyEF1FlMiCWadhzrRmIXSmq55mF/lmsBx+LwB/ Lz5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x2BYLZxIxSAdt8ypoIQIORGGOqYh56gnCIuumwf7wWQ=; b=dM2+Q+Hdqv4ZpAh4MPLiT977mFGVndZyuhzl7UgHV5RzCwJD4oO1qSzwNbODsoBITq CJqJWXOIZ1bjJDtgMEE7Wsj8zU1YPE1U2UVSgvWHrX7EuK4cEQw4aO7qUlxAh1DIZ+8l ErQL7SoXp/nRZp0774OpVraa6q2YlAULm7KP1BFDGONb9/cdUG6m56arWoU4Dh5VdNpZ TcQwBQuqbxIrhbvVSWREbo82kKNdLHgg//FKxiL7I5rwUPETnLWvG7xqY8L6qxW4EZ+h 4/cXmfm/+24EGDyd35cMZ48tl+3eK9EEHm1Z6yPQFP857KH3VslZI/VsALEylw6aaSKG AvJg==
X-Gm-Message-State: APjAAAVSGQKikRUWIys0HW9F1MmlLh7ToqXjc5Q3KSNvGHkNo2dTX83q Soa8xww7sNldZGetwTyHGBJkPtDg6SdzvBPzFA/MgQ==
X-Google-Smtp-Source: APXvYqyMg9u+FQN8yjW5bbJ3saZU6ASCWr7o2kNaxodf+eTNakKybBufK71tbhOc+FSoSoSgXhM7756TWX9eRG1A0XI=
X-Received: by 2002:a17:906:448e:: with SMTP id y14mr14770700ejo.136.1572695116290; Sat, 02 Nov 2019 04:45:16 -0700 (PDT)
MIME-Version: 1.0
References: <157108615425.24656.12786623966649135975@ietfa.amsl.com> <CALypLp-sHu4-GM6MqCHwGAGhkp8Bb-0GcTQeB=VMO8yiCi6Z1g@mail.gmail.com>
In-Reply-To: <CALypLp-sHu4-GM6MqCHwGAGhkp8Bb-0GcTQeB=VMO8yiCi6Z1g@mail.gmail.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Sat, 02 Nov 2019 12:45:00 +0100
Message-ID: <CALypLp9WtOSCH-jiWsV_SDedicsoqS_-a2MUWXzwOCN5hG22zQ@mail.gmail.com>
Subject: Re: Tsvart last call review of draft-ietf-dmm-pmipv6-dlif-04
To: Joerg Ott <jo@acm.org>
Cc: tsv-art@ietf.org, draft-ietf-dmm-pmipv6-dlif.all@ietf.org, ietf@ietf.org, dmm <dmm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bf3eb305965b9d43"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/XxaPpNqzjkyXavTXFlP8SnqPbnk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Nov 2019 11:45:27 -0000
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> 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> 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 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
- Tsvart last call review of draft-ietf-dmm-pmipv6-… Joerg Ott via Datatracker
- Re: Tsvart last call review of draft-ietf-dmm-pmi… CARLOS JESUS BERNARDOS CANO
- Re: Tsvart last call review of draft-ietf-dmm-pmi… CARLOS JESUS BERNARDOS CANO
- Re: [Tsv-art] Tsvart last call review of draft-ie… Joerg Ott
- Re: [Tsv-art] Tsvart last call review of draft-ie… Joerg Ott