Subject: [Tsvwg] Comments on draft-ietf-tsvwg-mlpp-that-works-02.txt

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 24 Aug 2005 19:04:40 -0400

The following are comments we have based on reviewing
   draft-ietf-tsvwg-mlpp-that-works-02.txt

The review is done based on this draft being an Informational track draft
in TSVWG that describe one possible solution.  Please advise if this
document needs to be reviewed for a different purpose, as comments
may be different.

1. In Section 1.6 on Page 10-11.  Adding to what is indicated in the second 
paragraph:
     In military networks, admission control is also needed to ensure that 
parts of the
     core network does not get congested due to unexpected network failure 
for various
     reasons.  Should significant portions of the core network be made 
in-operable, the
     remaining working portions of the network must not be overloaded.
2. In Section 2 on Page 12 and 13.  There seems to be some contradiction 
between
     "In a voice/video-on-IP network, call control is completely divorced 
from the data
     plane: It is possible for a telephone instrument in the United States 
to have a
     Swedish telephone number if that is where its SIP proxy happens to be, 
..."
     AND
     "Is there bandwidth available to support the call?" and "Does the call 
actually work?"
     bullets in the same section.
     Given the bullet points, is the call control completely divorced from 
the data plane?
     Some additional explanation may help.
3. In Section 2.1 on Page 14.  The paragraph starting with "This informs 
both the
     use of DSCPs by the callee ..." implies that a different DSCP value is 
assigned for
     each precedence level, exposing security risks: identifies flow 
importance and
     allows focused attacks on the most important flow(s).  Some additional 
explanation
     here may help.
4. In Section 2.1 at top of Page 15.  "Figure X" should be "Figure 2"?
5. In Section 2.2 on Page 16.  At end of first paragraph.  How does RFC 
2998 relates
     to this paragraph?  Or to "this", what ever "this" refers to.  Some 
clarification may help.
6. In Section 2.3.1 on Page 18.  Discussion of RSVP will setup N 
reservations for N senders.
     Isn't RSVP Reservation Receiver based?  Not Sender based?  May be more 
explanation
     here will help.
7. In Section 2.3.1 on Page 18.  Discussion of RSVP Refresh Period being 30 
seconds by
     default and may be longer as appropriate.  It may be good to indicate 
that the RSVP
     Reservation state "converge" time may depend on the refresh 
period.  Hence the notion
     of "appropriate" may make the Refresh Period Shorter or Longer.  Some 
explanation
     here may help.
8. In Section 2.3.4 on Page 21.  This section describe the use of the RSVP 
DCLASS
     object in the RSVP PATH messages.
     Text from RFC 2996 Section 1.1 on Page 2:

    If the packets for this RSVP request are to be marked upstream,
    information about the DSCP(s) to use must be conveyed from the RSVP-
    aware network element to the upstream marking point.  This
    information is conveyed with the DCLASS object.  To do this, the
    network element adds a DCLASS object containing one or more DSCPs
    corresponding to the behavior aggregate, to the RESV message.  The
    RESV message is then sent upstream towards the RSVP sender.

     indicated the DCLASS is used with RSVP RESV messages.
     More explanation will be needed for the difference in usage as 
indicated in RFC 2996.
9. In Section 2.3.3 on Page 20.  The statement: "Encapsulating an RSVP 
packet inside    an encrypted packet for security purposes without copying 
or conveying the RSVP
     indicators in the outside IP packet header would make RSVP inoperable 
while in
     this form of a tunnel.  [RFC2207] describes how to modify an IPsec 
packet header to
     allow for RSVP awaremess by nodes ..." confuses me.
     First, RFC 2207 describes changes to RSVP (or IntServ to be more 
exact) Filter_Spec
     to allow the packet flow described by RSVP to use IPsec.
     This does not indicate that the RSVP messages themselves are protected 
by IPsec,
      hence the confusion.  And the question of how the issue indicated by 
the initial
      sentence is resolved?

      RFC 2207 also describes the additional changes to RSVP that is needed.
      Further more, from the Security Section of RFC 2207:

    The same considerations stated in [RFC 2205], [RFC 1826], and [RFC
    1827] apply to the extensions described in this note.  There are two
    additional issue related to these extensions.

    First, the vDstPort mechanism represents another data element about
    the IP Flow that might be available to an adversary.  Such data might
    be useful to an adversary engaging in traffic analysis by monitoring
    not only the data packets of the IP Flow but also the RSVP control
    messages associated with that Flow.  Protection against traffic
    analysis attacks is outside the scope of this mechanism.  One
    possible approach to precluding such attacks would be deployment and
    use of appropriate link-layer confidentiality mechansisms, such as
    encryption.

    Secondly, Changes in SPI values for a given flow will affect RSVP
    flows and reservations.  Changes will happen whenever that flow
    changes its Security Association.  Such changes will occur when a
    flow is rekeyed (i.e. to use a new key). Rekeying intervals are
    typically set based on traffic levels, key size, threat environment,
    and crypto algorithm in use.  When an SPI change occurs it will, in
    most cases, be necessary to update (send) the corresponding
    SENDER_TEMPLATEs and FILTER_SPECs.  IPSEC implementations, RSVP
    applications, and RSVP end-station implementations will need to take
    the possibility of changes of SPI into account to ensure proper
    reservation behavior.  This issue is likely to be a tolerable, since
    rekeying intervals are under the control of local administrators.

    indicates additional considerations that needs to addressed, as
    they may increase some forms of complexity.
10. On the point of security, RSVP uses MD5 as the security mechanism
     for the RSVP-hop by RSVP-hop RSVP messages.  With MD5 identified
     as a weak security mechanism, does this post any concerns?
     If this does post security concerns, how may this be resolved?
Thank you in advance for any response to and additional discussions of the 
above comments.
We have tried to be clear with each comment, but please let us know if any 
clarifications to the comments are needed.
-- Kwok Ho Chan, Jozef Babiarz, Corey Alexander --

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 25 Aug 2005 11:48:33 -0500

Kwok Ho , Jozef , Corey

I'll answer some of these comments in-line

>document needs to be reviewed for a different purpose, as comments

I believe this document is being considered on the BCP status

>1. In Section 1.6 on Page 10-11.  Adding to what is indicated in the 
>second paragraph:

the way I read the comment above, you are asking for a means to prevent 
congestion, and I'm not sure that should be a goal. I believe that is 
unavoidable if there is enough traffic. This document deals with real-time 
flows that are required to operate even when there is congestion - where 
packet latency needs to be controlled per flow (or as an aggregate of flows).

As a simple example, take my home braodband connection, I can use all 
available bandwidth surfing, yet when I have a voice call, I want its 
packets to take precedence over the surfing traffic, but not stop the 
surfing traffic from all remaining available bandwidth during that call.

>     Swedish telephone number if that is where its SIP proxy happens to 
> be, ..."
>     AND
>     "Is there bandwidth available to support the call?" and "Does the 
> call actually work?"

fair comment. Without some binding taking place somewhere, right now, there 
is a complete divorce of the two layers (3 from 7).

However, implementing something like RFC 3312 (SIP Preconditions involving 
RSVP), the divorce exists/remains everywhere between the two endpoints - 
but is merged at the two endpoints. Layers 3 and 7 binding takes place in 
the phone.

Further, based on local configuration, that bind of L3 and L7 can occur in 
a Call Server (perhaps a first hop SIP proxy).

>     use of DSCPs by the callee ..." implies that a different DSCP value 
> is assigned for
>     allows focused attacks on the most important flow(s).  Some 
> additional explanation
>     here may help.

I'll get on my co-author again about this  ;-)

>     Isn't RSVP Reservation Receiver based?

no it is not. The reservation is set-up receiver to sender, but only after 
the PATH message has traveled from sender to receiver.

So, to be clear with an example, say - as I illustrated in the appendix - 
Alice calls Bob as askes that a reservation be set-up.

- Bob receives that SIP request, and sends a PATH to Alice. This is not the 
reservation, but establishes the path from Alice to Bob the reservation 
will take based on routing protocols (OSPF, IS-IS and BGP for example).

- Alice receives the PATH from Bob with specific RSVP enabled routers 
identified within this PATH message. This ordered list of routers is put 
into the RESV message that Alice sends towards Bob. This establishes the 
reservation in the Alice-to-Bob direction.

- independent to this is the PATH message from Alice to Bob building the 
path between the two phones. This is based on those same routing protocols, 
and can take a different path from Alice to Bob.

- Once Alices receives Bob's PATH message, he transmits his RESV towards 
Alice to establish the reservation to Alice.

- This combination of one-way reservations enable the two-way nature of 
most phone calls.

In the Appendix, I also detailed how the SIP set-up messages wait for these 
reservations to be established before Bob's phone rings, and the call 
set-up progresses. RFC 3312 articulates this more.

>Not Sender based?  May be more explanation
>     here will help.

see above

>7. In Section 2.3.1 on Page 18.  Discussion of RSVP Refresh Period being 
>30 seconds by

fair, it can be shorter or longer.

>     More explanation will be needed for the difference in usage as 

Are you suggesting our ID differs from 2996?

If so, can you give the difference as an example?

>-- Kwok Ho Chan, Jozef Babiarz, Corey Alexander --

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.