Re: [IPsec] Please Review Changes to AD VPN Problem Statement

[Stephen Hanna]

Tero,

Thanks for your additional suggestions. I agree with
those also. I will post a revised draft shortly
containing the text that we have agreed upon.

Take care,

Steve

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Tero Kivinen
> Sent: Monday, April 22, 2013 8:09 AM
> To: Stephen Hanna
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] Please Review Changes to AD VPN Problem Statement
> 
> Stephen Hanna writes:
> > I agree with you that requirement 5 as currently worded
> > is too strict. We don't want to end up with a situation
> > where no ADVPN peers can participate in the establishment
> > of the ADVPN! On the other hand, we want to limit the
> > effects of the compromise of an endpoint because endpoint
> > compromise (not gateway compromise) is a common occurrence.
> > A compromised endpoint shouldn't be able to impersonate
> > other peers.
> 
> I agree.
> 
> > You proposed this text:
> >
> > > Any of the ADVPN peers MUST NOT have a way to get the long
> > > term authentication credentials for any other ADVPN peers.
> >
> > I think that's correct. But I also think we want to say:
> >
> > > The compromise of an Endpoint MUST NOT affect the security
> > > of communications between other Peers.
>   ^ => ADVPN Peers
> 
> > Are you OK with replacing the current text for requirement 5
> > with those two sentences? I think that will preserve the
> > essence of the requirement without making it too strict.
> 
> I am ok with those two sentences. Note, that Endpoint does not include
> gateways, so the second sentence does not cover the compromize of the
> Spokes. I would even add text saying that "The compromize of an
> Gateway SHOULD NOT affect the security of the communications between
> ADVPN Peers not associated with that Gateway". That last one cannot
> easily be MUST NOT, as compromised gateway might be able to do all
> kind of tricks to affect the security of other ADVPN Peers, for
> example it can try to get the other ADVPN Peers to change their
> current Gateway to himself and then it will be able to comprimise
> them. Some of those we can protect, but plugging all possible holes
> might end up very hard. For example it might be impossible to make so
> that the ADVPN Peer who has been out of network for a while, will not
> connect back to that compromized Gateway...
> --
> kivi...@iki.fi
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Please Review Changes to AD VPN Problem Statement

[Stephen Hanna]

Tero,

I agree with you that requirement 5 as currently worded
is too strict. We don't want to end up with a situation
where no ADVPN peers can participate in the establishment
of the ADVPN! On the other hand, we want to limit the
effects of the compromise of an endpoint because endpoint
compromise (not gateway compromise) is a common occurrence.
A compromised endpoint shouldn't be able to impersonate
other peers.

You proposed this text:

> Any of the ADVPN peers MUST NOT have a way to get the long
> term authentication credentials for any other ADVPN peers.

I think that's correct. But I also think we want to say:

> The compromise of an Endpoint MUST NOT affect the security
> of communications between other Peers.

Are you OK with replacing the current text for requirement 5
with those two sentences? I think that will preserve the
essence of the requirement without making it too strict.

Thanks,

Steve


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Please Review Changes to AD VPN Problem Statement

[Stephen Hanna]

I have posted a new version of the AD VPN Problem
Statement that adds clarifying text to requirements
6 and 7, as suggested by Tero. Please review and
comment. Is everyone (especially Tero) OK with the
new text?

The new draft is available at

https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem

Since the changes are few, it may be easier for you
to look at the diff linked to here:

http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ad-vpn-problem-05

Thanks,

Steve

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of internet-dra...@ietf.org
> Sent: Monday, April 08, 2013 10:54 PM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ad-vpn-problem-05.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the IP Security Maintenance and
> Extensions Working Group of the IETF.
> 
>   Title   : Auto Discovery VPN Problem Statement and
> Requirements
>   Author(s)   : Steve Hanna
>   Vishwas Manral
>   Filename: draft-ietf-ipsecme-ad-vpn-problem-05.txt
>   Pages   : 11
>   Date: 2013-04-08
> 
> Abstract:
>This document describes the problem of enabling a large number of
>systems to communicate directly using IPsec to protect the traffic
>between them.  It then expands on the requirements, for such a
>solution.
> 
>Manual configuration of all possible tunnels is too cumbersome in
>many such cases.  In other cases the IP address of endpoints change
>or the endpoints may be behind NAT gateways, making static
>configuration impossible.  The Auto Discovery VPN solution will
>address these requirements.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-05
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ad-vpn-problem-05
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Revised AD VPN Requirements

[Stephen Hanna]

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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #212: Section 2.2 should be more detailed.

[Stephen Hanna]

Yes, I agree. I'll rewrite the text to remove acronyms and
make the style match the rest of the document.

Thanks,

Steve 

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Paul Hoffman
> Sent: Sunday, March 25, 2012 5:48 AM
> To: IPsecme WG
> Subject: Re: [IPsec] [ipsecme] #212: Section 2.2 should be more
> detailed.
> 
> On Mar 21, 2012, at 2:29 AM, Stephen Hanna wrote:
> 
> > In a simple use case we want hub and spoke topology for say
> > the DC and the branches. This would also be true of ATM's
> > connecting to their DC.
> >
> > However for scalability reasons we would not want all traffic
> > to go through the hub. In the ATM example we could want VoIP
> > session to bypass the DC and have a direct connectivity between
> > themselves. There are multiple other uses cases for the same.
> > These new sessions however are temporary, when compared to
> > permanent branch to hub connections.
> 
> 
> Neither ATM nor DC are defined in the current document. It would be
> better not to introduce new acronyms for a single use case.
> 
> --Paul Hoffman
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

[Stephen Hanna]

If that's the topic, we already have an issue (#213) for it.

Let's see if MCR will clarify what he meant here.

Thanks,

Steve

> -Original Message-
> From: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
> Sent: Wednesday, March 21, 2012 7:04 PM
> To: Yoav Nir
> Cc: Stephen Hanna; IPsecme WG
> Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out
> completely or just punt endpoints to a closer gateway?
> 
> Hi Steve, Yoav,
> 
> I don't want to speak for MCR, but I think you are taking his question
> too far towards the implementation aspects. What I read in the question
> is, do we allow for a situation where (by policy and/or because of
> limitations in the solution) an endpoint cannot connect directly to the
> ultimate peer, but needs instead to go through some sort of relay.
> 
> Given this reading of the issue, I think this is something that's still
> at the requirements level and we should agree whether we want it as an
> actual requirement.
> 
> Thanks,
>   Yaron
> 
> On 03/21/2012 11:33 PM, Yoav Nir wrote:
> > I agree that this pre-supposes that the solution will involve
> "gateways"
> > figuring things out for "endpoints" in either one step or more than
> one
> > step. It pre-supposes a two-tier system.
> >
> > We've had a presentation in Taipei that did not involve gateways, but
> > rather specialized servers carrying authoritative information, with
> all
> > the IPsec hosts, whether gateways or endpoints querying those
> servers.
> > Those servers could be specialized IPsec information servers,
> dispensing
> > PAD and SPD entries through a web service, or they could be the DNS
> > system. Either way, this is a different model to the one that has the
> > information flowing through the overlay network.
> >
> > So I agree that answering this question is pre-mature. Whatever the
> > model, there will be an equivalent question, but I think it's too
> early now.
> >
> > Yoav
> >
> > On Mar 21, 2012, at 9:59 PM, Stephen Hanna wrote:
> >
> >> Again, this issue was based on Michael Richardson's March 12 email,
> >> which said:
> >> The dual trunk scenario should perhaps be further motivated and
> >> clarified. Are there some situations where a spoke should not
> contact
> >> another spoke directly, but in fact should contact a hub closer to
> the
> >> other spoke. I can see some solutions where a hub would not have
> >> complete knowledge of the mesh, and so would in fact simply punt a
> >> connection closer.
> >> I hope this clarifies the issue for you.
> >> I think that Michael is asking an important question. There are many
> >> ways to solve the P2P VPN problem. One way is to have satellites
> with
> >> little configuration that connect to core gateways with lots of
> >> dynamic information. A core gateway (a "hub" in Michael's parlance)
> >> can download things to a satellite (maybe a new SPD and PAD,
> >> credentials, etc.), thus causing some traffic from the satellite to
> be
> >> sent to a different core gateway or satellite. In that circumstance,
> I
> >> think Michael's question is about whether the core gateway that a
> >> satellite initially connects (which I'll call the "initial core
> >> gateway") to should be expected to have or obtain all the
> information
> >> needed to configure the satellite or whether the initial core
> gateway
> >> can send the satellite to another core gateway where it can get more
> >> information. At least, that's how I understand Michael's question.
> >> Perhaps he can affirm or deny this interpretation.
> >> Personally, I think that this question is premature. It presupposes
> >> too much about the eventual solution. That's why I think it should
> be
> >> answered in the solution not included in the problem statement.
> >> Apparently, Yaron doesn't agree with me. I'd like to hear more from
> >> him on this matter. Does he believe that all solutions to this
> problem
> >> (or at least all the good ones) must necessarily employ the model
> that
> >> I described above? What about a solution that doesn't rely on core
> >> gateways to refer satellites but instead has satellites querying for
> >> the information that they need? Or one that has some external entity
> >> (not the core gateway) configuring the satellites? In my view, there
> >> may be many possible P2P VPN solutions. How

Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

[Stephen Hanna]

Again, this issue was based on Michael Richardson's March 12 email, which said:

The dual trunk scenario should perhaps be further motivated and
clarified.  Are there some situations where a spoke should not contact
another spoke directly, but in fact should contact a hub closer to the
other spoke.  I can see some solutions where a hub would not have
complete knowledge of the mesh, and so would in fact simply punt a
connection closer.

I hope this clarifies the issue for you.

I think that Michael is asking an important question. There are many ways to 
solve the P2P VPN problem. One way is to have satellites with little 
configuration that connect to core gateways with lots of dynamic information. A 
core gateway (a "hub" in Michael's parlance) can download things to a satellite 
(maybe a new SPD and PAD, credentials, etc.), thus causing some traffic from 
the satellite to be sent to a different core gateway or satellite. In that 
circumstance, I think Michael's question is about whether the core gateway that 
a satellite initially connects (which I'll call the "initial core gateway") to 
should be expected to have or obtain all the information needed to configure 
the satellite or whether the initial core gateway can send the satellite to 
another core gateway where it can get more information. At least, that's how I 
understand Michael's question. Perhaps he can affirm or deny this 
interpretation.

Personally, I think that this question is premature. It presupposes too much 
about the eventual solution. That's why I think it should be answered in the 
solution not included in the problem statement. Apparently, Yaron doesn't agree 
with me. I'd like to hear more from him on this matter. Does he believe that 
all solutions to this problem (or at least all the good ones) must necessarily 
employ the model that I described above? What about a solution that doesn't 
rely on core gateways to refer satellites but instead has satellites querying 
for the information that they need? Or one that has some external entity (not 
the core gateway) configuring the satellites? In my view, there may be many 
possible P2P VPN solutions. However, I'm not an IPsec expert. Maybe this is the 
only practical approach. I'd like to hear views from Yaron and from others on 
this topic.

Thanks,

Steve

From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of 
Vishwas Manral
Sent: Wednesday, March 21, 2012 3:18 PM
To: Stephen Hanna
Cc: IPsecme WG
Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out 
completely or just punt endpoints to a closer gateway?

Hi Steve,

This is unclear to me. Isn't it routing that we send a packet across to a 
closer gateway/ router? What does everything mean in the question below?

If we are talking about say security and routing, I think that is true. The 
"logical" gateway (could be multiple interactions and devices) should be able 
to provide the functionality.

Thanks,
Vishwas
On Tue, Mar 20, 2012 at 6:33 PM, Stephen Hanna 
mailto:sha...@juniper.net>> wrote:
Please comment on Suggested Resolution. Note that Yaron has
already supplied his comment below.

Steve

-Original Message-
From: ipsecme issue tracker 
[mailto:t...@tools.ietf.org<mailto:t...@tools.ietf.org>]
Sent: Tuesday, March 20, 2012 6:59 PM
To: yaronf.i...@gmail.com<mailto:yaronf.i...@gmail.com>; 
draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org<mailto:draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org>
Subject: [ipsecme] #214: Should gateways figure things out completely or just 
punt endpoints to a closer gateway?

#214: Should gateways figure things out completely or just punt endpoints to a
closer gateway?

 Suggested Resolution: We should not specify this in the problem statement.
 It should be specified in the solution.

 YS: sounds like a requirements-level question to me.

--
-+-
 Reporter:  |  Owner:  draft-ietf-ipsecme-p2p-vpn-
 yaronf.ietf@...  |  problem@...
 Type:  defect  | Status:  new
 Priority:  normal  |  Milestone:
 Component:  p2p-vpn-|   Severity:  -
 problem|   Keywords:
Resolution:  |
-+-

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/214#comment:1>
ipsecme <http://tools.ietf.org/ipsecme/>

___
IPsec mailing list
IPsec@ietf.org<mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint

[Stephen Hanna]

This issue was based on Michael Richardson's March 12, 2012 email where he said:

Finally, say my laptop is normally part of such a mesh (as a /32,/128
subnet).  When I'm "trapped" behind a NAPT, I naturally use
NAT-traversal to get out and join the MESH.

Now, what happens if I come to the office, which is itself part of the
MESH. This is not a new problem, btw, but normally I have only a single
tunnel to bring up or down.  Now that I have all these tunnels and
policy.  Should any of this MESH continue to be used?
Are there some non-convex topologies where this can be important (should
some traffic be double encrypted as a result?), or is it all just out of
scope.   (We dealt with these things as implementation challenges when
combining an extruded IPsec tunnel with RFC4322.  We had
co-terminal tunnels of the near kind, which was solved, and co-terminal
tunnels of the far kind, which we did not manage to implement)

For the above, consider a laptop/tablet which might now have multiple
exit routes via 3G+wifi+wired...  and that it's moving.

I hope that helps clarify the issue. If not, perhaps you and Michael can 
clarify and discuss it further.

Thanks,

Steve

From: Vishwas Manral [mailto:vishwas.i...@gmail.com]
Sent: Wednesday, March 21, 2012 3:23 PM
To: Stephen Hanna
Cc: IPsecme WG
Subject: Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint

Hi Steve,

Branch routers have 3G/ 4G interfaces as backups for the primary interface and 
sometimes even multiple 3G/ 4G interfaces with no wired interface at all to the 
backend.

I however do not see any issue that occurs as a result of this. Currently if an 
interface goes down the tunnel is torn down. Is the question about bonding the 
multiple interfaces instead?

Thanks,
Vishwas
On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna 
mailto:sha...@juniper.net>> wrote:
Another issue. Please comment.

And don't miss Yaron's comment below.

Thanks,

Steve

-Original Message-
From: ipsecme issue tracker 
[mailto:t...@tools.ietf.org<mailto:t...@tools.ietf.org>]
Sent: Tuesday, March 20, 2012 6:57 PM
To: yaronf.i...@gmail.com<mailto:yaronf.i...@gmail.com>; 
draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org<mailto:draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org>
Subject: [ipsecme] #216: Multiple interfaces or mobile endpoint

#216: Multiple interfaces or mobile endpoint

 What if an endpoint has multiple interfaces and/or is mobile?
 Which tunnels should be torn down as this endpoint moves around,
 sometimes behind a gateway and sometimes not?

 Suggested Resolution: We should not specify this in the problem
 statement. It should be specified in the solution.

 YS: sounds like a requirement question to me. In fact we may be
 able to simplify things by making this issue an explicit non-goal.

--
-+-
 Reporter:  |  Owner:  draft-ietf-ipsecme-p2p-vpn-
 yaronf.ietf@...  |  problem@...
 Type:  defect  | Status:  new
 Priority:  normal  |  Milestone:
 Component:  p2p-vpn-|   Severity:  -
 problem|   Keywords:
Resolution:  |
-+-

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/216#comment:1>
ipsecme <http://tools.ietf.org/ipsecme/>

___
IPsec mailing list
IPsec@ietf.org<mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [ipsecme] #221: IPsec architecture and proprietary approaches

[Stephen Hanna]

Here's the last issue for now. If you think that I missed any,
please let me know and we'll get them added.

Thanks,

Steve

-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org] 
Sent: Tuesday, March 20, 2012 7:06 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #221: IPsec architecture and proprietary approaches

#221: IPsec architecture and proprietary approaches

 In section 3.3, we should say that proprietary approaches may not
 implement all the checks in the IPsec architecture.

 Suggested Resolution: Add this to section 3.3.

-- 
-+-
 Reporter:   |  Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…  |  problem@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  p2p-vpn- |   Severity:  -
  problem|
 Keywords:   |
-+-

Ticket URL: 
ipsecme 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [ipsecme] #218: Exhaustive configuration

[Stephen Hanna]

Keeping you entertained in the week before IETF 83...

Steve

-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org] 
Sent: Tuesday, March 20, 2012 7:03 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #218: Exhaustive configuration

#218: Exhaustive configuration

 Exhaustive configuration can work fine if there are good automated
 configuration protocols.

 Suggested Resolution: Exhaustive configuration doesn't scale for
 constrained devices in large networks. Explain this in section 3.1.

-- 
-+-
 Reporter:   |  Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…  |  problem@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  p2p-vpn- |   Severity:  -
  problem|
 Keywords:   |
-+-

Ticket URL: 
ipsecme 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [ipsecme] #220: Sec. 3.2: dangling paragraph

[Stephen Hanna]

Another one.

Steve

-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org] 
Sent: Tuesday, March 20, 2012 7:05 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #220: Sec. 3.2: dangling paragraph

#220: Sec. 3.2: dangling paragraph

 The last paragraph of section 3.2 doesn't belong in that section.

 Suggested Resolution: Delete that paragraph.

-- 
-+-
 Reporter:   |  Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…  |  problem@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  p2p-vpn- |   Severity:  -
  problem|
 Keywords:   |
-+-

Ticket URL: 
ipsecme 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [ipsecme] #219: Star topology as an admin choice

[Stephen Hanna]

Please comment.

Steve

-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org] 
Sent: Tuesday, March 20, 2012 7:04 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #219: Star topology as an admin choice

#219: Star topology as an admin choice

 Some admins prefer a star topology so they can inspect traffic. They may
 not want to use this technology.

 Suggested Resolution: Mention this in the Security Considerations section.

-- 
-+-
 Reporter:   |  Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…  |  problem@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  p2p-vpn- |   Severity:  -
  problem|
 Keywords:   |
-+-

Ticket URL: 
ipsecme 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [ipsecme] #217: Temporary credentials

[Stephen Hanna]

Another issue to comment on.

Steve

-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org] 
Sent: Tuesday, March 20, 2012 7:01 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #217: Temporary credentials

#217: Temporary credentials

 Endpoints may require temporary credentials in order to establish a secure
 connection to another endpoint.

 Suggested Resolution: Put this in the requirements section.

-- 
-+-
 Reporter:   |  Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…  |  problem@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  p2p-vpn- |   Severity:  -
  problem|
 Keywords:   |
-+-

Ticket URL: 
ipsecme 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint

[Stephen Hanna]

Another issue. Please comment.

And don't miss Yaron's comment below.

Thanks,

Steve

-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org] 
Sent: Tuesday, March 20, 2012 6:57 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #216: Multiple interfaces or mobile endpoint

#216: Multiple interfaces or mobile endpoint

 What if an endpoint has multiple interfaces and/or is mobile?
 Which tunnels should be torn down as this endpoint moves around,
 sometimes behind a gateway and sometimes not?

 Suggested Resolution: We should not specify this in the problem
 statement. It should be specified in the solution.

 YS: sounds like a requirement question to me. In fact we may be
 able to simplify things by making this issue an explicit non-goal.

-- 
-+-
  Reporter:  |  Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…  |  problem@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  p2p-vpn-|   Severity:  -
  problem|   Keywords:
Resolution:  |
-+-

Ticket URL: 
ipsecme 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [ipsecme] #215: Should traffic flow through the gateway while a shortcut is being established?

[Stephen Hanna]

Another issue. Please comment.

Steve

-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org] 
Sent: Tuesday, March 20, 2012 7:00 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: Re: [ipsecme] #215: Should traffic flow through the gateway while a 
shortcut is being established?

#215: Should traffic flow through the gateway while a shortcut is being
established?

 Suggested Resolution: We should not specify this in the problem statement.
 It should be specified in the solution.

-- 
-+-
  Reporter:  |  Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…  |  problem@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  p2p-vpn-|   Severity:  -
  problem|   Keywords:
Resolution:  |
-+-

Ticket URL: 
ipsecme 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

[Stephen Hanna]

Please comment on Suggested Resolution. Note that Yaron has
already supplied his comment below.

Steve

-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org] 
Sent: Tuesday, March 20, 2012 6:59 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #214: Should gateways figure things out completely or just 
punt endpoints to a closer gateway?

#214: Should gateways figure things out completely or just punt endpoints to a
closer gateway?

 Suggested Resolution: We should not specify this in the problem statement.
 It should be specified in the solution.

 YS: sounds like a requirements-level question to me.

-- 
-+-
  Reporter:  |  Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…  |  problem@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  p2p-vpn-|   Severity:  -
  problem|   Keywords:
Resolution:  |
-+-

Ticket URL: 
ipsecme 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible

[Stephen Hanna]

Another issue. Please comment on Suggested Resolution.

Thanks,

Steve

-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org] 
Sent: Tuesday, March 20, 2012 6:58 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint 
connectivity may not be possible

#213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be
possible

 In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible
 if both endpoints are NATed.

 Suggested Resolution: Mention this in section 2.1.

-- 
-+-
  Reporter:  |  Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…  |  problem@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  p2p-vpn-|   Severity:  -
  problem|   Keywords:
Resolution:  |
-+-

Ticket URL: 
ipsecme 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [ipsecme] #212: Section 2.2 should be more detailed.

[Stephen Hanna]

Third issue.

Steve

-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org] 
Sent: Tuesday, March 20, 2012 6:57 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #212: Section 2.2 should be more detailed.

#212: Section 2.2 should be more detailed.

 Suggested Resolution: Expand use case using text supplied by
 Vishwas Manral of HP.

 In a simple use case we want hub and spoke topology for say
 the DC and the branches. This would also be true of ATM's
 connecting to their DC.

 However for scalability reasons we would not want all traffic
 to go through the hub. In the ATM example we could want VoIP
 session to bypass the DC and have a direct connectivity between
 themselves. There are multiple other uses cases for the same.
 These new sessions however are temporary, when compared to
 permanent branch to hub connections.

-- 
-+-
  Reporter:  |  Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…  |  problem@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  p2p-vpn-|   Severity:  -
  problem|   Keywords:
Resolution:  |
-+-

Ticket URL: 
ipsecme 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] FW: [ipsecme] #211: We should talk more about why this is a hard problem.

[Stephen Hanna]

Second issue. Please comment on the suggested resolution.

Thanks,

Steve

-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org] 
Sent: Tuesday, March 20, 2012 6:49 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #211: We should talk more about why this is a hard problem.

#211: We should talk more about why this is a hard problem.

 This topic came up several times in different ways: we should talk about
 gaps, we should say more clearly why this is hard, etc.

 Suggested Resolution: Add a Requirements section that lays out the hard
 (or not so hard) problems that any solution must address.

-- 
-+-
 Reporter:   |  Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…  |  problem@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  p2p-vpn- |   Severity:  -
  problem|
 Keywords:   |
-+-

Ticket URL: 
ipsecme 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] First Batch of P2P VPN Issues

[Stephen Hanna]

With Yaron's help, I have reviewed all the email traffic
regarding draft-ietf-ipsecme-p2p-vpn-problem-00.txt and
created tickets for all the issues in the ipsecme trac
database, including a proposed resolution for each issue.

Although you can access the issues online through the
trac database, the best way to discuss them and reach
consensus on an appropriate resolution is via email.
Therefore, I will start an email thread for each issue.
Please respond on that thread if you have a comment
on that issue. If you agree with the proposed resolution,
that's good to know also.

Let's try to reach consensus on as many issues as
possible this week. That will let us focus on the
few thorny issues at next week's ipsecme meeting.
If we close out all these issues, we can move on
to focus on requirements at the meeting.

So look out for 12 emails from me, starting new
threads on the 12 issues listed in the tracker.
I have been warned that mailman may rate limit
my emails to the list so if it takes a few hours
for my emails to arrive, don't despair. You can
respond to the first ones while waiting for the
last few.

Thanks,

Steve

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [ipsecme] #210: What should we call this effort?

[Stephen Hanna]

Here's the first issue. So far, it has been the most
contentious one! Interesting that it's the least
technical issue. H.

Anyway, if you're not happy with the proposed resolution,
please suggest another. And if you support this idea,
please say so.

Thanks,

Steve

-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org] 
Sent: Tuesday, March 20, 2012 6:44 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #210: What should we call this effort?

#210: What should we call this effort?

 Many names were suggested but no consensus has emerged. The most popular
 candidate so far is "Auto Mesh VPN".

 Suggested Resolution: Choose Auto Mesh VPN unless another more popular
 name emerges on the email list by the end of IETF 83.

-- 
-+-
 Reporter:   |  Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…  |  problem@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  p2p-vpn- |   Severity:  -
  problem|
 Keywords:   |
-+-

Ticket URL: 
ipsecme 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] P2P VPN draft UNCLASSIFIED

[Stephen Hanna]

I'm concerned that people expect "ad hoc VPN" to include VPN connections 
between endpoints with no prior trust relationship.

Thanks,

Steve

From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Mark 
Boltz
Sent: Monday, March 19, 2012 2:12 PM
To: IPsecme WG
Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED

I agree that the meshing becomes messy. And thus, Yoav's comment on partial 
mesh and such is valid.

Since the topology is, in my view, based on the use cases and the problem 
statement as I have understood them, a somewhat nebulous thing, I would offer 
up a very simple term for the goal:

 ad hoc VPN

As that would thus mean a VPN that is "formed, arranged, or done for a 
particular purpose only".

I will endeavor to have more commentary on the draft later this evening.

--
Mark Boltz, CISSP, CISA, NSA-IEM, CSGI
Director, Federal and Mid-Atlantic
e: mark.bo...@stonesoft.com   e: 
fede...@stonesoft.com
p: 866.869.4075   c: 571.246.2233
o: 202.434.8963   f: 703.997.4759
w: http://www.stonesoft.com

1200 G St. NW, Suite 800
Washington, DC 20005-6705

Stonesoft: Network Security. Simplified.

On Mar 19, 2012, at 10:36 AM, Michael Richardson wrote:




"Yoav" == Yoav Nir mailto:y...@checkpoint.com>> writes:
   Yoav> As Tero pointed out, some of the use cases don't end up in a
   Yoav> full mesh, because sometimes administrators really want a
   Yoav> trunk, so the end result could be a mesh among nodes in the
   Yoav> same organization, and a trunk to another. Maybe even a
   Yoav> partial mesh (with "secondary nodes" behind particularly bad
   Yoav> NAT devices connecting to one of many "primary nodes")

I agree.

   Yoav> So perhaps the name should not include the word "mesh". How
   Yoav> about "dynamic discovery VPN" (DD-VPN)?

I offer:
 On-Demand Dynamic VPN  = ODD-VPN.

--
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca 
http://www.sandelman.ottawa.on.ca/ |device driver[
  Kyoto Plus: watch the video 
  then sign the petition.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] P2P VPN draft UNCLASSIFIED

[Stephen Hanna]

On Chris' new use case, I don't think that's a new use case.
I think it's a requirement that spans all the use cases. The
solution must be able to handle network topology changes.
But we're not into requirements yet. Use cases first.

Thanks,

Steve

> -Original Message-
> From: Ulliott, Chris [mailto:chris.ulli...@cesg.gsi.gov.uk]
> Sent: Monday, March 12, 2012 7:16 PM
> To: 'm...@cisco.com'; Stephen Hanna
> Cc: 'ipsec@ietf.org'
> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED
> 
> Classification:UNCLASSIFIED
> 
> Good catch!
> 
> I've also thought of an additional use case, as I extend / change a
> network within a data centre etc, it would be helpful if the crypto
> gateway could learn of the new networks (through routing perhaps) and
> make them available through the encrypted tunnels.
> 
> Chris
> 
> [This message has been sent by a mobile device]
> 
> - Original Message -
> From: Mike Sullenberger [mailto:m...@cisco.com]
> Sent: Monday, March 12, 2012 10:56 PM
> To: sha...@juniper.net 
> Cc: ipsec@ietf.org ; Ulliott, Chris
> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED
> 
> Steve,
> 
> I do not think changing the name to "Dynamic Mesh VPN" is a good idea.
> The first thing that is going to happen is that it is going to be
> shortened to "DMVPN" and then we have conflict with Cisco DMVPN, which
> would be confusing and also "DMVPN" is a registered trademark.  It
> would be best to use some other synonym for "Dynamic Mesh".
> 
> Mike.
> 
> >Upon reflection, I can see how "Point to Point VPNs" is problematic
> >as a description of the problem. Really it's more about dynamically
> >creating SAs so that any endpoint or gateway can communicate directly
> >with any other, as permitted by policy. And how can we do this in a
> >manageable manner in a large-scale environment where endpoints are
> >mobile and configurations and policies change often?
> >
> >So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best.
> >
> >Thanks,
> >
> >Steve
> >
> >> -Original Message-
> >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On
> Behalf
> >> Of Ulliott, Chris
> >> Sent: Wednesday, March 07, 2012 4:53 PM
> >> To: 'ipsec@ietf.org'
> >> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED
> >>
> >> Classification:UNCLASSIFIED
> >>
> >> How about "dynamic mesh VPNs" as a title as I think the dynamic part
> is
> >> key here and probably an important aspect of the use cases.
> >>
> >> Chris
> >>
> >> [This message has been sent by a mobile device]
> >>
> >> - Original Message -
> >> From: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
> >> Sent: Wednesday, March 07, 2012 09:17 PM
> >> To: IPsecme WG 
> >> Subject: [IPsec] P2P VPN draft
> >>
> >> Hi Steve,
> >>
> >> a few initial comments.
> >>
> >>   * The draft is short and clear. Thanks for that!
> >>   * I have a problem with the title (and even more, with the "file
> >> name" of the draft). P2P is usually perceived as peer-to-peer,
> >> which skews the discussion towards one particular use case, that
> >> of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN"
> instead.
> >>   * I am unclear about 2.2: so what if you "suddenly need to
> exchange a
> >> lot of data". How is it different from normal IP traffic load
> >> management? The text is simply too vague here. Ideally, should
> we
> >> expect the traffic to migrate to other gateways? To go directly
> >> between endpoints? To establish priorities on existing gateways?
> >>
> >> Thanks,
> >>
> >>  Yaron
> 
> 
> ++
> | Mike Sullenberger; DSE |
> | m...@cisco.com.:|:.:|:. |
> | Customer Advocacy  CISCO   |
> ++
> 
> ***
> *
> 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 us

Re: [IPsec] P2P VPN draft UNCLASSIFIED

[Stephen Hanna]

Of course, you're right. The acronym DMVPN makes this
a very bad choice. Thanks for pointing that out.

I'll throw out a few ideas here:

Dynamic Direct VPN (DDVPN)
Shortcut VPN (SVPN)
Dynamic Scalable VPN (DSVPN)
Dynamic Efficient VPN (DEVPN)

Other ideas or comments on these are most welcome.

Thanks,

Steve

> -Original Message-
> From: Mike Sullenberger [mailto:m...@cisco.com]
> Sent: Monday, March 12, 2012 6:57 PM
> To: Stephen Hanna
> Cc: ipsec@ietf.org; chris.ulli...@cesg.gsi.gov.uk
> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED
> 
> Steve,
> 
> I do not think changing the name to "Dynamic Mesh VPN" is a good idea.
> The first thing that is going to happen is that it is going to be
> shortened to "DMVPN" and then we have conflict with Cisco DMVPN, which
> would be confusing and also "DMVPN" is a registered trademark.  It
> would be best to use some other synonym for "Dynamic Mesh".
> 
> Mike.
> 
> >Upon reflection, I can see how "Point to Point VPNs" is problematic
> >as a description of the problem. Really it's more about dynamically
> >creating SAs so that any endpoint or gateway can communicate directly
> >with any other, as permitted by policy. And how can we do this in a
> >manageable manner in a large-scale environment where endpoints are
> >mobile and configurations and policies change often?
> >
> >So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best.
> >
> >Thanks,
> >
> >Steve
> >
> >> -Original Message-
> >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On
> Behalf
> >> Of Ulliott, Chris
> >> Sent: Wednesday, March 07, 2012 4:53 PM
> >> To: 'ipsec@ietf.org'
> >> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED
> >>
> >> Classification:UNCLASSIFIED
> >>
> >> How about "dynamic mesh VPNs" as a title as I think the dynamic part
> is
> >> key here and probably an important aspect of the use cases.
> >>
> >> Chris
> >>
> >> [This message has been sent by a mobile device]
> >>
> >> - Original Message -
> >> From: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
> >> Sent: Wednesday, March 07, 2012 09:17 PM
> >> To: IPsecme WG 
> >> Subject: [IPsec] P2P VPN draft
> >>
> >> Hi Steve,
> >>
> >> a few initial comments.
> >>
> >>   * The draft is short and clear. Thanks for that!
> >>   * I have a problem with the title (and even more, with the "file
> >> name" of the draft). P2P is usually perceived as peer-to-peer,
> >> which skews the discussion towards one particular use case, that
> >> of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN"
> instead.
> >>   * I am unclear about 2.2: so what if you "suddenly need to
> exchange a
> >> lot of data". How is it different from normal IP traffic load
> >> management? The text is simply too vague here. Ideally, should
> we
> >> expect the traffic to migrate to other gateways? To go directly
> >> between endpoints? To establish priorities on existing gateways?
> >>
> >> Thanks,
> >>
> >>  Yaron
> 
> 
> ++
> | Mike Sullenberger; DSE |
> | m...@cisco.com.:|:.:|:. |
> | Customer Advocacy  CISCO   |
> ++
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] P2P VPN draft UNCLASSIFIED

[Stephen Hanna]

Upon reflection, I can see how "Point to Point VPNs" is problematic
as a description of the problem. Really it's more about dynamically
creating SAs so that any endpoint or gateway can communicate directly
with any other, as permitted by policy. And how can we do this in a
manageable manner in a large-scale environment where endpoints are
mobile and configurations and policies change often?

So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best.

Thanks,

Steve

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Ulliott, Chris
> Sent: Wednesday, March 07, 2012 4:53 PM
> To: 'ipsec@ietf.org'
> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED
> 
> Classification:UNCLASSIFIED
> 
> How about "dynamic mesh VPNs" as a title as I think the dynamic part is
> key here and probably an important aspect of the use cases.
> 
> Chris
> 
> [This message has been sent by a mobile device]
> 
> - Original Message -
> From: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
> Sent: Wednesday, March 07, 2012 09:17 PM
> To: IPsecme WG 
> Subject: [IPsec] P2P VPN draft
> 
> Hi Steve,
> 
> a few initial comments.
> 
>   * The draft is short and clear. Thanks for that!
>   * I have a problem with the title (and even more, with the "file
> name"
> of the draft). P2P is usually perceived as peer-to-peer, which
> skews
> the discussion towards one particular use case, that of
> endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" instead.
>   * I am unclear about 2.2: so what if you "suddenly need to exchange a
> lot of data". How is it different from normal IP traffic load
> management? The text is simply too vague here. Ideally, should we
> expect the traffic to migrate to other gateways? To go directly
> between endpoints? To establish priorities on existing gateways?
> 
> Thanks,
> 
>  Yaron
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> 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 postmas...@gchq.gsi.gov.uk.
> 
> 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
> info...@gchq.gsi.gov.uk
> 
> ***
> *
> 
> 
> 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.
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Please Comment on New P2P VPN Problem Statement

[Stephen Hanna]

Vishwas,

Thanks for your comments. I'll respond inline below.

1. I guess the problem statement is not just about lessening the number of 
configuration commands but also the fact that static configuration may not work 
in some cases. The spokes may get new addresses every time they come up (using 
DHCP/ PPPoE) and hence the communication end point identifiers change.

SH> Yes, the dynamic nature of configuration data is as much a problem as the 
size of that data.

2. I am not sure but the use cases do not come out very clearly to me. The most 
important part of the communication is of end-sites communicating to the 
gateway hub router. In a typical enterprise deployment that would mean a 
branches connected to the campus/ data center. This tunnel is permanent. Mainly 
to access resources at the back end. There could be redundancy here to provide 
HA.

3. We then optionally require communication between end sites and such 
communication may be temporary or permanent. For such cases we want to be able 
to unburden the gateway so as to not cause overload.

4. We could have multiple gateways work in a cluster mode to serve a set of 
end-sites and to provide HA.

5. The clusters may in turn communicate with each other.

SH> I'm sorry that the use cases are not clear. However, I'm sure we can and 
will improve them.

SH> Your description of "The most important part of the communication" seems to 
be focused only on use case 2.2 in the draft. In your example, several 
"end-sites" need to establish a direct connection to each other instead of 
going through a "gateway hub router". To use the terminology defined in the 
draft, that's a gateway-to-gateway use case. I understand that you consider 
that to be the most important use case but others have previously spoken out 
about the importance of use cases 2.1 and 2.3.

SH> So I do agree with your description of use case 2.2. Maybe we should add 
another example under use case 2.2, based on your example. Could you provide 
more details about why a direct connection between two "end-sites" might be 
needed? I can add that as an example in the next version of the draft.

SH> And thanks for volunteering to participate in formulating the problem 
statement and the solutions. That's great!

Take care,

Steve

From: Vishwas Manral [mailto:vishwas.i...@gmail.com]
Sent: Tuesday, March 06, 2012 5:23 PM
To: Stephen Hanna
Cc: IPsecme WG
Subject: Re: [IPsec] Please Comment on New P2P VPN Problem Statement

Hi Steve,

I agree to the need of standardization for a large scale point-to-point 
solution.

1. I guess the problem statement is not just about lessening the number of 
configuration commands but also the fact that static configuration may not work 
in some cases. The spokes may get new addresses every time they come up (using 
DHCP/ PPPoE) and hence the communication end point identifiers change.

2. I am not sure but the use cases do not come out very clearly to me. The most 
important part of the communication is of end-sites communicating to the 
gateway hub router. In a typical enterprise deployment that would mean a 
branches connected to the campus/ data center. This tunnel is permanent. Mainly 
to access resources at the back end. There could be redundancy here to provide 
HA.

3. We then optionally require communication between end sites and such 
communication may be temporary or permanent. For such cases we want to be able 
to unburden the gateway so as to not cause overload.

4. We could have multiple gateways work in a cluster mode to serve a set of 
end-sites and to provide HA.

5. The clusters may in turn communicate with each other.

We as HP would love to participate in this draft as well as any solution 
document that is produced.

Thanks,
Vishwas
On Tue, Mar 6, 2012 at 1:54 PM, Stephen Hanna 
mailto:sha...@juniper.net>> wrote:
In case you didn't notice, I have posted the -00 version
of the P2P VPN problem statement. The URL is below.
Please review and comment.

I'm especially interested in getting feedback on the
use cases in this document. As previously agreed, they
are based on the use cases in section 2.2 of the
previous problem statement draft. I have tried to
clarify those use cases, especially by providing
definitions of terms and using those terms consistently
throughout the document.

After we reach consensus on the use cases, we can move
on to defining requirements derived from those use cases.
But I see no point in talking about requirements before
we've agreed on a clear description of the problems
that we are trying to solve.

So please review this short document and send comments.

Thanks,

Steve

-Original Message-
From: i-d-announce-boun...@ietf.org<mailto:i-d-announce-boun...@ietf.org> 
[mailto:i-d-announce-boun...@ietf.org<mailto:i-d-announce-boun...@ietf.org>] On 
Behalf Of internet-dra...@ietf.org<mailto:int

[IPsec] Please Comment on New P2P VPN Problem Statement

[Stephen Hanna]

In case you didn't notice, I have posted the -00 version
of the P2P VPN problem statement. The URL is below.
Please review and comment.

I'm especially interested in getting feedback on the
use cases in this document. As previously agreed, they
are based on the use cases in section 2.2 of the
previous problem statement draft. I have tried to
clarify those use cases, especially by providing
definitions of terms and using those terms consistently
throughout the document. 

After we reach consensus on the use cases, we can move
on to defining requirements derived from those use cases.
But I see no point in talking about requirements before
we've agreed on a clear description of the problems
that we are trying to solve.

So please review this short document and send comments.

Thanks,

Steve

-Original Message-
From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On 
Behalf Of internet-dra...@ietf.org
Sent: Tuesday, March 06, 2012 11:01 AM
To: i-d-annou...@ietf.org
Cc: ipsec@ietf.org
Subject: I-D ACTION:draft-ietf-ipsecme-p2p-vpn-problem-00.txt

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working 
Group of the IETF.

Title : Point to Point VPNs Problem Statement
Author(s) : S. Hanna
Filename  : draft-ietf-ipsecme-p2p-vpn-problem
Pages : 13 
Date  : March 6, 2012 

   This document describes the problem of enabling a large number of
   systems to communicate directly using IPsec to protect the traffic
   between them.  Manual configuration of all possible tunnels is too
   cumbersome in such cases, so an automated method is needed.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-p2p-vpn-problem

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] NUDGE: Starting work on our new charter items

[Stephen Hanna]

Mark,

Thanks for stepping forward to help with the problem statement
and with reviewing the various drafts. In order to maximize the
open discussion of these drafts, I think it's best to conduct
these discussions on the public ipsec email list. Therefore,
I'll be posting a first draft of the problem statement ASAP
to get some discussion going.

For everyone's reference, the updated ipsecme charter is at
http://datatracker.ietf.org/wg/ipsecme/charter
It now includes this text relating to the scalable VPN work:

-

In an environment with many IPsec gateways and remote clients that share
an established trust infrastructure (in a single administrative domain
or across multiple domains), customers want to get on-demand
point-to-point IPsec capability for efficiency. However, this cannot be
feasibly accomplished only with today's IPsec and IKE due to problems
with address lookup, reachability, policy configuration, and so on.

The IPsecME Working Group will handle this large scale VPN problem by:

* Creating a problem statement document including use cases, definitions
and proper requirements for discovery and updates. This document would
be solution-agnostic.

* Publishing a common solution for the discovery and update problems
that will satisfy the requirements in the problem statement document.
The working group may standardize one of the vendor solutions, a
combination, an superset of such a solution, or a new protocol.

* Reviewing and help publish Informational documents describing current
vendor proprietary solutions.

-

Thanks,

Steve

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Mark Boltz
> Sent: Wednesday, February 08, 2012 11:26 AM
> To: Ulliott, Chris
> Cc: IPsecme WG; Paul Hoffman
> Subject: Re: [IPsec] NUDGE: Starting work on our new charter items
> 
> I will volunteer to help review the drafts and develop the
> requirements. How should we approach that sharing? Google, this list,
> something else? Also, could someone (re-)post the charter with the
> objectives again, I can't seem to find it. Alternatively send to me
> directly off list.
> 
> I look forward to participating.
> 
> --
> Mark Boltz, CISSP, CISA, NSA-IEM, CSGI
> Director, Federal and Mid-Atlantic
> e: mark.bo...@stonesoft.com   e: fede...@stonesoft.com
> p: 866.869.4075   c: 571.246.2233
> o: 202.434.8963   f: 703.997.4759
> w: http://www.stonesoft.com
> 
> 1200 G St. NW, Suite 800
> Washington, DC 20005-6705
> 
> Stonesoft: Network Security. Simplified.
> 
> On Jan 31, 2012, at 7:12 AM, "Ulliott, Chris"
>  wrote:
> 
> > Paul - count me in, am more than happy to contribute and help review
> drafts.  Unfortunately getting to Paris could be challenging, but I'll
> go and talk nicely to the folk who control the purse strings!
> >
> > Chris
> >
> > -Original Message-
> > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On
> Behalf Of Paul Hoffman
> > Sent: Friday, January 27, 2012 4:49 PM
> > To: IPsecme WG
> > Subject: [IPsec] NUDGE: Starting work on our new charter items
> >
> > [[ There has not been enough response yet, by far. ]]
> >
> > We have a new charter. Do we have any volunteers to start work on the
> two documents we committed to work on?
> >
> > Related: we should consider having a face-to-face meeting at the
> upcoming IETF in Paris, but only if there is value for the newly-
> chartered work. In my mind, that means both a first draft submitted
> *and* interesting questions that would benefit from face-to-face
> discussion instead of just work on the list. Do people believe we will
> have that?
> >
> > --Paul Hoffman
> >
> > ___
> > IPsec mailing list
> > IPsec@ietf.org
> > 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 postmas...@gchq.gsi.gov.uk.
> >
> > 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
> > info...@gchq.gsi.gov.uk
> >
> >
> ***
> *
> >
> >
> > 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.

Re: [IPsec] NUDGE: Starting work on our new charter items

[Stephen Hanna]

Paul,

Sorry to be late in responding. I've been working with other
Juniper folks to figure out which of us should volunteer to
edit the P2P VPN problem statement. But never mind about that.

I am willing to edit the P2P VPN problem statement document.
I know that we need to have a draft promptly and get some serious
discussion going on the email list before IETF 83. There are
plenty of interesting questions related to requirements that
we'll want to discuss on the list and in person at IETF 83.

Praveen Sathyanarayan from Juniper has already committed to
write an Informational RFC documenting our current solution.
And I think it's premature to start work on the common
solution before we've agreed on the problem statement or
at least nailed down the main issues. Don't you agree?

Thanks,

Steve

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Paul Hoffman
> Sent: Friday, January 27, 2012 11:49 AM
> To: IPsecme WG
> Subject: [IPsec] NUDGE: Starting work on our new charter items
> 
> [[ There has not been enough response yet, by far. ]]
> 
> We have a new charter. Do we have any volunteers to start work on the
> two documents we committed to work on?
> 
> Related: we should consider having a face-to-face meeting at the
> upcoming IETF in Paris, but only if there is value for the newly-
> chartered work. In my mind, that means both a first draft submitted
> *and* interesting questions that would benefit from face-to-face
> discussion instead of just work on the list. Do people believe we will
> have that?
> 
> --Paul Hoffman
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Large Scale VPN

[Stephen Hanna]

Yes, I definitely think this is a good idea.

Thanks,

Steve

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Yoav Nir
> Sent: Monday, December 12, 2011 4:45 AM
> To: IPsecme WG
> Cc: Paul Hoffman
> Subject: Re: [IPsec] Large Scale VPN
> 
> Hi all
> 
> If we want Paul and Yaron to take this to our AD, we need to show that
> there are more people who think these work items are a good idea. More
> people than just me and MCR.  So please show your support (or
> objections!) soon. An "I think this is a good idea", "I think we should
> use ternary logic", or "+1" is all it takes.
> 
> Yoav
> 
> On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote:
> >
> > Agree. How about:
> >
> > In an environment with many IPsec gateways and remote clients that
> share an established trust infrastructure (in a single administrative
> domain or across multiple domains), customers want to get on-demand
> point-to-point IPsec capability for efficiency. However, this cannot be
> feasibly accomplished only with today's IPsec and IKE due to problems
> with address lookup, reachability, policy configuration, etc.
> >
> > The IPsecME working group will handle this large scale VPN problem by
> delivering the following:
> >
> > * The working group will create a problem statement document
> including use cases, definitions and proper requirements for discovery
> and updates. This document would be solution-agnostic. Should reach WG
> last call around October 2012.
> >
> > * The working group will review and help publish Informational
> documents describing current vendor proprietary solutions. These should
> be ready for IETF last call by August 2012.
> >
> > * The working group will choose a common solution for the discovery
> and update problems that will satisfy the requirements in the problem
> statement document. The working group may standardize one of the vendor
> solutions, a combination, an superset of such a solution, or a new
> protocol.
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Preparing a charter change for P2P VPN

[Stephen Hanna]

The conclusion of Wednesday night's P2P VPN side meeting
was that we would start a new thread on the proposed
ipsecme charter change and resolve the open questions
by email. Let's start off with the text that came out
of Wednesday's meeting and the questions raised there.

The text from the meeting describing the problem to
be solved was:

In an environment with many IPsec gateways and remote
clients that share an established trust infrastructure
(in a single administrative domain or across multiple
domains), customers want to get on-demand mesh IPsec
capability for efficiency. However, this cannot be
feasibly accomplished only with today's IPsec and IKE
due to problems with address lookup, reachability,
policy configuration, etc.

And the main open questions from the meeting were:

* Should we create a problem statement and requirements
  draft?

* Should we create a Standards Track document with
  the solution or just document existing proprietary
  vendor solutions in Informational RFCs?

Please respond to this email with comments on the
problem description text and on the questions.
I think we need to reach consensus on those basic
matters before we can work on final proposed text
for the charter change.

Thanks,

Steve

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Notes from P2P VPN Side Meeting

[Stephen Hanna]

Here are the notes that I took during Wednesday
night's side meeting on P2P VPN. Please send any
corrections to the list.

Thanks,

Steve

--

Notes from November 16, 2011 P2P VPN Side Meeting
at IETF 82

Steve Hanna took notes. He did not duplicate the
slide content but focused on the discussion. The
slides can be found on the ipsec email list.

After a bit of monkeying around with audio and
video issues, Yoav Nir gave a brief presentation
on the Problem Statement draft. This was followed
by equally brief presentations on the Cisco,
Juniper, and Checkpoint solutions for P2P VPN
from Frederic Detienne, Geoff Huang, and Yoav.
Last, Mike Irani gave a presentation on U.S.
Government efforts in this area and Mike Ko
gave a presentation on his ideas for Dynamic
Secure Interconnect (DSI).

Steve displayed some draft language describing
the problem we're trying to solve:

In an environment with many IPsec gateways and remote
clients that share an established trust infrastructure
(single domain or multi-domain), customers want to get
full mesh IPsec connectivity for efficiency. However,
this cannot be feasibly accomplished only with today's
IPsec and IKE due to problems with address lookup,
reachability, policy configuration, etc. We aim to
solve this problem in an interoperable manner using
IPsec and IKE and perhaps other new or existing IETF
standards.

We agreed on a few edits. The parenthetical text about
domains was ambiguous about what kind of domains: trust
domains or administrative domains. We meant administrative
domains so we changed that text to say "in a single
administrative domain or across multiple domains".
We need to specify the ability to create and remove
mesh links as needed so we changed "full mesh IPsec
connectivity" to "on-demand IPsec capability". And
the last sentence is controversial since we haven't
agreed on how this problem should be solved so we
deleted this sentence for now. The resulting text is:

In an environment with many IPsec gateways and remote
clients that share an established trust infrastructure
(in a single administrative domain or across multiple
domains), customers want to get on-demand mesh IPsec
capability for efficiency. However, this cannot be
feasibly accomplished only with today's IPsec and IKE
due to problems with address lookup, reachability,
policy configuration, etc.

This text is not perfect but there did seem to be
a rough consensus in the room that this describes
the problem we want to solve.

Paul Hoffman explained that we have several options
for next steps. We could ask ipsecme to create a
problem statement and requirements document then
move on to solutions. Or we could go straight to
a standards track solutions document. Or we could
just have vendors publish their existing proprietary
solutions as Informational RFCs.

There was a good deal of discussion about the pros
and cons of these various approaches. Yaron Sheffer
and others said that we need a requirements document
since we clearly don't agree on the requirements.
Brian Weis said that this group doesn't do
requirements documents. Paul pointed out that
many vendors only care about interoperability
and value add. Chris Ulliott said his employer
(the U.K. Government) needs to pick a single
vendor-independent standard.

We agreed to take a proposed ipsecme charter change
to the list and eventually to Sean Turner (our AD).
We'll start a new thread on this topic and resolve
the open questions on the charter change by email.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Meeting scheduled: IPsec WG BoF (plain text)

[Stephen Hanna]

The audio streaming in the room is not working so
we'll be using Webex for remote audio. All
presenters and speakers will use headsets or
PC mikes for speaking.

Please join the Webex below and get audio
there.

Thanks,

Steve

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Frederic Detienne
> Sent: Wednesday, November 16, 2011 4:19 AM
> To: ipsec@ietf.org WG
> Subject: [IPsec] Meeting scheduled: IPsec WG BoF (plain text)
> 
> Hi everyone,
> 
> this plain email just in case someone can't read the invite in my
> previous email.
> 
> This email provides instruction to connect to the video bridge that
> will allow us to share documents at the BoF. We will use the audio
> stream in the room.
> 
> If room audio is not available, we will advise accordingly. Please
> check your email 5-10 min before the meeting for possible additional
> audio instructions.
> 
> best regards,
> 
>   fred
> 
> Begin forwarded message:
> >
> > Topic: IPsec WG BoF
> > Date: Wednesday, November 16, 2011
> > Time: 8:00 pm, China Time (Beijing, GMT+08:00)
> > Meeting Number: 201 123 128
> > Meeting Password: NMRhBGcT
> >
> > ---
> > To start the online meeting
> > ---
> > 1. Go to https://cisco.webex.com/cisco/j.php?ED=179670317
> > 2. Log in to your account.
> > 3. Click "Start Now".
> > 4. Follow the instructions that appear on your screen.
> >
> > 
> > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
> > 
> >
> > The affected toll free numbers are: (866) 432-9903 for the San
> Jose/Milpitas area and (866) 349-3520 for the RTP area.
> >
> > Please dial the local access number for your area from the list
> below:
> > -  San Jose/Milpitas (408) area:  525-6800
> > -  RTP (919) area:  392-3330
> >
> > ---
> > To join the teleconference only
> > ---
> > 1. Dial into Cisco WebEx (view all Global Access Numbers at
> > http://cisco.com/en/US/about/doing_business/conferencing/index.html
> > 2. Follow the prompts to enter the Meeting Number (listed above) or
> Access Code followed by the # sign.
> >
> > San Jose, CA: +1.408.525.6800  RTP: +1.919.392.3330
> >
> > US/Canada: +1.866.432.9903  United Kingdom: +44.20.8824.0117
> >
> > India: +91.80.4350.  Germany: +49.619.6773.9002
> >
> > Japan: +81.3.5763.9394  China: +86.10.8515.5666
> >
> > ---
> > For assistance
> > ---
> > 1. Go to https://cisco.webex.com/cisco/mc
> > 2. On the left navigation bar, click "Support".
> > To add this meeting to your calendar program (for example Microsoft
> Outlook), click this link:
> >
> https://cisco.webex.com/cisco/j.php?ED=179670317&UID=482102172&ICS=MS&L
> D=1&RD=2&ST=1&SHA2=9HO7DbLipS1xHA6-QDCAKsyn4lRwIxIqi0uooKshp/c=
> >
> > To check whether you have the appropriate players installed for UCF
> (Universal Communications Format) rich media files, go to
> https://cisco.webex.com/cisco/systemdiagnosis.php
> >
> > http://www.webex.com
> > We've got to start meeting like this(TM)
> >
> > %ConfCallModerator%
> >
> > ---
> > To invite others to join
> > ---
> >
> > Start copying here...
> >
> > Topic: IPsec WG BoF
> > Date: Wednesday, November 16, 2011
> > Time: 8:00 pm, China Time (Beijing, GMT+08:00)
> > Meeting Number: 201 123 128
> > Password: NMRhBGcT
> >
> > ---
> > To join the meeting online
> > ---
> > 1. Go to https://cisco.webex.com/cisco/j.php?ED=179670317&UID=0
> > 2. Enter your name and email address.
> > 3. Enter the meeting password: NMRhBGcT
> > 4. Click "Join".
> > 5. If the meeting includes a teleconference, follow the instructions
> that appear on your screen.
> >
> > ---
> > To join the teleconference only
> > ---
> > Provide your phone number when you join the meeting to receive a call
> back. Or, call the number below and enter the meeting number.
> > Call-in toll-free number (US/Canada): +1-866-432-9903
> > Call-in toll number (US/Canada): +1-408-525-6800
> > Toll-free dialing restrictions:
> http://www.webex.com/pdf/tollfree_restrictions.pdf
> > Access code: 201 123 128
> >
> > Sign up for a free trial of WebEx
> > http://www.webex.com/go/mcemfreetrial
> >
> > IMPORTANT NOTICE: This WebEx service includes a feature that allows
> audio and any documents and other materials exchanged o

Re: [IPsec] P2P VPN - Side Meeting

[Stephen Hanna]

I think we will benefit greatly if we focus tonight's
meeting mainly on discussion of and perhaps agreement
on the PROBLEM TO BE SOLVED.

Comparison and analysis of proposed solutions should
wait until we have agreed on the problem statement
and the requirements derived from that. And, as we've
just seen, it's very hard to have a clear discussion
of different alternative proposals without having
those proposals described in detail as Internet-Drafts.

The goal of the 7 minute presentations of solutions
tonight (as I understand it) is simply to show that
there are some interesting solutions out there, not
to promote comparisons of them. I already regret
the decision to include those solutions on the agenda
since we've now spent lots of time insulting each
others' approaches without actually understanding them.

Please let's skip more shouting matches about solutions
tonight. We don't have enough facts on the table.
Instead, let's focus on discussing which problem
we should be trying to solve.

Thanks,

Steve

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Frederic Detienne
> Sent: Wednesday, November 16, 2011 4:24 AM
> To: Yoav Nir
> Cc: ipsec@ietf.org WG; Tero Kivinen; Mike Sullenberger
> Subject: Re: [IPsec] P2P VPN - Side Meeting
> 
> 
> You are mixing everything up. It is too much work to correct you over
> email. I will try to help you at the meeting.
> 
> regards,
> 
>   fred
> 
> On 16 Nov 2011, at 15:35, Yoav Nir wrote:
> 
> > OK.
> >
> > Routing protocols are not security protocols. That's fine. Neither is
> HTTP.
> >
> > BGPSEC and SIDR implement a layer of security on top of BGP to
> overcome this issue, and that may be used in the Internet.
> >
> > OSPF and NHRP are designed to be used in closed environments
> (corporate networks), where everyone is assumed to be "playing nice",
> so there has never been as much requirement for a security layer, and
> in fact there is no security layer to NHRP.
> >
> > When you extend NHRP to an overlay network over the Internet, as you
> do with GRE, you are still fine as long as everybody "plays nice". With
> the obvious example of a corporate network with tunnels to the branches
> in New York, London, Paris, and Shang-hai you're still fine, because
> all the gateways are configured by the same person or organization, or
> at least they are part of the same hierarchy, although by this point
> you may need to be worried about misconfiguration.
> >
> > With a multiple-administrative-domain use case, all bets are off.
> What would prevent a gateway anywhere from claiming responsibility for
> the addresses of the facebook.com server?  That would cause several bad
> things:
> > - that gateway gets access to all facebook traffic in the entire
> overlay network
> > - all the gateways have to work extra hard encrypting facebook
> content for no reason at all.
> >
> > This is a real problem regardless of whether we use IPsec tunnels or
> GRE tunnels. Neither IKE nor NHRP has a secure routing layer. Whichever
> solution we pick (as a working group) we will still need to develop a
> security layer, which may or may not be based on what the BGP people
> are doing.
> >
> > This is especially important for cross-domain use cases, but would be
> very helpful for same-domain as well.
> >
> > Yoav
> >
> > On Nov 16, 2011, at 3:11 PM, Frederic Detienne wrote:
> >
> >>
> >> Security is a matter of architecture and end-to-end design. Several
> mechanisms are used to achieve an efficient balance with complexity.
> Features and security protocols are only building blocks.
> >>
> >> IPsec and IKE are not the only features that protect a network and
> routing as a security policy really is not a problem until shown
> otherwise.
> >>
> >> Again, I urge you to be specific because there is nothing tangible
> in your claims. I understand what you mean but if you rationalized it,
> you would see your intuition fools you.
> >>
> >>
> >> On 16 Nov 2011, at 14:17, Yoav Nir wrote:
> >>
> >>>
> >>> On Nov 16, 2011, at 1:45 PM, Tero Kivinen wrote:
> >>>
>  Yoav Nir writes:
> >> So you still didn't explain what GRE does better than modern
> IPsec
> >> tunneling?
> >
> > I think GRE (or any tunnel that is not IPsec - like L2TP) allows
> > them to avoid having to deal with RFC 4301 stuff like SPD. The
> only
> > selector they need is for the GRE tunnel (protocol 43?) or the
> L2TP
> > tunnel (UDP 1701).
> 
>  I.e. bypass the security mechanishms provided the security
> protocol.
> >>>
> >>> Yes!
> >>>
> > That means that your security policy is effectively determined by
> > the routing protocol.
> 
>  I.e. move the security from the security protocol to something
> else
>  which is not a security protocol. Is this really something we want
> to
>  do?
> >>>
> >>> Define "we"
> >>>
>  Who is going to make sure the end result is secure?
> >>>
> >>> The customer
> >>>
> >

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

[Stephen Hanna]

I agree. Wednesday night would be best.

Who else is interested in getting together to discuss this? Clearly, there are 
plenty of interesting issues to discuss.

Steve

From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav 
Nir
Sent: Friday, October 28, 2011 10:00 AM
To: Geoffrey Huang; Stephen Hanna
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

Well, there is a free room between 1300-1500 on Wednesday, but then we're 
opposite WebSec, and I can't attend.

Our best bet is to do it after the Plenary. The plenary ends at 19:30, and 
people might want to grab something to eat, so it would probably be best to do 
it at 20:00.

Hope you don't have a flight for Wednesday night...

On 10/26/11 10:19 PM, "Geoffrey Huang" 
mailto:ghu...@juniper.net>> wrote:

I have to agree with the recent comments about the inapplicability of RFC 4322. 
 I don't think that a DNNSEC infrastructure can be assumed, particularly not in 
the deployments I have seen.

I agree with Steve Hanna's comments about the need for ad-hoc peer-to-peer 
VPNs, bypassing a centralized hub.  I also agree with Paul Hoffman's comments 
about using an already-existing "trusted introducer."

Finally, I will be in Taiwan, but specifically (only) to discuss this topic.  
I'm hoping that the date of Wednesday, November 16 is still good for the bar 
BOF that some of us had previously discussed.

-geoff
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

[Stephen Hanna]

I'm concerned about using DNS as the introducer here. Doing this
securely requires DNS records to be updated, signed, and distributed
whenever a new "satellite" gateway or host arrives or departs.
That's cumbersome, expensive, and complex since it requires
interfacing the IPsec and DNSSEC infrastructure and lots of
resigning.

The core IPsec gateway already knows all the information necessary
to establish a secure direct connection between satellites and
there's already a secure connection between the core and the
satellites. Why not use that connection to distribute the information
directly from the core to the satellites?

Whatever technology is decided upon, my employer (Juniper Networks)
sees a need for dynamically established "peer-to-peer" VPNs and
supports efforts to create standards in this area and to get
widespread adoption of those standards.

Thanks,

Steve Hanna

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Yoav Nir
> Sent: Tuesday, October 25, 2011 4:40 AM
> To: 'Michael Richardson'; ipsec@ietf.org
> Cc: Ulliott, Chris
> Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs
> Problem Statement
> 
> Chris' case is a little different, because he is willing to do some
> work to establish trust between the two administrative domains, so it's
> not really opportunistic (although doing it with OE might be a
> solution)
> 
> So there could be some "hub gateway" that could do the introducing,
> perhaps over IPsec or IKE.
> 
> On the one hand, if DNS works and everybody already has a DNS resolver,
> it may be better to use that than to invent a new mechanism. OTOH if I
> didn't like inventing new mechanisms, I wouldn't be participating in
> the IETF.
> 
> 
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Michael Richardson
> Sent: 24 October 2011 16:01
> To: ipsec@ietf.org
> Cc: Ulliott, Chris
> Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs
> Problem Statement
> 
> 
> I was not intending to be, (I have no ticket as yet), but plans might
> change.
> It seems like Chris has all of the requirements of OE, and there is all
> of the challenges.  IPv6 and homenet might well provide FDQNs for
> hosts, and a trusted path to update the reverse.
> 
> If DNS does not work for you, then you need another trusted introducer,
> and there have been many proposals out there for doing this kind of
> thing.  None of taken off and hit the elbow of exponential growth.
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec