Subject: Re: draft-lee-ppvpn-ce-auto-config-01.txt

From: "Cheng-Yin Lee" <[email-masked]>
Date: 1 Aug 2002 14:18:52 -0400

Eric,
Thanks for your detailed comments. Sorry for the delayed response.

Eric Rosen wrote:

> ****  I  think we
> **** should be settling  on a smaller number rather than  a larger number of
> **** mechanisms.

Agree that we should be settling on a smaller number of mechanisms, but the
request after the 53rd IETF meeting was for comparisons of management protocols
that could be used.

>
> **** Up  until  now,  we've  really  had  two  basic  mechanism  that  we've
> **** discussed:
>
> **** - Reliable real-time distribution of VPN config info via protocols that
> ****   were developed for distributing routing information (BGP).
>
> **** - Clients  poll servers  for information,  using a  type of  server for
> ****   which  there is a  ubiquitously deployed  infrastructure with  a well
> ****   understood and well-tested update/synchronization mechanism (DNS).
>
> **** When introducing additional mechanisms  for consideration, it should be
> **** made clear what the trade-offs  are with respect to the mechanisms that
> **** have already been considered.

There is a section on DNS in this draft, but we can add further clarifications.
Do you think BGP is feasible for CE-based VPN?

>
> 3. VPN service parameters
>
>    The parameters that can be auto-configured at a CE device to allow a
>    CE to self provision tunnels include:
>
>    i) the list of remote CE IP address(es)
>
>    ii) the VPN identification
>
> **** If  the VPN-id is  auto-discovered, how  does the  CE identify  (to the
> **** auto-discovery  infrastructure) the  class of  information it  needs to
> **** obtain?   Or are we  anticipating a  multi-stage autoconfig  process in
> **** which the  CE first finds  its IP address  (using its MAC address  as a
> **** key, say), then uses its IP address  as a key to finds its VPN-id, etc.

Yes, the CE should obtain its IP address first, and subsequently obtain VPN
information, as Thomas Nadeau also suggested in another thread.

>    iii) the role of a site (e.g. whether it's a hub or spoke)
>
> **** I don't see why the CE even has to know this.

It is useful to indicate if a site should originate the tunnel setup, perhaps
it's better to call this "tunnel setup originator" or something along this line
instead?

>    iv) the transform sets defining the security protocols and algorithms
>    that shall be used by two CEs for encryption and authentication (for
>    IPSec).
>
>    The (pre-shared or CE's private) key for IPSec tunnels must be pre-
>    configured on the CE. Other VPN service related configuration which
>    do not change as sites are removed or added to a VPN may also be
>    configured a priori or remotely (and manually) configured if the
>    parameters do not change frequently. The intent here is to define a
>    minimal set of VPN service parameters that should be auto-configured.
>    Hence, this draft shall focus on the auto-configuration of tunnel(s)
>    to remote CE(s). If necessary, the transform sets for IPSec and other
>    service parameters shall be defined to be auto-configured in future.
>    It is assumed for now, the transform sets configured on a CE shall be
>    applicable to all the IPSec tunnel(s) to other CEs of the same VPN.
>
> **** Does this rule out the use of different security policies for different
> **** tunnels?

So you think it's better and necessary to allow the transforms sets to be
auto-configured as well? We can include this if so.

> 4. CE Auto-Configuration requirements
>
>    The CE auto-configuration solution should:
>
>    - minimize the number of parameters that must be pre-configured
>
>    - minimize the number of parameters that shall be auto-configured
>
> **** These   two   requirements  are   in   conflict.    Why  minimize   the
> **** number of auto-configured parameters?  Or did you mean "maximize"?

The point is to reduce in general the  number of parameters to be configured
(auto or pre) if feasible.

>    - allow configuration of CEs within one AS (Autonomous System) or
>    network provider
>
> **** I don't understand what that means.  Are you saying that the procedures
> **** needn't allow for VPNs whose CEs are in different ASes?  I think such a
> **** restriction would be unacceptable.

No, it means it should at least allow configuration within one AS.

>    - allow CE to auto discover/request tunnel endpoint information
>
>    - be able to auto update CEs with new tunnel endpoint information
>
>    - allow a CE to self-provision the tunnels to other CEs
>
> **** The above three lines seem state the same thing.
>

We'll clarify this.
the 1st point means to allow CE to query for tunnel endpoint info (e.g. LDAP
could support this)
the 2nd point means to allow CE to be updated by tunnel endpoint info by an
entity (e.g. COPS, DHCP could do this, but LDAP can't support this)
the 3rd point - the CE is able to automatically provision itself given the VPN
information (discovered earlier on)

>    - allow a provider to provision tunnel information for a CE
>    independent of whether a CE is up and running
>
> **** and when  the CE  comes back on  line, the auto-update  procedures must
> **** reliably obtain the latest info

Yes.

>    - allow authentication of the tunnel endpoint information
>
>    - not allow a customer to tamper with configuration of a CE
>
> **** This last requirement  is at odds with the requirement  that the SP not
> **** have to manage any interaction  with the customer routing.  I think you
> **** mean that the  customer must not be allowed to tamper  with any part of
> **** the CE's configuration other than the part that he is allowed to tamper
> **** with.  Such a statement would only be interesting if made very specific.

If the CE is owned by the provider should the customer be allowed to configure
the CE at all?

>    - allow a provider to explicitly add or remove sites of a VPN e.g. a
>    tunnel setup or removal does not necessarily imply a site should be
>    added or removed from the VPN
>
>    The CE auto-configuration solution may:
>
>    - allow configuration of CEs in different AS (Autonomous Systems) or
>    network provider
>
> **** This has to be mandatory, not merely "allowed".

If this is common in deployment or required by SP, then we should make this
mandatory.

>
>    - automate IP address association with a CE of a VPN
>
>    [Note: a provider may have to be informed of a CE location offline
>    and has to manually associate an IP address (that the CE is reachable
>    from a provider's network) with a CE  of a VPN. Hence it is useful to
>    allow a CE to authenticate itself to a  VPN Configuration server and
>    then to "register" itself. This allows a VPN Configuration server to
>    associate the CE with its current IP address  or alternatively, if
>    the CE is within the service provider's network, the VPN
>    Configuration server may be able to assign the IP address to the CE
>    (on the port facing a network provider), associate the CE with the
>    assigned IP address and at the same time provide the remote CE IP
>    addresses [See Appendix].
>
> **** So, with  this sort of  mechanism I could  take my CE anywhere  I want,
> **** hook it  up to the net,  and gain access to  my VPN.  In  fact, I could
> **** take someone  else's CE,  bring it to  my place,  hook it up,  and gain
> **** access  to his VPN.   This is  neat, but  whether it's  a good  idea is
> **** something  else  entirely.

The purpose is to reduce the provisioning required. Is it better to have IP
address association of a CE with a VPN, done manually then?

> Or  are  you thinking  of  something  less
> **** flexible, where a given CE only gets to attach to a given PE interface?

Could you clarify how this would work?

>
> **** I think we could use  more elaboration of the relation between security
> **** and CE auto-configuration.

ok, we'll elaborate on this, you're asking about impact (of CE-autoconfig) on VPN
security?

It's getting long, so I'll continue with the rest of your comments in another
email.

thanks
cheng-yin

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 8 Aug 2002 17:14:13 -0400

Eric,
Responses/questions to the rest of your comments.

Eric Rosen wrote:
> 4.1 General Ideal Solution
>
>    Ideally on bootup, a CE should be able to automatically perform
>    procedures to gain network access if needed and obtain an IP
> address
>    to allow it to communicate with other CEs in the IP network, e.g.
> via
>    [DHCP] or for PPP links via IPCP.  Subsequently the CE shall
> request
>    tunnel information from a VPN Configuration server.
>
>    CEs need only be pre-configured with :
>
>    a) a shared key or private key/certificate pair or a password, to
>    allow it to authenticate itself to the VPN Configuration server and
>
> **** Having the CE  authenticate itself ensures that the  CE won't
> learn the
> **** tunneling  information  unless the  CE  has  been  configured
> with  the
> **** authentication data.  But  if the server doesn't know  where the
> CE is,
> **** or who has it, I'm not sure how much that really protects.

I don't follow the second sentence, could you rephrase it pls?

>    b) a shared key or a CA's public key to allow it to authenticate
> the
>    VPN Configuration server
>
> **** I don't know how  much good a shared key would do  here.  It
> would have
> **** to  be known  by a  large number  of devices  which are  not
> under the
> **** physical control of the SP.

Is your concern about having to distribute the shared keys or something
else, could you elaborate pls?

>    If a shared key is used, a CE may additionally be pre-configured
> with
>    a CE Identification (ID) in some service deployment scenarios, e.g.
>
>    where the service provider is not able to infer the "location" of
> the
>    CE or infer from the IP address of a CE which CE it is
> communicating
>    with.
>
> **** The above paragraph seems to belong  in part a).  However, I'm
> not sure
> **** just what  good it does,  unless it is  impossible for the CE-id
> to be
> **** changed by someone other than the SP.

Yes, the above para should be in part (a) and the CE ID can only be
changed by the SP.

> 5.1 SNMP
>
>    It is not recommended that an operator configure CEs directly via
>    SNMP, as this is labour intensive.
>
> **** Whether  it  is  labor intensive  is  a  tools  issue, not  a
> protocol
> **** issue. The real issue with regard to the use of management
> protocols is
> **** the  complexity  of setting  up  the  tools  to provide  the
> necessary
> **** timeliness and reliability.

agree.

>    A new auto-discovery framework is required on CEs and SNMP
> "manager"
>    code which allows a CE to "get" VPN service parameters (a defined
> IP
>    VPN MIB) from a VPN Configuration server is required to be
>    implemented on a CE.  Normally a Network Element (NE) has an SNMP
>    "agent" which allows a Network Manager to "get" MIB objects from
> the
>    NE.  If it is not feasbible for a CE to "get" VPN parameters, the
> VPN
>    Configuration server may have to send SNMP traps to the CE to
> trigger
>    the CE to do a "get" VPN parameters from the VPN Configuration
>    server.
>
> **** Having the  CE use SNMP GET  to pull data  from a server is  a
> somewhat
> **** peculiar idea, I think.  You'd be better off using FTP.

We are not advocating this mechanism, just trying to document what the
possibilities are to allow us to compare the different protocols and the
issues in using them.

> 5.2 LDAP/DNS
>
>    A CE could retrieve tunnel endpoint information (to add new
> tunnels)
>    from a (DNS or LDAP) server, and may be located in a different
>    provider's network. However, a provider is not able to inform a CE
> to
>    explicitly teardown a tunnel to a site unless the CE poll the DNS
> or
>    LDAP server for VPN update information or a message is sent from
>    another server using a different protocol to trigger the CE to pull
>
>    information from the DNS or LDAP server.
>
> **** The receive-trigger-then-pull  paradigm is a lot  more
> complicated than
> **** the "poll periodically"  paradigm, especially if you try  to do
> it with
> **** protocols that  do not have the necessary  reliability mechanisms
> built
> **** into  them.

Agree that the "poll" paradigm is simpler. Again, we are not advocating
this particular method, just trying to document possibilities and issues
here, we'll incorporate your comments on this issue.

Do you think it's necessary to be able to update CEs to teardown a
tunnel, or is it sufficient to have CEs only poll for the updates?

> Either  paradigm  has some  difficulties  in figuring  out
> **** whether  the absence  of some  previously present  data  is
> significant
> **** (meaning  remove a tunnel)  or not  (e.g., a  transient problem
> in the
> **** delivery mechanism).

Agree for mechanisms that don't have reliability mechanims, but some of
the mechanims considered such as  DHCP has reliability mechanisms and
while the RADIUS protocol itself does not provide reliability
mechanisms, the retransmission & reliability procedures are provided by
implementation.

>    If another messaging/protocol is required to inform a CE to remove
> a
>    tunnel endpoint, that same protocol could be used to inform a CE to
>
>    add a tunnel endpoint, instead of LDAP/DNS, i.e. the use of
> LDAP/DNS
>    for CE auto-configuration would be redundant then.
>
> **** A bit of handwaving there.

The point here is if an additional protocol is required to inform a CE
to add a tunnel endpoint (instead of relying on polling via LDAP/DNS)
then this protocol could very well be used by CEs to query for VPN
informationl instead of using LDAP/DNS.

> 5.3 IKE
>
>    When a CE attempts to setup tunnel to a remote CE (which may be
>    located in a different provider's network), the remote CE is
>    implicitly being informed of the tunnel endpoint. The remote CE may
>
>    still need to contact the VPN Configuration Server (using another
>    protocol) to download other tunnel endpoint information.  This
>    implies a provider is not able to explicitly teardown a tunnel to a
>
>    site, unless a message is sent from  a server using another
> protocol,
>    as in the LDAP/DNS approach.
>
> **** This is another of the  "receive trigger then pull" methods.

understood.

> 5.4 COPS
>
>    COPS allows a CE to retrieve tunnel endpoint information as well as
>
>    to be updated of tunnel endpoint information from a PDP (a server).
>
>    CEs may be located in different providers' network and SSL/TLS may
> be
>    leveraged to provide secure commnunication between CEs and the VPN
>    Configuration Server.
>
>    The PDP (Policy Decision Point) must maintain a large number of TCP
>
>    sessions if there are a large number of CEs.
>
> **** Is there anything to be said in favor of this solution?

Yes, in the first paragraph 5.4

> 5.6 DHCP
>
>    Auto-discovery and auto-update framework already exist on DHCP
> client
>    and server.
>
> **** I'm  not  sure  that  DHCP   auto-update  is  all  that
> robust.   When
> **** connections depending on the discovered information are in
> progress, it
> **** is not always  clear what the impact of the updates  is supposed
> to be.
> **** This would have to be clearly spelled out.

DHCP has realibility mechanisms, we'll clarify this.

>    Automate CE address association with CEs of a VPN and
>    faciliate CE address management and reuse.  Lightweight when CEs of
> a
>    VPN are within a provider network.
>
> **** Unfortunately,  there  is   no  "lightweight"  procedure  for
> reliably
> **** updating  the entire  set of  DHCP servers  that may  need to
> have the
> **** configuration information. I believe  this has been pointed out
> before,
> **** and  replied to  only  with handwaving  about  unnamed and
> unspecified
> **** "existing products" which are alleged to solve the problem.

We can remove the description "lightweight", but if you compare among
different protocols, DHCP & RADIUS may require the least protocol extensions
(mainly parameter extensions). As you may have also commented in the
draft-ietf-ppvpn-ce-based thread, DHCP would work.

As I understand, multiple DHCP servers can be configured from one
management station, and configuration information is sent from the management
station to multiple DHCP servers.  The MIB for the DHCP servers can be specified
but I'm not sure if the mechanisms to configure multiple servers correctly (e.g.
what if one server is down) need to be standardized, what do you think?

Perhaps you may be concerned with DHCP "failover" (DHC WG draft)? As I
understand, DHCP "failover" addresses synchronization of address leases. I think
this has requirements that are different from provisioning multiple servers.

>    In the case where CEs span inter-domain networks and hence the
>    network access configuration process may not be leveraged, an
>    approach where a front-end Authentication Server [See PIC, XAUTH]
> is
>    used to authenticate CEs in another provider's network and request
>    VPN information from a back-end server (e.g. a RADIUS server or
> DHCP
>    Server), may be required.  The CEs in another provider's domain
>    cannot be updated with new VPN information, unless the back-end
>    server is able to provide VPN information update to the front-end
>    Authentication Server, and the front-end Authentication Server is
>    able to inform CEs of the VPN information change.
>
> **** Since the CEs are not under the physical control of the SP, I
> think the
> **** authentication  requirements are the  same whether  they attach
> to the
> **** SP's own backbone or not.

Agree. Perhaps if we can't leverage the network access configuration
process, the latter approach may be used instead for both cases (whether
the CE attach to the SP's own backbone or not)?

>
> 1. Overview of CE Auto-configuration solutions
>
>    A CE shall be automatically configured with an IP address to allow
> it
>    to communicate with the provider's network.
>
>    Different protocols (depending on the network access method and VPN
>
>    service deployment requirements) which allow CEs to discover and/or
>
>    be updated with VPN service information are described here.
>
>    Both the automatic configuration of IP address on the CE and
>    provisioning of services on the CE should be authenticated to
> prevent
>    malicious users from tampering with CE configuration.
>
> **** We  need a  much  more detailed  analysis  of the  possible
> attacks  by
> **** "malicious  users" and  the  way in  which  the various
> authentication
> **** methods prevent (or fail to prevent) those attacks.

Authentication will not prevent DoS. Could you provide an example where
authentication of CE provisioning messages will fail to prevent the CE
from being provisioned by unauthorized users, I can't think of one myself.

> 2. Auto-configuration of IP address of CE
>
>    If a CE is located in the VPN service provider's network (also the
>    network provider in this case), a CE may use DHCP to automatically
>    obtain and configure its IP address (facing a provider's network).
>    Otherwise the CE IP address is assigned by the CE's network
> provider,
>    and VPN service provider must be informed of the CE IP address
>    offline, or when a CE contact the VPN Configuration Server as
>    described in later sections.
>
> **** I don't understand why the  IP address must be explicitly
> configured in
> **** the CE if the CE is on a different provider's network.

No, it's not saying that, the IP address  of the CE could be
auto-configured by the other provider's network (not by the VPN provider).

> 6. Security Considerations for DHCP
>
>    The addition of DHCP option(s) for VPN auto-configuration does not
>    affect the security of DHCP.  The security issues of DHCP are
>    described in [DHCP-AUTH] and as it pertains to the
> auto-configuration
>    of CEs, the security issues are described in this draft.
>
>    If an unauthorised CE configure its own IP address, the CE may not
> be
>    permitted to use any services unless the CE has been authenticated
>    for the particular service. For e.g. a device or the default filter
>
>    at the ingress to the network can be configured to discard all
>    traffic except DHCP messages from the client (port 67) unless the
>    client has been authenticated for services as described in Section
> 3.
>
> **** Is  the  PE   expected  to  keep  state  about   which  CEs
> have  been
> **** authenticated?

I don't think the PE need to do this if the CE and PE is a point to
point link.

>    To reduce DoS attacks, the DHCP server may choose to "quarantine"
> CEs
>    which have exceeded the pre-defined number of communication
> attempts
>    allowed with the DHCP server within a given period.
>
> **** I think this  just turns the DoS  attack on the DHCP server  into
> a DoS
> **** attack on the CE.

How so?

thanks
cheng-yin