Subject: Re: AD Comments on PW Security

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

At 07:39 AM 10/28/2002 -0700, Danny McPherson wrote:

>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.

         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?   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.

         --Tom

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

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 29 Oct 2002 17:31:07 +0000

>  aspects of encapsulation are?  [Also 11.2]

The key issue is whether there is anything special about securing
PW-PDUs, as opposed to using IPSEC to secure anthing else carried
over MPLS or L2TP.

Alison is correct that PDU security is required (in some instances), but 
hopefully we can satisfy the needs by technology that is outside the
scope of PWE3.

Perhaps we should re-word the requirement to say that securing
PW-PDUs may be required, but that security is assumed to be provided
by the PSN.

>  and add some words like that.

Something based on the text of RFC-3378 (removing the circular reference)
would would work for the architecture - it is already close. In the
case of requirements, I think that all tthat is needed is a one
sentence summary sating that is nome circumstances the PDUs
need to be secured.

---

From: Eric Rosen <[email-masked]>
Date: Tue, 29 Oct 2002 14:12:57 -0500

Perhaps section 11.2 of the requirements document could say something like: 

    When deploying a PWE3 service, it must be possible to provide some
    assurance that packets received  on a PW were actually transmitted
    on that PW, not inserted into the PW by a third party.  Similarly,
    it  must  be  possible  to  provide some  assurance  that  packets
    transmitted on a PW will  be delivered only to the remote endpoint
    of the PW, and will no be seen by arbitrary third parties. Whether
    this  requires  cryptography  or  not depends  on  the  particular
    deployment scenario.

    It  must  be  possible  to provide  cryptographic  authentication,
    integrity, and privacy through the use of IPsec. 

I'm not sure the requirements document should say anything more. 

I  don't  think  we need  different  sorts  of  security for  the  different
services, so the architecture document is probably the place to go into more
detail.  As  far as  providing the necessary  assurances without the  use of
cryptography, the issues are really no  different than they are in the L3VPN
space,  as discussed,  say,  in section  13 of  draft-ietf-ppvpn-rfc2547bis-
03.txt and section 6 of draft-ietf-ppvpn-as2547-00.txt. 

As for providing  the necessary assurances with the  use of cryptography, it
might be  appropriate for the  architecture document to discuss  using IPsec
per-tunnel  as opposed to  using IPsec  per-PW.  I  think that  putting L2TP
through an  IPsec tunnel is well  understood; putting MPLS  through an IPsec
tunnel is also well-understood, though less well-known. 

The meta-issue here is that no one really wants to use IPsec, because of the
management and  performance implications.   Rather, one expects  the service
providers offering  a PWE3 service  to provides the necessary  assurances by
controlling their own networks, especially at the inter-provider boundaries.
Of course, this  won't work over the public Internet  (i.e. where the tunnel
pathtraverses an arbitrary and  uncontrolled set of providers).  IPsec would
be needed  in that environment if anyone  ever actually tried to  run a PWE3
service  over  that  environment.  The  WG  tends  to  focus on  the  former
scenario, while the IESG tends to focus on the latter.

The material from RFC 3378 is unobjectionable, but it seems to me it belongs
in  the draft  that  describes the  emulated  ethernet service,  not in  the
requirements draft or the architecture draft.