RE: security issues on MPLS

["Ferrell, William" <William.Ferrell@titan.com>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Gert
The problem is ... seems as though there are no experts on securing MPLS.
Its always overlooked from an operations perspective.

Our scope of Securing MPLS is broad without going into SMPLS.
to me the most effective way of attacking the issue  is :
Id. MPLS overarching secuity issues from 
Access, inplementation,Operations to hardware/platforms.
keeping the LAbels, LDP , and LSP /LER attacks, through VPNs to the ISIS and
BGP routing Protocols in focus.
Each segment has its own security issues then to use them (BGP,ISIS,VPN)in
conjuction with MPLS may/maynot have a different impact. 
Again the scope is huge and there isnt a lot of research on the issue. 
Our goal is to write security requirments for each segment and the whole.

Will


-----Original Message-----
From: Gert Grammel
To: Ferrell, William
Cc: 'curtis@fictitious.org '; 'Mark.Jones@mail.sprint.com ';
'ccamp@ops.ietf.org '; 'dwfedyk@nortelnetworks.com '; 'gash@att.com ';
'mpls@UU.NET '
Sent: 3/12/03 6:50 AM
Subject: security issues on MPLS

William,

I am not an expert in security issues but (G)MPLS security in particular
rsvp is
based on RFC 2747. In and e2e case IPSEC can be used as well see (see
RFC's 2402
and RFC 2406).

Regards

Gert

"Ferrell, William" wrote:

>  Gert / All
>
>  I am Will Ferrell of Titan working at DISA on an MPLS security
> project. I have worked with Barry Raveendran Greene (Cisco) on a major
DISA
> ACL project of which he provided invaluable guidance/support/ tech
reference
> that led to the projects success.
>
> Ive checked RFC's 2547,3036,2702 et. al.  It appears that there isnt a
lot
> of interest in securing MPLS. Can you refer me to other work for MPLS
> security requirements and all phases of MPLS security to include
secure
> implementation.
>
> > > >
> > > >William Ferrell
> > > >Information Assurance Eng. CCNP
> > > >Titan Corp.
> > > >703-882-2474
>
> -----Original Message-----
> From: Gert Grammel
> To: curtis@fictitious.org
> Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> dwfedyk@nortelnetworks.com; gash@att.com; mpls@UU.NET
> Sent: 3/10/03 7:24 AM
> Subject: Re: {Possible Spam} Re: I-D
> ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Curtis,
>
> you've wrote:
>
>      It would be best if ITU members go off and waste their own time
>      pursuing ASON capabilities, just as the ATM Forum went off and
> wasted
>      their time on Q.2931 capability in UNI 3.x, 4.x, ...
>
> and I don't agree with that. In my view it would be best if ITU-T
> members were
> able to understand and accept the ideas behind GMPLS and would provide
> valuable
> input to bring this work forward.
>
> Regards
>
> Gert
>
> Curtis Villamizar wrote:
>
> > Coments inline.
> >
> > In message <3E679FB5.542FBF09@alcatel.de>, Gert Grammel writes:
> > >
> > > Mark,
> > >
> > > 'improving the coordination between the IETF and ITU-T' is one of
> the
> > > things I' d like to see since years. However in my experience the
> true
> > > barrier between both groups is not so much the technology as such,
> but
> > > some ignorance about the core aspects in both organizations. To
give
> a
> > > balanced figure here:
> > >
> > >   1. You remember the thread about the non-standard SDH/SONET
> > >      extensions. Here some guys active in GMPLS tried to push
their
> > >      ideas about transparency.  Obviously this was perceived on
> ITU-T
> > >      side as a challenge on the purity of a standard (G.707). This
> one
> > >      was (almost) setteled by moving all non-standard features to
an
> > >      informal draft.
> > >
> > >   2. Now it is the other way round. Somehow ITU-T extensions got
> > >      accepted (agai n informational) in IETF which do not comply
to
> > >      the purity of RSVP-TE. Due t o the fact that this
informational
> > >      RFC was not reviewed in CCAMP before, it is perceived as an
> > >      assault.
> > >
> > > So the match is tied up 1:1 but maybe it's now the right time to
> find
> > > a solutio n on how to proceed. What I've seen so far was a
complete
> > > misperception of what i s required on either side and why.
> > >
> > >   1. ITU-T basically started by defining user services having in
> mind
> > >      layered transport platforms like OTH and SDH/SONET. Those
> > >      services can be summarized as 'Bandwidth on Demand' services
> > >      (BOND). Naturally this led to a very strong focus on UNI
> > >      interfaces and a kind of ignorance of networkin g protocols.
> You
> > >      probably remember the discussions on why not using SS7? (For
> > >      those not familar with the issue: SS7 is the signaling
protocol
> > >      between PSTN switches)
> >
> > SDH/SONET bandwidth on demand has never been deployed.  There is
> > serious question about whether this is a viable service.  The
> > technology has existed for about a decade (a little less maybe) for
> > provide ATM SVC service doing essentially the same thing.  Market
> > penetration after a decade is very close to zero for SVC.  Market
> > penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
> > market seems to be shrinking as well.  FR SVC market is zero.
> > SDH/SONET does not have the bandwidth on demand capability but there
> > is ample evidence that implementing it would be a waste of time.
> >
> > ASON is a requirements document from ITU that assumes the SDH/SONET
> > BOND is a viable service.  This is an enormous leap of faith given
the
> > trends in the market.  The IETF doesn't buy into it.
> >
> > And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
> > mess, so if you want to extend TCAP to support ASON, go right ahead.
> > We in the IETF would get a real good laugh over that.
> >
> > >   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE,
> ...)
> > >      and extending their scope to L1 technologies namely SDH/SONET
> and
> > >      OTH.  Naturally this led to a very strong focus on protocol
> > >      consistency and a kind of ignorance on service aspects other
> than
> > >      those already available in MPLS. You may remember here the
> > >      discussion about whether UNI is useful at all some time ago.
> >
> > Initially IP and voice ran over TDM.  The bandwidth demands of IP
were
> > much less than voice a decade ago.  As IP penetration grew roughly
> > exponentially through the early, mid, and most of the late 1990s,
this
> > reversed and IP consumed far more bandwidth than voice.  Switched
> > services also grew but at a slower rate and in the late 1990s
> > experienced negative growth for many SPs.  One factor may have been
> > notable outages in FR (US nationwide one day at one major provider
and
> > intermittent for 10 days in another a few years later) shot a big
hole
> > in the "much more reliable than IP" story.
> >
> > Initially MPLS served as traffic enginnering strictly for IP.  With
IP
> > still growing substantially, voice growing very slowly (and losing
> > revenue) and switched services growing slowly to shrinking, there
was
> > motivation to carry voice, switched services, and leased line
services
> > over the IP and/or MPLS infrastructure and decommission older
> > SDH/SONET ADM and FR or ATM switches.  This led to the tunneling
work.
> >
> > Another factor which led to GMPLS was the (unrealized) promise/hype
of
> > optical switching in the very late 1990s.  IP over an ATM overlay
was
> > a poor design and IP providers did not want to repeat that mistake
so
> > the control of the underlying optical domain was accommodated by
what
> > has evolved into GMPLS.  GMPLS was extended to accommodate TDM in
> > addition to FSC, LSC and PSC.
> >
> > > So putting everything together means that it is required to keep
> > > (IETF) protocol consistency but adding some (ITU-T) specific
> > > extensions to well defined service points in the network (UNI).
> > > Unfortunately service points tend to exchange messages between
> > > themselves and this would mean that an intermediate protocol would
> > > have had to support such kind of communication. What concerns the
> IETF
> > > community is probably not the fact that there is a UNI somewhere,
> but
> > > the changes and extensions to etablished protocols in order to
> achieve
> > > a collaboration between them.
> >
> > ASON was never accepted by the IETF as requirements and for very
good
> > reason.  To say that IETF must accept the ASON requirements simply
> > because they came in a liason statement and that the IETF must
> > accommodate this ITU folly is absurd.
> >
> > > I recall that this was the basic issue with the ITU-T proposal
when
> it
> > > was presented for the first time in Yokohama. The way I've got
> > > Kireeti's message there was: please authors try to let us
understand
> > > what problem you want to solve and tell us which kind of
information
> > > you have to exchange between which points to achieve it. We'll
sort
> > > out then in CCAMP what would be the most appropriate way to
> implement
> > > it, while maintaining consistency in our protocols .
> >
> > Regardless of how this was handled in Yokohama, some of the
> > fundamental premise of ASON is flawed.  It would be best if ITU
> > members go off and waste their own time pursuing ASON capabilities,
> > just as the ATM Forum went off and wasted their time on Q.2931
> > capability in UNI 3.x, 4.x, but ITU should do so without extending
> > protocols which originated in the IETF.
> >
> > > Although it didn't work the first time I still consider Kireeti's
> > > suggestion to be a wise way to move forward and perhaps the key
for
> > > harmonic collaboration.
> > >
> > > Regards
> > >
> > > Gert
> >
> > I look forward to seeing the IETF come up with a formal statement of
> > liason policy.  It would be useful to have explicitly documented
that
> > liason statements carry no more weight than any individual
> > internet-draft submission.
> >
> > Curtis
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de