RE: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-pr oc-00.txt

[neil.2.harrison@bt.com]

William Ferrell wrote 13 March 2003 16:22
> "Since MPLS implements the same routing protocols such as 
> OSPF and BGP in
> LSRs in performing routing functions, it would have  the same
> vulnerabilities, such as routing tables being poisoned and IP 
> header fields
> being changed, as in the IP networks using regular routers in 
> routing IP
> traffic"
> 
> Same old arguement here : 
> MPLS uses LDP is that to say that it is "like " OSPF ? NO. 
> MPLS uses the
> Routing protocol to get routing information. But ultimately , 
> yes I agree
> that by useing ISIS , OSPF and BGP the routing tables are 
> suspect to attack
> and same old vulnerbilities are now transposed onto the MPLS net, but
> conversely so is the signalling and hellos in LDP.  
> 
Will,  Not really sure where you are going here but one thing you need to
think about is making sure the network itself has some form of self-checking
so that security problems don't arise as a results of network failures.  We
regard this as very important (especially for arbitrary X/MPLS client/server
relationships, eg ATMoverMPLS) so let me try and explain:

In a cnls network each/every pkt contains full SA/DA.  So you can pick a pkt
up from anywhere and drop it somewhere else and (subject to TTL exhaust) it
will find its way to the right destination.  Not true however in MPLS (any
type).

The links between MPLS nodes use link-connection identifiers, which are only
required to be unique for the link between a pair of adjacent nodes.  These
link-connection identifiers only possess networking currency when they are
allocated to a parent LSP entity at it's creation time.  Similarly, the
link-connection identifiers lose their networking currency when their parent
LSP entity is destroyed.

A specific link-connection identifier can be used: (i) on different links in
the same LSP, or (ii) on any links in other LSPs.  This means one cannot
take a packet out of a given LSP at any point and drop it into the network
at some other point and expect it to find it's way to the correct
destination.  There are 2 possible outcomes from doing this:

1	The packet will black-hole at the next receiving node if the
link-connection identifier has no currency at that node, ie it is not
allocated to some parent LSP;  or,

2	The packet will be forwarded at the next receiving node if the
link-connection identifier has currency at that node (and thereafter
forwarded on all subsequent links to the connection sink point), ie it is
allocated to some parent LSP.  Note also that this case can be *recursive*
if there are nested client/server LSP relationships....so the black-holing
or further forwarding behaviour can continue upwards in the affected client
LSPs.

Any failures that result in MPLS packets being misdirected raise traffic
integrity/security concerns.  So not only must such defects be automatically
detectable, but they must also automatically elicit the right type of
consequent actions, eg in this case squelch the traffic, as well as
informing the higher client (eg ATM) of the failure.....note that the client
network may be an external customer of the MPLS layer network
service-provider and so in a completely different management domain.

So this is why in SDH, for example, you find a trail-trace function in the
user-plane, ie a periodic identifier sent by the source to the sink so that
the sink can verify it has correct connectivity.  The same should also apply
to MPLS (or at least those versions of MPLS that are p2p.....mp2p LSPs raise
a whole raft of other issues).  The requirements for this are given in
Y.1710 and the solutions are given in Y.1711, ie we require that a
Connectivity Verification OAM packet be periodically sent in the user-plane
from the source to the sink that identifies where the pkt came from. In
doing so we can detect all failure modes, eg simple breaks, swapped LSPs,
and mismerged LSPs, and take the right consequent actions quickly.

This does not address all the security concerns of course, and its not
intended to protect against malicious attacks....it merely helps protect the
network from creating security breaches due to its own failures.

regards, Neil