Subject: Re: WG LC: draft-ietf-l3vpn-2547bis-mcast

From: Thomas Morin <[email-masked]>
Date: Thu, 04 Dec 2008 11:48:12 +0100

Hello,

It occurred to me that if/when the PIM assert mechanism is used on PMSI
tunnels, then there is a small issue related to S-PMSIs that does not
seem to be addressed in current specifications : when two PEs happen to
send traffic for a same (S,G) on a P-tunnel, at least one of the PEs
needs to receive the packets sent by the other PE or the PIM Assert
mechanism won't get triggered. But if we are in a situation where the
two PEs have bound an (S,G) to an S-PMSI, then nothing guarantees that
one of them will see the packets from the other.

I would see different ways to resolve this (there might be others):
* impose that PEs join all S-PMSI tunnels for (C-S,C-G) as soon as they
have VRF PIM state for (C-S,C-G), *even* if the RPF interface is not the
MI-PMSI or such an S-PMSI  -- that way we can be sure that the PIM
Assert mechanism will trigger
* or, impose that, when there are multiple S-PMSI signalled for a said
(C-S,C-G), a said PE with state for (C-S,C-G) does not join more than
one of them -- that way even though the PIM assert doesn't trigger, we
avoid duplicates being forwarded down to the CEs
* (or, make it clear that the upstream dataplane check is mandatory and
that the PIM Asserts mechanism is not used on the MI-PMSI)
* (or, don't use S-PMSIs when their are dual-homed sources and PIM-based
C-multicast routing is used)

(the above does not apply if BGP-based C-multicast routing is used)

Thank you,

-Thomas

Danny McPherson :
> 
> Please consider today the start of a 2-week last call
> for draft-ietf-l3vpn-2547bis-mcast, available here:
> 
> http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-07
> 
> Input on this draft's suitability for publication as an
> Internet Standards Track document is solicited, feedback
> ends December 9, 2008.
> 
> Thanks in advance for your feedback!
> 
> Danny & Marshall

---

From: Thomas Morin <[email-masked]>
Date: Thu, 04 Dec 2008 11:03:00 +0000

Hi,

The Security section currently has the following paragraph:

        If one uses the UDP-based protocol for switching to S-PMSI (as
        specified in Section 7.2.1), then by default each PE router MUST
        install packet filters that would result in discarding all UDP
        packets with the destination port 3232 that the PE router
        receives from the CE routers connected to the PE router.
        
This text seems to have been introduced to address security issues such
as CVE-2008-1156.

But, that paragraph would deserve a few improvements :
* worded as it is, some legitimate UDP packets would be blocked (packets
between two hosts in a VPN that would happen to use port 3232 as
destination port)
* what it should say is not what should be blocked, but instead what is
allowed: ie. that a UDP packet for S-PMSI signalling MUST NOT be
processed for a VRF *unless* (a) its destination address is
ALL_PIM_ROUTERS (224.0.0.1) and (b) its TTL is 1 and (c) it was received
on an MI-PMSI 
* it would also make sense to recommend that the source IP address of
the outer GRE header does match exactly the source address of the inner
UDP packet
* the "If one uses the UDP-based protocol for switching to S-PMSI"
should be more precise: the check must be done even if the PE is not
configured to "use" S-PMSIs ; it must be done as soon as the PE is in a
situation where it could process such packets (in practice, as soon as
it is implemented)

Even though UDP S-PMSI switch-over signalling is not the most generally
favored mechanisms for S-PMSI switch-over signalling, I think it would
be better to have this correctly covered.

-Thomas

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 05 Dec 2008 09:51:42 +0800

Hi all,

Three years ago, there were still some doubts about whether there is a need
for the inner label to identify the ingress PE ( see the following threads
).  Now in latest version of draft-ietf-l3vpn-2547bis-mcast, there is
already some corresponding mechanism to addres this issue, that is  "it MUST
carry, as its second label, a label which has been bound to the packet's
ingress PE. This label is an upstream-assigned label that the LSP's root
node has bound to the ingress PE and has distributed via an A-D Route ".  

Using an upstream-assigned label to identify the ingress PE is not a bad
idea. However, we can still use one downstream-assigned label (simpler in
both control plane and data plane) to identify both the MVRF instance and
the ingress PE. Just like the usage of the PW label, the egress PE can
assign different labels for the same mVRF to different PE neighbors. Any
comments?

=====================================================
11.3. Encapsulations Identifying a Distinguished PE

11.3.1. For MP2MP LSP P-tunnels

   As discussed in section 9, if a multicast data packet belongs to a
   Sparse Mode or Single Source Mode multicast group, it is highly
   desirable for the PE that receives the packet from a PMSI to be able
   to determine the identity of the PE that transmitted the data packet
   onto the PMSI.  The encapsulations of the previous sections all
   provide this information, except in one case.  If a PMSI is being
   instantiated by a MP2MP LSP, then the encapsulations discussed so far
   do not allow one to determine the identity of the PE that transmitted
   the packet onto the PMSI.

   Therefore, when a packet that belongs to a Sparse Mode or Single
   Source Mode multicast group is traveling on a MP2MP LSP P-tunnel, it
   MUST carry, as its second label, a label which has been bound to the
   packet's ingress PE.  This label is an upstream-assigned label that
   the LSP's root node has bound to the ingress PE and has distributed
   via an A-D Route (see section 4; precise details of this distribution
   procedure will be included in the next revision of this document).
   This label will appear immediately beneath the labels that are
   discussed in sections 11.1.3 and 11.2.
======================================================

http://www.ietf.org/mail-archive/web/l3vpn/current/msg01369.html

http://www.ietf.org/proceedings/05nov/slides/l3vpn-1/l3vpn-1.ppt 

Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 
> 代表 Thomas Morin
> 发送时间: 2008年12月4日 18:48
> 收件人: L3VPN; Eric Rosen; Rahul Aggarwal
> 主题: Re: WG LC: draft-ietf-l3vpn-2547bis-mcast
> 
> Hello,
> 
> It occurred to me that if/when the PIM assert mechanism is 
> used on PMSI tunnels, then there is a small issue related to 
> S-PMSIs that does not seem to be addressed in current 
> specifications : when two PEs happen to send traffic for a 
> same (S,G) on a P-tunnel, at least one of the PEs needs to 
> receive the packets sent by the other PE or the PIM Assert 
> mechanism won't get triggered. But if we are in a situation 
> where the two PEs have bound an (S,G) to an S-PMSI, then 
> nothing guarantees that one of them will see the packets from 
> the other.
> 
> * impose that PEs join all S-PMSI tunnels for (C-S,C-G) as 
> soon as they have VRF PIM state for (C-S,C-G), *even* if the 
> RPF interface is not the MI-PMSI or such an S-PMSI  -- that 
> way we can be sure that the PIM Assert mechanism will trigger
> * or, impose that, when there are multiple S-PMSI signalled 
> for a said (C-S,C-G), a said PE with state for (C-S,C-G) does 
> not join more than one of them -- that way even though the 
> PIM assert doesn't trigger, we avoid duplicates being 
> forwarded down to the CEs
> * (or, make it clear that the upstream dataplane check is 
> mandatory and that the PIM Asserts mechanism is not used on 
> the MI-PMSI)
> * (or, don't use S-PMSIs when their are dual-homed sources 
> and PIM-based C-multicast routing is used)
> 
> > Please consider today the start of a 2-week last call for 
> > draft-ietf-l3vpn-2547bis-mcast, available here:
> > 
> > Input on this draft's suitability for publication as an Internet 
> > Standards Track document is solicited, feedback ends 
> December 9, 2008.
> >

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 08 Dec 2008 12:07:40 +0800

Hi All,

Sorry for confusing you since I mistaked MP2MP for MP2P.  What I said in the
previous email is just related to ingress replication through unicast
tunnel.

Xiaohu

> 代表 Xu Xiaohu
> 发送时间: 2008年12月5日 9:52
> 收件人: 'L3VPN'; 'Eric Rosen'; 'Rahul Aggarwal'
> 主题: Identifying an ingress PE in ingress replication 
> approach//re: WG LC:draft-ietf-l3vpn-2547bis-mcast
> 
> Hi all,
> 
> Three years ago, there were still some doubts about whether 
> there is a need for the inner label to identify the ingress 
> PE ( see the following threads ).  Now in latest version of 
> draft-ietf-l3vpn-2547bis-mcast, there is already some 
> corresponding mechanism to addres this issue, that is  "it 
> MUST carry, as its second label, a label which has been bound 
> to the packet's ingress PE. This label is an 
> upstream-assigned label that the LSP's root node has bound to 
> the ingress PE and has distributed via an A-D Route ".  
> 
> Using an upstream-assigned label to identify the ingress PE 
> is not a bad idea. However, we can still use one 
> downstream-assigned label (simpler in both control plane and 
> data plane) to identify both the MVRF instance and the 
> ingress PE. Just like the usage of the PW label, the egress 
> PE can assign different labels for the same mVRF to different 
> PE neighbors. Any comments?
> 
> > It occurred to me that if/when the PIM assert mechanism is used on 
> > PMSI tunnels, then there is a small issue related to 
> S-PMSIs that does 
> > not seem to be addressed in current specifications : when two PEs 
> > happen to send traffic for a same (S,G) on a P-tunnel, at 
> least one of 
> > the PEs needs to receive the packets sent by the other PE 
> or the PIM 
> > Assert mechanism won't get triggered. But if we are in a situation 
> > where the two PEs have bound an (S,G) to an S-PMSI, then nothing 
> > guarantees that one of them will see the packets from the other.
> > 
> > * impose that PEs join all S-PMSI tunnels for (C-S,C-G) as soon as 
> > they have VRF PIM state for (C-S,C-G), *even* if the RPF 
> interface is 
> > not the MI-PMSI or such an S-PMSI  -- that way we can be 
> sure that the 
> > PIM Assert mechanism will trigger
> for a said 
> > * (or, make it clear that the upstream dataplane check is mandatory 
> > and that the PIM Asserts mechanism is not used on the MI-PMSI)
> > * (or, don't use S-PMSIs when their are dual-homed sources and 
> > PIM-based C-multicast routing is used)
> >

---

From: Eric Rosen <[email-masked]>
Date: Mon, 08 Dec 2008 09:23:02 -0500

If I understand  the problem correctly, the issue  occurs when the following
two conditions hold:

- ingress replication through unicast tunnels is used, and

- the unicast  tunneling mechanism  does not provide  a way to  identify the
  tunnel head end.

The mechanisms  specified in draft-ietf-l3vpn-2547bis-mcast-bgp-05.txt allow
each tail  end to  specify the  downstream-assigned label to  be used  for a
particular VPN, but do not specify any mechanism that allows the tail end of
a unicast tunnel to identify the head end.  However, various mVPN procedures
assume that when a packet is received, the head end of the tunnel is known.

I believe this is  only an issue for LDP-based MP2P tunnels.   It is fair to
say that  the ingress  replication methods that  have been specified  do not
allow ingress replication through that particular kind of tunnel.

Rather  than adding  new mechanism  to the  existing documents,  I  think we
should simply add  a sentence somewhere saying that  this particular case is
outside the scope of the documents.   Then anyone who thinks it important to
handle this case will be free to submit a draft specifying how to handle it.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 08 Dec 2008 10:28:10 -0500

Thomas> I would see different ways to resolve this (there might be others):

Thomas> * impose that PEs join all S-PMSI tunnels for (C-S,C-G) as soon as
Thomas>   they have VRF PIM state for (C-S,C-G), *even* if the RPF interface
Thomas>   is not the MI-PMSI or such an S-PMSI -- that way we can be sure
Thomas>   that the PIM Assert mechanism will trigger

I believe this is the current practice in the PIM/GRE deployments.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 08 Dec 2008 16:15:58 -0500

Thomas> The Security section currently has the following paragraph:

Actually, the proper cross-reference now is section 7.4.2 ;-)

I'm not sure that any special mention of the S-PMSI Join message needs to be
made in the Security Considerations at all.

Processing  of the S-PMSI  Join Message  is only  defined there  for packets
received from an  MI-PMSI, and the message is defined as  a UDP message with
destination port 3232 and destination address ALL-PIM-ROUTERS.

The real security issue is whether a CE could send a packet to an ingress PE
which  the ingress PE  would then  forward to  an egress  PE, and  which the
egress PE  would then interpret as  an S-PMSI Join Message  received over an
MI-PMSI.

If the  CE sent  a UDP packet  with destination address  ALL-PIM-ROUTERS and
destination port 3232, the packet would not be forwarded to the MI-PMSI, but
would be discarded as an invalid control packet.

So I think the  only case to worry about is the case  where the CE sends the
PE a  GRE-encapsulated S-PMSI Join, and  the destination address  of the GRE
header  is the  same  PIM  group address  that  the PEs  are  using for  the
MI-PMSI.  This  case needs to be  protected against in  general, and doesn't
seem to require anything specific to the S-PMSI Join messages.

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 09 Dec 2008 14:35:03 +0800

Hi Eric,

> If I understand  the problem correctly, the issue  occurs 
> when the following two conditions hold:
> 

Absolutely correct.

> The mechanisms  specified in 
> draft-ietf-l3vpn-2547bis-mcast-bgp-05.txt allow each tail  
> end to  specify the  downstream-assigned label to  be used  
> for a particular VPN, but do not specify any mechanism that 
> allows the tail end of a unicast tunnel to identify the head 
> end.  However, various mVPN procedures assume that when a 
> packet is received, the head end of the tunnel is known.
> 
> say that  the ingress  replication methods that  have been 
> specified  do not allow ingress replication through that 
> particular kind of tunnel.

RSVP-TE tunnel with PHP-enabled also has such problem.  Although many tunnel
technologies except LDP provide a way to identify the tunnel head end, why
not use a unified mechanism to identify it.

Xiaohu

---

From: Thomas Morin <[email-masked]>
Date: Tue, 09 Dec 2008 13:33:45 +0100

Hello working group,

I have two related comments on two sections of
draft-ietf-l3vpn-2547bis-mcast:

** section 9.1, first paragraph, indicates that a dataplane check has to
be made, but:
  - the level of requirement for this dataplane check is vague ("will
check") and text in other section imply that it is not necessarily in
use (it is indeed exact that there are cases where the check is not
strictly needed).  The spec would be  better by saying in which cases it
has to be enabled, and in which case it can be omitted.
  - when this check is done, and when PIM-based C-multicast routing is
used, the PIM Assert mechanism is useless on the MI-PMSI: the spec
should make it clear if implementations are required to implement it or
not
  - the check as currently described, may not be compatible with
Extranet : Extranet is a requirement in RFC4834 expected to be covered
in future work, it is better if we can avoid having to update the
architecture RFC to fit Extranet. The change is actually pretty light:
formulate the check as "check that packets comes from the expected VRF"
instead as "check that packets comes from the expected neighbor"

  => I would suggest clearer wording in section 9.1 about if the
dataplane check is a MUST, SHOULD or MAY ; and clear wording about what
happens (what work/what breaks, side effects) when it is not, and clear
indication if PIM Asserts have to be implemented for the MI-PMSI Lan
Interface
  => I would suggest rewriting the dataplane check to "check that
packets comes from the expected VRF"

** section 5.1.3 proposes multiple UMH selection algorithms and does not
exclude algorithms that would allow different PEs to select a distinct
upstream PE for a said (C-S,C-G); it actually proposes such an algorithm
("use the Installed UMH route") -- but:
  - when such an algorithm is used, in the segmented inter-AS approach
with BGP-based C-multicast routing, PEs *and* ASBRs have to make a
dataplane check on incoming packets
  - if C-multicast routing is done with Full PIM Peering, and the
algorithm described is used, its purpose is defeated, since traffic will
end up flowing from only one PE (because of the PIM Assert mechanism)

  => I would suggest that the specs clearly indicates that the dataplane
check in 9.1 is REQUIRED to allow the use of algorithms that do not
guarantee selection of a same UMH by two distincts PEs

I think it is important to update the document wrt. those issues.

Thanks,

-Thomas

---

From: Thomas Morin <[email-masked]>
Date: Tue, 09 Dec 2008 14:14:43 +0100

Hi Eric,

>         receives from the CE routers connected to the PE router.
[...]
> made in the Security Considerations at all.

Hum, surprising to hear this: why was it added then ?...

In fact, given past security vulnerabilities in implementations of
draft-rosen, such a security statement *is* needed.

> destination port 3232 and destination address ALL-PIM-ROUTERS.

Two things here:
- I don't think that there is a place in current specs where it is
explicit that S-PMSI Join messages processing is only for UDP packets
carried on an MI-PMSI
- even if there was, this would not be enough to avoid security issues:
people usually read specs as "what is enough to get things working" and
the security section is here, among other things, to provide safeguards
which highlight where allowing more than that what is needed to behave
correctly could raise security issues (sometimes an implementation can
safely allow more than what the specs say, sometimes not) : we are
exactly on such a case, as accepting UDP S-PMSI Join packets from the CE
side can happen very easily given the protocol design ("let's listen on
UDP port 3232 in the context of the VRF"), it will not break any
function,  can go unnoticed for a long time... but actually opens a big
security hole !

Correct text to cover this in the security section is actually needed.

> egress PE  would then interpret as  an S-PMSI Join Message  received over an

Yes, this would also be an issue, but no this is not the only one as
past experience showed it.

[...]
> seem to require anything specific to the S-PMSI Join messages.

(  If you have VRF isolation on the dataplane, I don't think that this
is a very serious worry (contrary to the previous case) : a packet
toward destination address G coming from the CE, with G being the same
destination address than the one of a PIM-based I-PMSI tunnel used by
this PE, would be forwarded in the VRF scope as a valid customer
multicast packet (forwarded through the provider core in the context of
a VRF, unless there aren't receivers for this group via another PE), and
would a priori not have any valid reason to be GRE-decapsulated  )

-Thomas

---

From: Eric Rosen <[email-masked]>
Date: Tue, 09 Dec 2008 12:02:29 -0500

Eric> I'm not sure that any special mention of the S-PMSI Join message needs
Eric> to be made in the Security Considerations at all.

Thomas> Hum, surprising to hear this: why was it added then ?...

Because I made  a mistake.  Someone suggested it, and at  the time I thought
it was okay, but on later consideration I think I erred on adding it.

Eric> I don't think that there is a place in current specs where it is
Eric> explicit that S-PMSI Join messages processing is only for UDP packets
Eric> carried on an MI-PMSI

I have  to disagree;  I think this  is quite  clear from sections  7.4.2 and
7.4.2.1.

Eric> accepting UDP  S-PMSI Join  packets from the  CE side can  happen very
Eric> easily given the protocol design 

On the  contrary, there are no  semantics specified for  S-PMSI Join packets
received from a CE.

Thus I think the only issues  are those which are discussed in the security
considerations of RFC  4797, "Use of Provider Edge  to Provider Edge (PE-PE)
Generic Routing  Encapsulation (GRE)  or IP in  BGP/MPLS IP  Virtual Private
Networks".

---

From: Thomas Morin <[email-masked]>
Date: Wed, 10 Dec 2008 15:13:23 +0100

Hi Eric,

> it was okay, but on later consideration I think I erred on adding it.

I think this was a wise addition to the document, which just need a bit
more text to be complete.

> I have  to disagree;  I think this  is quite  clear from sections  7.4.2 and

Well the text says that you need an MI-PMSI and that S-PMSI Join packets
will be sent on it.  Strictly speaking it doesn't say "only".

> On the  contrary, there are no  semantics specified for  S-PMSI Join packets

Indeed there is no valid semantic for S-PMSI Join packets received from
a CE.  But a wrong semantic can very easily be given to such packets by
a implementation not having been carefully written in this respect, and
this is why I think the security section should raise a "warning" flag.

If you look at CVE-2008-1156, this is exactly the case: S-PMSI Join
packets given the processing (and same semantic) independently if they
are received from the PE than from the CE.  Note that the possibility
that such an issue could possibly exist was first identified through
reading the specs, and then confirmed by testing against an equipment.

-Thomas

---

From: Eric Rosen <[email-masked]>
Date: Wed, 10 Dec 2008 12:29:51 -0500

> a implementation not having been carefully written in this respect,

Implementation  errors which cause  packets to  be processed  with incorrect
semantics can  cause a variety of  problems.  However, we  cannot expect the
security   considerations  section   to  list   all  the   things   that  an
implementation could possibly get wrong.

However, if it makes you happy, I suppose we could replace:

   If one uses the UDP-based protocol for switching to S-PMSI (as
   specified in Section 7.2.1), then by default each PE router MUST
   install packet filters that would result in discarding all UDP
   packets with the destination port 3232 that the PE router receives
   from the CE routers connected to the PE router.

with

   The S-PMSI  Join messages  defined in section  7.4.2 are valid  only when
   received over a PMSI, and MUST NOT be processed in other contexts.

---

From: Thomas Morin <[email-masked]>
Date: Thu, 11 Dec 2008 11:03:36 +0100

Hi Eric,

> implementation could possibly get wrong.

Of course. But among all the things that an implementation can get
wrong, not all of them are likely, not all are security issues, and few
or them are both.  So, if there happens to be one thing that is easy to
get wrong (and that actually happened in the past) and has significant
impact on security, it seems wise to raise a warning.

>    received over a PMSI, and MUST NOT be processed in other contexts.

This is "less wrong" than previous wording, but I think that it does not
yet restrict things enough in the light of past issues.

I would propose:

     The S-PMSI  Join messages  defined in section  7.4.2 are valid 
     only when received over an MI-PMSI, and with a destination address
     of ALL-PIM-ROUTERS, and MUST NOT be processed in other contexts.

Ideally, I think it would be good to add some text to explain (a) why
this is a MUST NOT and (b) why this is expected to prevent illegitimate
S-PMSI Join packets sent by a CE to be processed by a PE (*because*
messages sent to the ALL-PIM-ROUTERS address are link local and *not*
forwarded). Tell me if you want text for this.

Thanks,

-Thomas

---

From: Mark Fine <[email-masked]>
Date: Thu, 11 Dec 2008 17:39:27 -0800

Comments on draft-ietf-l3vpn-2547bis-mcast-bgp section 13 and
draft-ietf-l3vpn-2547bis-mcast section 9.1:

With C-RP behind PE1, PE2 having (C-*,C-G) state, C-S behind PE3, and
C-S sending traffic to C-G...

C-RP will upstream join (C-S,C-G) since inherited_olist(C-S,C-G) will
contain joins(C-*,C-G) from PE2's (C-*,C-G) state.

Per 13.1 and 9.1, PE3 creates (C-S,C-G) state as a result of receiving
the Source Tree Join C-multicast route from PE1, and PE3 originates
the Source Active route.

Per 13.2 and 9.1, PE2 sets up its forwarding path to receive (C-S,C-G)
from PE3's tunnel as a result of receiving the Source Active route
from PE3.

Per 13.2.1 and 9.1, PE1 creates (C-S,C-G,rpt) state as a result of
receiving the Source Active route from PE3 and having (C-*,C-G) state
with an iif containing a PE-CE interface.

C-RP will upstream prune (C-S,C-G) since inherited_olist(C-S,C-G) will
be NULL from PE1's (C-S,C-G,rpt) state.

Per 13.1 and 9.1, PE3 deletes (C-S,C-G) state as a result of the
withdrawn Source Tree Join C-multicast route from PE1, and PE3
withdraws the Source Active route.

Per 13.2.1 and 9.1, PE1 deletes (C-S,C-G,rpt) state as a result of the
withdrawn Source Active route from PE3.

C-RP will upstream join (C-S,C-G) since inherited_olist(C-S,C-G) will
no longer be NULL from after deleting PE1's (C-S,C-G,rpt) state.

... per 13 and 9.1, the above suggests a continuous cycle of joining
C-RP to SPT, pruning C-S off RPT, pruning C-RP from SPT, joining C-S
to RPT, joining C-RP to SPT... only forwarding (C-S,C-G) traffic to
PE2 in the intervals where C-RP is joined to SPT.

---

From: Mark Fine <[email-masked]>
Date: Thu, 11 Dec 2008 16:58:40 -0800