Re: [MEXT] tsv-dir review Re: Last Call: draft-ietf-mext-flow-binding

[Jari Arkko <[e-mail]>]

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 [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>
>