Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support
Note: This ballot was opened for revision 11 and is now closed.
(Jari Arkko) Yes
(Ron Bonica) No Objection
(Stewart Bryant) (was Discuss) No Objection
"The receiver MUST quietly ignore and skip over the option" I think that the authors mean silently. The abbreviations BU, HA, CN, MN and MAP should be expanded on first use.
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
(Adrian Farrel) (was Discuss) No Objection
(Russ Housley) No Objection
(Alexey Melnikov) (was Discuss) No Objection
(Tim Polk) No Objection
Comment (2010-05-06 for -** No value found for 'p.get_dochistory.rev' **)
I support Sean's discuss issue: The Security Considerations section should include explicit pointers to the Security Considerations sections in RFCs 3775, 3963, and 5555.
(Dan Romascanu) No Objection
(Peter Saint-Andre) No Objection
(Robert Sparks) No Objection
(Sean Turner) (was Discuss) No Objection
#1) I would like the authors to consider adding the following text (from Tina Tsou's SECDIR review) to the security considerations: This specification does not open up new fundamental lines of attack on communications between the MN and its correspondent nodes. However, it allows attacks of a finer granularity than those on the basic binding update. For instance, the attacker can divert or replicate flows of special interest to the attacker to an address of the attacker's choosing, if the attacker is able to impersonate the MN or modify a binding update sent by the MN. Hence it becomes doubly critical that authentication and integrity services are applied to binding updates.
(Lars Eggert) (was Discuss) Abstain
Section 2., paragraph 5: > Note that per-packet load balancing may have negative impacts on TCP > congestion avoidance mechanisms as it is desirable to maintain order > between packets belonging to the same TCP connection. This behaviour > is specified in [RFC2702]. Other negative impacts are also foreseen > for other types of real time connections due to the potential > variations in round trip time between packets. Moreover, per-packet > load-balancing will negatively affect traffic with anti-replay > protection mechanisms. Hence, per-packet load balancing is not > envisioned in this specification. It'd be even stronger here and say that packet-based load balancing causes severe performance issues for almost all kinds of Internet transports and applications, and that this specification SHOULD NOT be used in this way. Section 3., paragraph 2: > Flow: A flow is a sequence of packets for which the MN desires > special handling either by the Home Agent (HA), the Corresponding > Node (CN) or the (Mobility Anchor Point) MAP. Isn't a flow for the purposes of this specification something more restrictive, i.e., a sequence of packets *that can be matched by a common traffic selector*? Section 3., paragraph 5: > Flow Identifier: A flow identifier uniquely identifies a flow > binding associated with a mobile node. It is generated by a > mobile node and is cached in the table of flow binding entries > maintained by the MN, HA, CN or MAP. "uniquely identifies a flow" in what scope? I assume not Internet-wide. Section 4.2., paragraph 9: > The Flow Identifier field is a 16-bit unsigned integer that > includes the unique identifier for the flow binding. This > field is used to refer to an existing flow binding or to create > a new flow binding. The value of this field is set by the > mobile node. FID = 0 is reserved and MUST NOT be used. This means a node can have at most 64K flow bindings. It's a large number, but not so large that I can see it being sufficient in all future corner cases. Section 5.3.3., paragraph 2: > and one or mobe Binding Identifier mobility options identifying Nit: s/mobe/more/ Section 6., paragraph 2: > Section 18.104.22.168. Implementations are encouradged to keep binding Nit: s/encouradged/encouraged/ Section 8., paragraph 10: > identifiction format. Nit: s/identifiction/identification/