Subject: Re: [Tsvwg] AD evaluation comments on draft-ietf-tsvwg-rsvp-l3vpn-01

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 18 May 2009 11:57:27 +0200

On 29 Apr 2009, at 15:18, Magnus Westerlund wrote:

> Hi,
>
> I have done my AD review of "Support for RSVP in Layer 3 VPNs" and  
> have
> some comments.
>
> 1. Section 1: "We note that similar techniques may be applicable to
>   other protocols used for admission control such as NSIS [RFC4080]."
>
> Should this reference be to the QoS NSLP (draft-ietf-nsis-qos-nslp)?

Yes. It should reference the QoS NSLP.
I believe it also worth referencing GIST since of the "similar  
techniques" may potentially have ramifications in GIST (e.g. in the  
Message Routing Information).

So I suggest:
"
We note that similar techniques may be applicable to
other protocols used for admission control such as the combination of  
the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling  [draft- 
ietf-nsis-qos-nslp] and General Internet Signaling Transport (GIST)  
protocol [draft-ietf-nsis-ntlp].
"

>
>
> 2. Section 3.1, second paragraph: "However, MPLS VPN PE routers
> (especially those separated by Option-B ASBRs)"
>
> Use of ASBR without reference or expansion.

Will be fixed.

>
>
> 3. Section 5.1, first paragraph: There is talk about "CAC". This
> abbreviation is not expanded. Also, it is really approproate, why not
> use admission control simply?

Agreed. CAC will be replaced with admission control.

>
>
> 4. Section 8.1: "The VPN-
>   IPv4 address in this object is built by combining the IPv4 address
>   from the incoming SESSION with the RD in the BGP advertisement from
>   the egress PE for this prefix and customer."
>
> How is this combining done? Please provide either a reference or a
> normative description of how the combining is to happen and in which
> order.
>
> This definition issue reoccurs also in Section 8.2, 8.6 and 8.7.
>

Section 3 and its subsections already state how the "VPN-x" objects  
are to be built and does so in a specific context of processing a  
given message on a given device. For example in section "3.2 Path  
message processing at Ingress PE", it says:
"
A new  VPN-IPv4 SESSION object is constructed, containing the Route
    Distinguisher (RD) that is part of the VPN-IPv4 route prefix for  
this
    destination, and the IPv4 address from the SESSION. In addition, a
    new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the  
original
    IPv4 address from the incoming SENDER_TEMPLATE plus the RD that is
    used by this PE to advertise that prefix for this customer into the
    VPN.
"

So I propose we simply remove from section 8.1, 8.2, 8.6 and 8.7 the  
statements about how the VPN-IPv4 address is built as this is  
redundant and harder to understand in these sections which do not have  
the context of the message processing.
This will also be more consistent with the document structure whereby  
section 8 is intended to specify Object format/rules and processing is  
described in earlier sections.

> 5. Section 8.1:
> "The protocol ID, flags, and DstPort are identical to the IPv4 and
>   IPv6 SESSION objects."
>
> Please provide a reference to that object.

There is a reference at the beginning of the section, but it can  
improve readability if repeated here. Will do.

>
>
> 6. Section 8.5: "The flags and DSCP are identical to the AGGREGATE- 
> IPv4
> and AGGREGATE-IPv6 SESSION objects."
>
> Reference to where these objects are defined.

There is a reference at the beginning of the section, but it can  
improve readability if repeated here. Will do.

>
>
> 7. Section 8.5: "   The flags, PHB-ID, vDstPort and Extended vDstPort
> are identical to
>   the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE-IPv6 SESSION
>   objects."
>

There is a reference at the beginning of the section, but it can  
improve readability if repeated here. Will do.

>
>
> 8. Section 10: What is the required to implement security functions  
> for
> this RSVP extension?

I don't quite get this question, sorry.
In section 10 we attempted to identify security issues and functions/ 
mechanisms to address those.
Can you expand on what you see missing?

Thanks

Francois

>
>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 May 2009 14:56:17 +0200

Hi,

It seems that most issues are easy to resolve. I will comment on the
ones that seem to require further discussion.

Francois Le Faucheur IMAP skrev:
>> I have done my AD review of "Support for RSVP in Layer 3 VPNs" and have
>> some comments.
>>
> the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling 
> [draft-ietf-nsis-qos-nslp] and General Internet Signaling Transport
> (GIST) protocol [draft-ietf-nsis-ntlp].
> "

Good

> Section 3 and its subsections already state how the "VPN-x" objects are
> to be built and does so in a specific context of processing a given
> message on a given device. For example in section "3.2 Path message
> processing at Ingress PE", it says:
> "
>    Distinguisher (RD) that is part of the VPN-IPv4 route prefix for this
>    new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the original
> statements about how the VPN-IPv4 address is built as this is redundant
> and harder to understand in these sections which do not have the context
> of the message processing.

Well, I think you should have a pointer back to where the address
construction is defined.

>>
>>
>> 8. Section 10: What is the required to implement security functions for
>> this RSVP extension?
> 
> In section 10 we attempted to identify security issues and
> functions/mechanisms to address those.

I don't think it is particular clear what security features that you
need to implement. For example the text says:

[RFC4364] addresses the security considerations of BGP/MPLS VPNs in
   general.  General RSVP security considerations are discussed in
   [RFC2205].  To ensure the integrity of RSVP, the RSVP Authentication
   mechanisms defined in [RFC2747] and [RFC3097] may be used.

It says RSVP authentication "may be used". I don't see that as being
clear and precise on what security functions that are required to
fulfill the IETF's requirement for strong security and ensure
interoperability.

So you identify a number of issues. Some of these have direct
requirements what protection you need to have, some other less so.

So it may be as simple as the "may be used" should read "MUST implement".

Cheers

Magnus Westerlund

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 19 May 2009 22:00:23 +0200

Hi Magnus,

On 18 May 2009, at 14:56, Magnus Westerlund wrote:

>> are
>> redundant

OK. There is already a back pointer at the beginning of the section,  
but I don't have a problem in including the pointer also when  
describing the actual content of this field.

Also, I am realizing that the I-D does not explicitly states that the  
"VPN-IPv4 DestAddress" field contains an address of the VPN-IPv4  
address family as specified in RFC 4364.  We should definitely add  
that (and do the corresponding changes in the other 8.x sections).

> So it may be as simple as the "may be used" should read "MUST  

I see.

So I would propose the following changes :

REPLACE:
" To ensure the integrity of RSVP, the RSVP Authentication
    mechanisms defined in [RFC2747] and [RFC3097] may be used."
BY:
" To ensure the integrity of RSVP, the RSVP Authentication
    mechanisms defined in [RFC2747] and [RFC3097] SHOULD be used. "

REPLACE:
"In order to prevent
    such an attack, a PE should have mechanisms to limit the fraction of
    its processing resources that can be consumed by any one CE or by  
the
    set of CEs of a given customer."
BY:
" In order to prevent
    such an attack, a PE SHOULD support mechanisms to limit the  
fraction of
    its processing resources that can be consumed by any one CE or by  
the
    set of CEs of a given customer."

REPLACE:
"We note that a provider may use
    local policy to limit the amount of resources that can be reserved  
by
    a given customer from a particular PE, and that a policy server  
could
    be used to control the resource usage of a given customer across
    multiple PEs if desired.
"
BY:
"We note that a provider MAY use
    local policy to limit the amount of resources that can be reserved  
by
    a given customer from a particular PE, and that a policy server  
could
    be used to control the resource usage of a given customer across
    multiple PEs if desired. It is RECOMMENDED that an implementation  
of this specification support local policy on the PE to control the  
amount of resources that can be reserved by a given customer/CE".

REPLACE:
" A "control plane" VPN can be
    created across PEs and ASBRs and addresses in this VPN can be used  
to
    signal RSVP sessions for any customers, but these routes MUST NOT be
    advertised to, or made reachable from, any customer."
BY:
REPLACE:
" A "control plane" VPN MAY be
    created across PEs and ASBRs and addresses in this VPN MAY be used  
to
    signal RSVP sessions for any customers, but these routes MUST NOT be
    advertised to, or made reachable from, any customer. An  
implementation of the present document MAY support such operation  
using a "control plane" VPN."

REPLACE:
"Alternatively, ASBRs may implement"
BY:
"Alternatively, ASBRs MAY implement"

REPLACE:
"If a provider wishes to
    mitigate this situation, it would be possible to extend the "control
    protocol VPN" approach described above."
BY:
""If a provider wishes to
    mitigate this situation, the implementation MAY support the "control
    protocol VPN" approach described above."

Francois

> Fdrvgatan 6                | Mobile +46 73 0949079

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 May 2009 10:55:38 +0200

Hi,

Okay, that makes it clearer what should be done. Lets see what the
secdir will say about this.

Cheers

Magnus

Francois Le Faucheur IMAP skrev:
> OK. There is already a back pointer at the beginning of the section, but
> I don't have a problem in including the pointer also when describing the
> actual content of this field.
> 
> "VPN-IPv4 DestAddress" field contains an address of the VPN-IPv4 address
> family as specified in RFC 4364.  We should definitely add that (and do
> the corresponding changes in the other 8.x sections).
> 
>>
>>
>>>>
>>>>
>    its processing resources that can be consumed by any one CE or by the
>    such an attack, a PE SHOULD support mechanisms to limit the fraction of
>    its processing resources that can be consumed by any one CE or by the
>    local policy to limit the amount of resources that can be reserved by
>    a given customer from a particular PE, and that a policy server could
>    local policy to limit the amount of resources that can be reserved by
>    a given customer from a particular PE, and that a policy server could
>    multiple PEs if desired. It is RECOMMENDED that an implementation of
> this specification support local policy on the PE to control the amount
> of resources that can be reserved by a given customer/CE".
> 
> 
> REPLACE:
>    created across PEs and ASBRs and addresses in this VPN can be used to
>    created across PEs and ASBRs and addresses in this VPN MAY be used to
> implementation of the present document MAY support such operation using
> a "control plane" VPN."
> 
> 
> REPLACE:

-- 

Magnus Westerlund