Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support
draft-ietf-mext-flow-binding-11
Yes
(Jari Arkko)
No Objection
(Adrian Farrel)
(Alexey Melnikov)
(Dan Romascanu)
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Tim Polk)
Abstain
Note: This ballot was opened for revision 11 and is now closed.
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Alexey Melnikov Former IESG member
(was Discuss)
No Objection
No Objection
(2010-08-16)
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2010-05-06)
Unknown
#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.
Stewart Bryant Former IESG member
(was Discuss)
No Objection
No Objection
(2010-05-05)
Unknown
"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.
Tim Polk Former IESG member
No Objection
No Objection
(2010-05-06)
Unknown
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.
Lars Eggert Former IESG member
(was Discuss)
Abstain
Abstain
(2010-09-08)
Unknown
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 4.2.1.4. Implementations are encouradged to keep binding Nit: s/encouradged/encouraged/ Section 8., paragraph 10: > identifiction format. Nit: s/identifiction/identification/