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
<cjbc@xxxxxxxxxx <mailto:cjbc@xxxxxxxxxx>> 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@xxxxxxxx <mailto:noreply@xxxxxxxx>> 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@xxxxxxxx <mailto:tsv-art@xxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tsv-art
