Subject: AD Comments on PW Security

From: Danny McPherson <[email-masked]>
Date: Mon, 28 Oct 2002 07:39:11 -0700

Folks, 
I'd like to get your feedback on Allison's comments here:

[snip]

  - Providing security for the PW PDUs;

 Disagree that this is a non-requirement, in that identifying the
 change in the channel security of the layer 2 because of its
 being a PW is very important.  Providing a channel security replacment
 to protect the bits is something that could be architected by PWE3,
 knowing how IPSEC fits here.  Why is that not your scope but other
 aspects of encapsulation are?  [Also 11.2]

 About Section 11:  PW's are insecure encapsulations and I think 
 this WG has to surface requirements about this.  The links have
 mechanisms and informations that are exposed by PW.  SO  it is
 data plane, not just control plane, I'd like the WG to reconsider
 on this (and I think Security Area should back this up).  It's ok
 not to do too much on this before we Last Call, IMO.  You could
 look at what we (I pushed) got the authors of RFC 3378 to put in
 and add some words like that.

[/snip]

-danny

---

From: Danny McPherson <[email-masked]>
Date: Mon, 28 Oct 2002 09:44:01 -0700

>          Two points.  First, it seems that many PW security issues are
> similar to those for L3VPN.  Therefore, shouldn't we first look at those
> issues and reference the pertinent ones from PPVPN (rather than importing)
> and then augment them where necessary?  

My opinion of course is that we should leverage PPVPN work 
where possible.  However, a unified security architecture for
PWs (and VPN signaling mechanisms) should be a fore thought
as far as were concerned, not bolted on..  I'm guessing we
agree on this.

> Second, security issues
> to consider not only include encryption/connection hi-jacking, but also
> mis-configuration of VPNs/connections (inadvertent or deliberate)
> and detection of those mis-configurations.  Ron Bonica pointed this out
> not too long ago for L3 VPN.  Thus, I suggest that we make sure that we
> consider a broad scope of security issues, not just the obvious ones.

Agreed!

-danny

---

From: [email-masked]
Date: Mon, 28 Oct 2002 18:46:10 -0000

Hi Tom/Danny...please see below.

regards, Neil

Thomas D. Nadeau remarked 28 October 2002 14:58
> At 07:39 AM 10/28/2002 -0700, Danny McPherson wrote:
> 
> >Folks,
> and then augment them where necessary?   Second, security issues
>          --Tom
NH=> You beat to saying this Tom.  However, let me add a bit more by way of
explanation of the issue being alluded to here:
There are 3 generic types of network:
-	cnls
-	co pkt-sw
-	co cct-sw (aka TDM)

In cnls networks like IP each/every pkt has absolute addressing, ie the
address is unique to the network its relevant to.  Each/every pkt therefore
has a native connectivity verification function to stop it getting
inadvertently misdirected.

This is not true in co networks.  They route between absolute soutrce/sink
addresses (the network access points), and create (via signalling or
management) trail (aka path) entities to 'steer' the data-plane pkts between
such points.  It is the combination of trail entity + pkts carried that
define the overall management entity here.....and in fact it is the trail
entity that takes management precedence, ie if the trail entity is faulty
(ie down) the pkts have no parent reference for correct routing.....a key
point when trying to define QoS metric objectives, which are only meaningful
if it is known that the trail is 'good/up'.  Now, the link-connections (ie
hops) in a co network use relative identifiers.....the same relative
identifiers can be used on other link connections (of same or other trail),
so they are only link-connection unique and not network unique.  This means
in co networks one has to apply some form of periodic/deterministic checking
that the right source is connected to the right sink.  This alone is good
enough for co cct-sw networks (eg J1 byte in SDH VC4).  However, its not
good enough in co pkt-sw networks as these can also replicate/leak pkts even
though the original trail stays up and looks fine.  Clearly leaking pkts is
a serious concern (you could call this a security concern) in the case of
VPNs.

I was very concious of this fact and the need to address it when I penned
Y.1710 (requirements) and Y.1711 (mechanisms) way back to deal with p2p
LSPs......though to be frank, these solutions can, and should, apply to all
co pkt-sw technologies, ie its the same functional problem....albeit the
precise detail may vary technology to technology.

BTW - Y.1711 does not address mp2p constructs....other techniques will have
to try and cope with the many fault-management issues they raise.  However,
in the case of simple p2p PW applications using MPLS, I believe you will
need to support the functions as defined in Y.1711, as without them I can't
see how the correct fault-management requirements will be provided to client
layer networks.

regards, Neil

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 28 Oct 2002 14:14:06 -0400

>as far as were concerned, not bolted on..  I'm guessing we

         Yes.

> > consider a broad scope of security issues, not just the obvious ones.

         Cool.

         --Tom

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

Success is relative; the more success, the more relatives. -Anonymous