Subject: Re: [IPsec] STRONG NUDGE: Revised AD VPN Requirements

From: "Ulliott, Chris" <[email-masked]>
Date: Wed, 17 Oct 2012 15:47:40 +0100

Apologies for the delay in replying...

I think the Gateway to gateway use case (para 2.2) doesn't cover the problem I'm suffering.  What if the use case was reworded such that it says something along the lines of:

-- start --

A typical Enterprise traffic model is hub and spoke, with the gateways connecting to each other using IPsec tunnels.

However for the voice and other rich media traffic that occupies a lot of bandwidth or is performance sensative, the traffic tromboning to the hub can create traffic bottlenecks on the hub and can lead to an increase in cost.  A fully meshed solution is would make best use of the available network capacity and performance but the deployment of a fully meshed solution involves considerable configuration, especially when a large number of nodes are involved.  For the reasons of cost and manual error reduction, it is desired that there be minimal configuration on each gateway.

It is highly desirable that the solution works where the endpoints are administrated by separate management domains, albeit, ones that have an existing trust relationship (for example two organisations who are collaborating on a project, they may wish to join their networks, whilst retaining independent control over configuration)

When two gateways communicate, they must use a mechanism for authentication, such that they do not expose themselves to the risk of impersonation by the other entities.

-- end --

In section 3.2, it would be nice if we could again mention that rather looking for a solution that makes a star architecture work, actually enables a dynamic, fully meshed solution to be practical.

In section 4.1, there are comments about minimising the configuration changes... should we word this a bit stronger and say that after initial configuration, there should be no need for a manual configuration change as devices (endpoint or gateways) are added, removed or changed?

For the use case where end points need to find the optimum gateway to connect to, do we need a requirement that enables an endpoint to identify which is the best gateway to connect to, the nearest may not be the best, depending on the network cost behind the gateway... but this may be complicating the problem too much.

Thoughts?

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Saturday, September 08, 2012 5:31 PM
To: IPsecme WG
Subject: [IPsec] STRONG NUDGE: Revised AD VPN Requirements

This appeared on the list over two weeks ago and it has received no comments since. This is supposed to be the WG's main work item, folks.

--Paul Hoffman

On Aug 23, 2012, at 9:02 AM, Stephen Hanna <[email-masked]> wrote:

> Vishwas and I have updated the AD VPN Problem Statement
> and Requirements draft to address the comments received
> on the previous version and remaining comments from
> earlier email discussions. The new version is available at
>
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem
>
> A summary of the changes in this version is included at
> the end of this message.
>
> Please review this document and provide any comments on
> the existing requirements or suggestions for new ones.
>
> For requirement 3, Vishwas will be starting an email
> thread soon so that the WG can discuss what this text
> means, whether we want to keep it, and how it can be
> made clearer.
>
> Thanks,
>
> Steve
>
> ------------
>
> Summary of Changes in draft-ietf-ipsecme-ad-vpn-00.txt
>
> * Changed draft name from p2p-vpn to ad-vpn.
>
> * Added a paragraph for each requirement, explaining how
>  that requirement is driven by the use cases.
>
> * In requirement 1, defined what we mean by minimizing
>  configuration changes.
>
> * In requirement 2, explained that this requirement implies
>  that SPD entries and other configuration based on peer
>  IP address will need to be automatically updated when
>  the peer's IP address changes.
>
> * Split requirement 4 into two requirements (now 4 and 5).
>
> * In requirement 6 (formerly 5), explained what we mean
>  by "easy handoff of sessions": avoid TCP session breakage
>  and packet loss, when possible.
>
> * In requirement 8 (formerly 7), acknowledged the difficulty
>  of handling cases where gateways are behind NATs or where
>  two endpoints are both behind separate NATs. In those cases,
>  we may need to use workarounds such as port forwarding by
>  the NATs or falling back to a hub and spoke architecture.
>
> * Added new requirement 9 around manageability.
>
> * Added new requirement 10 around cross-organization use.
>
> * Added new requirement 11 saying that administrators should
>  be able to limit topologies for security and other reasons.
>
> * Fixed typos and other minor wording issues.
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

****************************************************************************
Communications with GCHQ may be monitored and/or recorded 
for system efficiency and other lawful purposes. Any views or 
opinions expressed in this e-mail do not necessarily reflect GCHQ 
policy.  This email, and any attachments, is intended for the 
attention of the addressee(s) only. Its unauthorised use, 
disclosure, storage or copying is not permitted.  If you are not the
intended recipient, please notify [email-masked].  

This information is exempt from disclosure under the Freedom of 
Information Act 2000 and may be subject to exemption under
other UK information legislation. Refer disclosure requests to 
GCHQ on 01242 221491 ext 30306 (non-secure) or email
[email-masked]

****************************************************************************

The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 17 Oct 2012 09:51:40 -0700

Hi Chris,

Thanks a lot for your comments, my points inline:

On Wed, Oct 17, 2012 at 7:47 AM, Ulliott, Chris <
[email-masked]> wrote:

> I think the Gateway to gateway use case (para 2.2) doesn't cover the
> problem I'm suffering.  What if the use case was reworded such that it says
> something along the lines of:
>
> -- start --
>
> A typical Enterprise traffic model is hub and spoke, with the gateways
> connecting to each other using IPsec tunnels.
>
> However for the voice and other rich media traffic that occupies a lot of
> bandwidth or is performance sensative, the traffic tromboning to the hub
> can create traffic bottlenecks on the hub and can lead to an increase in
> cost.  A fully meshed solution is would make best use of the available
> network capacity and performance but the deployment of a fully meshed
> solution involves considerable configuration, especially when a large
> number of nodes are involved.  For the reasons of cost and manual error
> reduction, it is desired that there be minimal configuration on each
> gateway.

VM> I agree adding the point of Full mesh having more configuration is an
issue and will add it to the text. However another issue we see is that in
a Full Mesh we need connectivity between all nodes which means that the
weakest link is the Branch device, that is another reason we have a hub and
spoke with the mesh cross connections on demand.

It is highly desirable that the solution works where the endpoints are
administrated by separate management domains, albeit, ones that have an
existing trust relationship (for example two organisations who are
collaborating on a project, they may wish to join their networks, whilst
retaining independent control over configuration)
VM> I agree we should state this in the requirement explicitly and is
critical to the solution.

When two gateways communicate, they must use a mechanism for
authentication, such that they do not expose themselves to the risk of
impersonation by the other entities.
VM> Sounds good.

-- end --

In section 3.2, it would be nice if we could again mention that rather
looking for a solution that makes a star architecture work, actually
enables a dynamic, fully meshed solution to be practical.
VM> Agree.We call it star with temporary mesh connection, I agree we can
call it dynamic mesh connectivity instead.

In section 4.1, there are comments about minimising the configuration
changes... should we word this a bit stronger and say that after initial
configuration, there should be no need for a manual configuration change as
devices (endpoint or gateways) are added, removed or changed?
VM> I am ok with that, my point was we need to configure profiles when a
device is added, we do not need to reconfigure if we find devices of the
same profile.

For the use case where end points need to find the optimum gateway to
connect to, do we need a requirement that enables an endpoint to identify
which is the best gateway to connect to, the nearest may not be the best,
depending on the network cost behind the gateway... but this may be
complicating the problem too much.
VM> I think the problem of network cost is that of routing. We need a way
for policy to determine when to transfer a connection from one gateway to
another. The solution should allow for such signalling though.

Thoughts?
VM> Great comments, which I can see come from real world usecases.

Thanks,
Vishwas
Chris

> This appeared on the list over two weeks ago and it has received no
> comments since. This is supposed to be the WG's main work item, folks.
>
> --Paul Hoffman
>
> The original of this email was scanned for viruses by the Government
> Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide
> in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On
> leaving the GSi this email was certified virus free.

---

From: "Ulliott, Chris" <[email-masked]>
Date: Thu, 18 Oct 2012 18:04:20 +0100

For my scenario, having hub and spoke doesn't really work.  What happens with multiple organisations, do they each have a hub? - how do they communicate between them.  I'd like to set the challenge of trying to do full mesh - it may be that we need a mechanism that notifies gateways if one has gone rogue, but that doesn't necessarily require a hub and spoke architecture for the tunnels.

Does that make sense?

Chris
-----Original Message-----
From: Vishwas Manral [mailto:[email-masked]]
Sent: Wednesday, October 17, 2012 5:52 PM
To: Ulliott, Chris
Cc: IPsecme WG
Subject: Re: [IPsec] STRONG NUDGE: Revised AD VPN Requirements

Hi Chris,

On Wed, Oct 17, 2012 at 7:47 AM, Ulliott, Chris <[email-masked]> wrote:

        -- start --

VM> I agree adding the point of Full mesh having more configuration is an issue and will add it to the text. However another issue we see is that in a Full Mesh we need connectivity between all nodes which means that the weakest link is the Branch device, that is another reason we have a hub and spoke with the mesh cross connections on demand.

It is highly desirable that the solution works where the endpoints are administrated by separate management domains, albeit, ones that have an existing trust relationship (for example two organisations who are collaborating on a project, they may wish to join their networks, whilst retaining independent control over configuration)
VM> I agree we should state this in the requirement explicitly and is critical to the solution.

-- end --

In section 3.2, it would be nice if we could again mention that rather looking for a solution that makes a star architecture work, actually enables a dynamic, fully meshed solution to be practical.
VM> Agree.We call it star with temporary mesh connection, I agree we can call it dynamic mesh connectivity instead.

In section 4.1, there are comments about minimising the configuration changes... should we word this a bit stronger and say that after initial configuration, there should be no need for a manual configuration change as devices (endpoint or gateways) are added, removed or changed?
VM> I am ok with that, my point was we need to configure profiles when a device is added, we do not need to reconfigure if we find devices of the same profile.

For the use case where end points need to find the optimum gateway to connect to, do we need a requirement that enables an endpoint to identify which is the best gateway to connect to, the nearest may not be the best, depending on the network cost behind the gateway... but this may be complicating the problem too much.
VM> I think the problem of network cost is that of routing. We need a way for policy to determine when to transfer a connection from one gateway to another. The solution should allow for such signalling though.

Thoughts?

Thanks,
Vishwas
Chris

        -----Original Message-----
        From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
        Sent: Saturday, September 08, 2012 5:31 PM
        To: IPsecme WG
        Subject: [IPsec] STRONG NUDGE: Revised AD VPN Requirements

        --Paul Hoffman

This email was received from the INTERNET and scanned by the Government Secure Intranet anti-virus service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) In case of problems, please call your organisation's IT Helpdesk.
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.