Thank you for your review, Allison!
Authors, please take these comments into account.
My understanding about the traffic selector format is that the
previously approved document is the only one that we intend to have in
the standards track at the moment, and that should be referenced from
this document. (While allowing a registry to remain and the possibility
of other formats retained, of course.)
Jari
Allison Mankin kirjoitti:
Review for the Transport Directorate
draft-ietf-mext-flow-bindings-06.txt
2010-05-06
Allison Mankin
I've reviewed this document as part of the transport area
directorate'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 for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they have
received. Please always CC tsv-dir(_at_)ietf(_dot_)org if you reply to or
forward this review.
This draft is on the right track but has open issues, described in
the review.
Overview -
It's interesting that flow routing keeps appearing in disparate
Internet protocols. In this one, mobile nodes bind diverse CoAs
to flows based on traffic selector specs. The draft is carefully
generic and gives no use cases, sample policies or traffic selectors.
It has a helpful example, but it is abstract. I do find three
drafts that make use of flow bindings and give some picture of
how they might be used.
The WG has an approved standards track document specifying a binary
traffic selector. The present draft doesn't reference it even
informationally - is that purposeful for neutrality? The other two
are individual submissions. One specifies a traffic selector for 3GPP.
The final one sets out to massively extend flow binding options so that
they can originate from the home agent, not only from the mobile node.
This final draft presents 3G provider scenarios in which the HA
creates, deletes or modifies flow bindings or uses flow binding
actions, to accomplish goals such as enforcing a usage cap or ensuring
that an MN uses the provider's link even when a non-provider wifi may
also be available. I bring up the two individual submissions with 3G
themes without any information about how they are viewed in the WG or
about how they'll fare in the IETF. They do reveal ways that
draft-ietf-mext-flow-bindings can be read and thus they place it
in an architectural context.
Comments -
Lifetime -
What should be done with the Lifetime field on BUs carrying flow
binding options? Is it a meaningful field? Section 4.3 doesn't
mention Lifetime as information that is maintained with flow bindings.
If you do intend that both systems are available, time-based deletion,
and non-refresh-based deletion, it needs stating (and it raises the
complexity). Suggested action: write some guidance about this.
Design Limits -
4.2.1.4. Traffic Selector sub-option
TS Format
An 8-bit unsigned integer indicating the Traffic Selector Format.
Value "0" is reserved and SHOULD NOT be used.
This seems too small a space for traffic selector format identification.
It's been my experience that any two groups that want to classify traffic
specify at 3-4 (at least) similar but incompatible traffic selector
formats. Instead of reserving the 0 value with a SHOULD NOT, why don't
you reserve it with a MUST NOT, and conceive that in a future standards
document it could be used as an extension bit to signal an expanded space?
Section 5.2
The requirement that there be only one flow summary option in a
binding update but that all FIDs be refreshed in that binding update,
means that the upper limit for flow bindings for a MN at any one time
is 128 (the length field in the option will only count this many 16
bit FIDs). This seems limiting? What if an application decides to
use flow bindings in an innovative way that can make use of lots more?
Suggested action: discuss why it was decided that there could be only
one flow summary option. Does the WG believe that a maximum of 128
flow bindings is a good tradeoff?
Priority -
The draft illustrates specific uses of BID-PRI and FID-PRI. The draft
is open enough that these priorities could also be used more
classically as traffic priorities. I think this draft should pat
itself on the back for describing a simple robust use of the PRI
fields. My sense is that the dynamics of mobility and the interaction
of the two sets of priorities lend themselves to complications,
including priority inversion. Suggested action: write guidance that
simple use of the PRI fields is envisioned to be most robust.
Section 4.2
FID-PRI MUST be unique to each of the flows pertaining to
a given MN.
This sentence should be more precise. I think it means that there
should be no duplication of FID-PRIs, but I'm not sure, and I'm not
sure why it says "pertaining to a given MN"
Section 5.1.1
The ordered list of BIDs is used to determine how to forward a packet
to a given mobile node when the packet does not match any of the flow
binding entries defined in Section 4.3. A packet that does not match
any of the flow binding entries SHOULD be forwarded to the care-of
address identified by the BID with the highest priority i.e., lowest
BID-PRI value.
What if there are two BID-PRIs with the same lowest value? This also
plays into the question of avoiding (intentional or otherwise) packet-based
load-sharing. Do you want to rule out duplicate BID-PRIs?
Security -
Here is the entire meat of the Security Considerations (Section 7):
Since the flow identification mobility option is part of
the mobility header, it uses the same security as the Binding Update,
whether it is sent to a mobility agent, or to a correspondent node.
Flow bindings have the security issues of MCoA, which go far beyond
the original Binding Update security issues. RFC 5648 has a very
detailed discussion. Suggested action: this draft needs to say that
its security considerations derive from those of RFC 5648, as well as
those of the Binding Update. Also, do flow bindings make things
harder for IPSec than MCoAs do (as described in RFC 5648, Section
9.3.2)?
Beyond the RFC 5648 security considerations, flow bindings introduce
new vulnerabilities, because added to the redirection attacks
described in RFC 5648, with flow bindings a malicious MN has Discard,
Forward and traffic selectors as tools to use against victims. The
Forward Action even implements making copies of traffic onto multiple
CoAs - a malicious MN could set up a kind of wiretap.
Overall suggested action: produce some more analysis of flow binding
specific security risks.
Miscellaneous -
Section 4.2.1. Flow Identifications Sub-Options Definition
Sub-opt Type
8-bit unsigned integer indicating the sub-option Type. When
processing a flow identification mobility option containing an
option for which the sub-option Type value is not recognized by
the receiver, the receiver MUST quietly ignore and skip over
the option, correctly handling any remaining sub-options in the
^sub-option
same option.
Error in text: skip over the sub-option, not skip the option
Section 8. IANA Considerations
3) New "Flow Identification Mobility Option Status codes"
126-250 unassigned and available for reject codes to be
allocated via Standards Action or IESG Approval as per
[RFC5226]
Substantive typo, 126 should be 136.
Editorial -
Section 2
care-of address. The mobile node / mobile router assembles the flow
binding request based local policies, link characteristics and the
s/based local/based on local/
load-balancing will negatively affect traffic with anti-reply
s/anti-reply/anti-replay/
Section 4.2
FID-PRI
This is an 8-bit unsigned priority field to indicate the
priority of a particular option. This field is needed in cases
where two different flow descriptions in two different options
overlap. The priority field decides which policy should be in
those cases.
Is the word 'executed' missing between 'be' and 'in'?
Section 4.3
Any UDP traffic that does not match any of the earlier entries will
match the forth rule and according to the Action indicated, it will
s/forth/fourth/
Section 6
options, which allows them to refer to already registered care-off
addresses and flows, while registering new ones in subsequent binding
s/care-off/care-of/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf