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

2012-03-21 Thread yogendra pal 
Why they may not use this technology ? Even today irrespective of the
topology, traffic is intercepted by lawful agencies by using different
mechanism (port mirroring, etc...)

Thanks,
Yogendra Pal
Ericsson, India

On Wed, Mar 21, 2012 at 7:07 AM, Stephen Hanna  wrote:

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

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

2012-03-21 Thread yogendra pal 
I agree to what Yoav stated, that signalling part (SIP) and media part
(RTP) both SHOULD work even if there is NAT in the configuration today.
However, I could not get why we need to have new NAT traversal mechanism
using hub gateway, can you elaborate on this...

Thanks and Regards,
Yogendra Pal
Ericsson, India
+91-9686202644


On Wed, Mar 21, 2012 at 6:49 PM, Yoav Nir  wrote:

> "direct endpoint-to-endpoint connectivity may not be possible if both
> endpoints are NATed"
>
> Why?  There are several protocols (SIP/RTP come to mind) that manage
> endpoint-to-endpoint connectivity even when both are behind NAT. Why
> shouldn't IPsec endpoints do this?
>
> If this requires some new NAT traversal mechanism, perhaps using a hub
> gateway in place of the SIP SBC, then this should be part of the
> requirements.
>
> This mechanism is needed even if only one endpoint is NATted, otherwise
> we're constraining who the initiator has to be.
>
> Yoav
>
> On Mar 21, 2012, at 3:31 AM, Stephen Hanna wrote:
>
> > 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: <
> http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/213#comment:1>
> > ipsecme 
> >
> > ___
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> > IƧ��[�(^rC�{S�֥I�.�+r �^��
>
> ___
> 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?

2012-03-21 Thread 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. 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

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

2012-03-21 Thread Yaron Sheffer 

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

Re: [IPsec] [ipsecme] #217: Temporary credentials

2012-03-21 Thread Yaron Sheffer 

Hi Yoav,

When you say "local policy" you assume that spokes are smart enough (or 
well enough provisioned) to have such policy. My assumption OTOH was 
that the gateway is smarter, e.g. it knows what spokes are allowed to 
communicate directly or what kind of traffic is allowed to flow directly 
between spokes.


It may just be a semantic discussion, but the second bullet of your 
"introduction" is to me indistinguishable from authorization.


Thanks,
Yaron

On 03/21/2012 11:48 PM, Yoav Nir wrote:

I don't think there need to be authorization tokens, as authorization can be 
left to local policy.

But there always needs to be some kind of "introduction" process, and it can 
take many forms:
  - Yaron, Yoav is at 192.168.1.3. Use c80273f0f7dd5bdc10c38234616fde22 as PSK
  - Yaron, Yoav is at 192.168.1.3. His certificate has DN: 
"CN=ynir,OU=something"

In the first case, the "system" actually invented the credential, while in the 
second case it just tells you about it. So temporary credentials are not strictly 
necessary, but previous attempts to rely on pure PKI have been less than successful.

Yoav

On Mar 21, 2012, at 11:24 PM, Yaron Sheffer wrote:


The point of "temporary credentials" is that if these spokes normally
use EAP or PSK to authenticate to the gateway, they cannot use these
same credentials to auth to one another (because that would expose each
spoke to impersonation by the other one). So to support this scenario we
must have some other means of authentication.

This raises an interesting question: if the spokes are authenticating
with certificates, they could in principle use the same credentials to
authenticate to one another. So the "temporary credentials" now become
*authorization* tokens, basically conveying to gateway's policy. Do we
really want to go down this path?

Thanks,
Yaron

On 03/21/2012 10:43 PM, Geoffrey Huang wrote:

I don't understand what "temporary credentials" means.  If the intent is to 
have some transitive authentication (or redirection of trust hierarchy, at least) between 
a gateway and two spoke devices, which are trying to establish an ad-hoc connection, then 
I agree this would be important to have.

-geoff

From: Vishwas Manralmailto:vishwas.i...@gmail.com>>
Date: Wed, 21 Mar 2012 12:24:08 -0700
To: Steve Hannamailto:sha...@juniper.net>>
Cc: 
"ipsec@ietf.org"mailto:ipsec@ietf.org>>
Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials

Hi Steve,

I think this is an important requirement for sure.

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:36 PM, Stephen 
Hannamailto:sha...@juniper.net>>   wrote:
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.




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

Re: [IPsec] [ipsecme] #217: Temporary credentials

2012-03-21 Thread Yoav Nir 
I don't think there need to be authorization tokens, as authorization can be 
left to local policy.

But there always needs to be some kind of "introduction" process, and it can 
take many forms:
 - Yaron, Yoav is at 192.168.1.3. Use c80273f0f7dd5bdc10c38234616fde22 as PSK
 - Yaron, Yoav is at 192.168.1.3. His certificate has DN: "CN=ynir,OU=something"

In the first case, the "system" actually invented the credential, while in the 
second case it just tells you about it. So temporary credentials are not 
strictly necessary, but previous attempts to rely on pure PKI have been less 
than successful.

Yoav

On Mar 21, 2012, at 11:24 PM, Yaron Sheffer wrote:

> The point of "temporary credentials" is that if these spokes normally 
> use EAP or PSK to authenticate to the gateway, they cannot use these 
> same credentials to auth to one another (because that would expose each 
> spoke to impersonation by the other one). So to support this scenario we 
> must have some other means of authentication.
> 
> This raises an interesting question: if the spokes are authenticating 
> with certificates, they could in principle use the same credentials to 
> authenticate to one another. So the "temporary credentials" now become 
> *authorization* tokens, basically conveying to gateway's policy. Do we 
> really want to go down this path?
> 
> Thanks,
>   Yaron
> 
> On 03/21/2012 10:43 PM, Geoffrey Huang wrote:
>> I don't understand what "temporary credentials" means.  If the intent is to 
>> have some transitive authentication (or redirection of trust hierarchy, at 
>> least) between a gateway and two spoke devices, which are trying to 
>> establish an ad-hoc connection, then I agree this would be important to have.
>> 
>> -geoff
>> 
>> From: Vishwas Manralmailto:vishwas.i...@gmail.com>>
>> Date: Wed, 21 Mar 2012 12:24:08 -0700
>> To: Steve Hannamailto:sha...@juniper.net>>
>> Cc: 
>> "ipsec@ietf.org"mailto:ipsec@ietf.org>>
>> Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials
>> 
>> Hi Steve,
>> 
>> I think this is an important requirement for sure.
>> 
>> Thanks,
>> Vishwas
>> 
>> On Tue, Mar 20, 2012 at 6:36 PM, Stephen 
>> Hannamailto:sha...@juniper.net>>  wrote:
>> 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.
>> 

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

Re: [IPsec] [ipsecme] #218: Exhaustive configuration

2012-03-21 Thread Yoav Nir 
+1

Not only IP addresses, but actual peers may come and go. A user database 
changes every day as employees (for example) come and go.

On Mar 21, 2012, at 9:26 PM, Vishwas Manral wrote:

Hi Steve,

Like I mentioned the problem is not just exhaustive configuration but also the 
fact that configuration parameters like IP address change.

I agree we should expand the section you mention below.

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:37 PM, Stephen Hanna 
mailto:sha...@juniper.net>> wrote:
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 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?

2012-03-21 Thread Yoav Nir 
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. 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]
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
 Pri

Re: [IPsec] [ipsecme] #217: Temporary credentials

2012-03-21 Thread Praveen Sathyanarayan 
Yes. If certificate based authentication was used in the network, there is
no need of new credentials. But if pre-shared key based was used, then we
need this "temporary credentials". Also, it is required to define the
lifetime of this "temporary credentials". For example, if tunnel between
spokes are stays beyond lifetime of SA, then can the same "temporary
credentials" can be used for rekey? Or new "temporary credentials" should
be received from Hub?

Thanks,
Praveen


On 3/21/12 2:24 PM, "Yaron Sheffer"  wrote:

The point of "temporary credentials" is that if these spokes normally
use EAP or PSK to authenticate to the gateway, they cannot use these
same credentials to auth to one another (because that would expose each
spoke to impersonation by the other one). So to support this scenario we
must have some other means of authentication.

This raises an interesting question: if the spokes are authenticating
with certificates, they could in principle use the same credentials to
authenticate to one another. So the "temporary credentials" now become
*authorization* tokens, basically conveying to gateway's policy. Do we
really want to go down this path?

Thanks,
Yaron

On 03/21/2012 10:43 PM, Geoffrey Huang wrote:
> I don't understand what "temporary credentials" means.  If the intent is
>to have some transitive authentication (or redirection of trust
>hierarchy, at least) between a gateway and two spoke devices, which are
>trying to establish an ad-hoc connection, then I agree this would be
>important to have.
>
> -geoff
>
> From: Vishwas 
>Manralmailto:vishwas.i...@gmail.com>>
> Date: Wed, 21 Mar 2012 12:24:08 -0700
> To: Steve Hannamailto:sha...@juniper.net>>
> Cc: 
>"ipsec@ietf.org"mailto:ipsec@ietf.o
>rg>>
> Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials
>
> Hi Steve,
>
> I think this is an important requirement for sure.
>
> Thanks,
> Vishwas
>
> On Tue, Mar 20, 2012 at 6:36 PM, Stephen
>Hannamailto:sha...@juniper.net>>  wrote:
> 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.orge-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.
>
> --
>
> ___
> 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 mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #217: Temporary credentials

2012-03-21 Thread Yaron Sheffer 
The point of "temporary credentials" is that if these spokes normally 
use EAP or PSK to authenticate to the gateway, they cannot use these 
same credentials to auth to one another (because that would expose each 
spoke to impersonation by the other one). So to support this scenario we 
must have some other means of authentication.


This raises an interesting question: if the spokes are authenticating 
with certificates, they could in principle use the same credentials to 
authenticate to one another. So the "temporary credentials" now become 
*authorization* tokens, basically conveying to gateway's policy. Do we 
really want to go down this path?


Thanks,
Yaron

On 03/21/2012 10:43 PM, Geoffrey Huang wrote:

I don't understand what "temporary credentials" means.  If the intent is to 
have some transitive authentication (or redirection of trust hierarchy, at least) between 
a gateway and two spoke devices, which are trying to establish an ad-hoc connection, then 
I agree this would be important to have.

-geoff

From: Vishwas Manralmailto:vishwas.i...@gmail.com>>
Date: Wed, 21 Mar 2012 12:24:08 -0700
To: Steve Hannamailto:sha...@juniper.net>>
Cc: 
"ipsec@ietf.org"mailto:ipsec@ietf.org>>
Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials

Hi Steve,

I think this is an important requirement for sure.

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:36 PM, Stephen 
Hannamailto:sha...@juniper.net>>  wrote:
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.

--

___
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] #217: Temporary credentials

2012-03-21 Thread Geoffrey Huang 
I don't understand what "temporary credentials" means.  If the intent is to 
have some transitive authentication (or redirection of trust hierarchy, at 
least) between a gateway and two spoke devices, which are trying to establish 
an ad-hoc connection, then I agree this would be important to have.

-geoff

From: Vishwas Manral mailto:vishwas.i...@gmail.com>>
Date: Wed, 21 Mar 2012 12:24:08 -0700
To: Steve Hanna mailto:sha...@juniper.net>>
Cc: "ipsec@ietf.org" 
mailto:ipsec@ietf.org>>
Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials

Hi Steve,

I think this is an important requirement for sure.

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna 
mailto:sha...@juniper.net>> wrote:
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.

--

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

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

2012-03-21 Thread Geoffrey Huang 
I agree.  I believe this is a common use case.

-geoff

From: Vishwas Manral mailto:vishwas.i...@gmail.com>>
Date: Wed, 21 Mar 2012 12:14:26 -0700
To: Steve Hanna mailto:sha...@juniper.net>>
Cc: "ipsec@ietf.org" 
mailto:ipsec@ietf.org>>
Subject: Re: [IPsec] [ipsecme] #212: Section 2.2 should be more detailed.

Hi Stephen,

Sounds good to me.

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:29 PM, Stephen Hanna 
mailto:sha...@juniper.net>> wrote:
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 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?

2012-03-21 Thread 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]
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 mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

2012-03-21 Thread 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]
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 mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [ipsecme] #218: Exhaustive configuration

2012-03-21 Thread Vishwas Manral 
Hi Steve,

Like I mentioned the problem is not just exhaustive configuration but also
the fact that configuration parameters like IP address change.

I agree we should expand the section you mention below.

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:37 PM, Stephen Hanna  wrote:

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

Re: [IPsec] [ipsecme] #217: Temporary credentials

2012-03-21 Thread Vishwas Manral 
Hi Steve,

I think this is an important requirement for sure.

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna  wrote:

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

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

2012-03-21 Thread Vishwas Manral 
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  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]
> 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: <
> http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/216#comment:1>
> ipsecme 
>
> ___
> 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?

2012-03-21 Thread Vishwas Manral 
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  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]
> 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: <
> http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/214#comment:1>
> ipsecme 
>
> ___
> 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] #212: Section 2.2 should be more detailed.

2012-03-21 Thread Vishwas Manral 
Hi Stephen,

Sounds good to me.

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:29 PM, Stephen Hanna  wrote:

> 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: <
> http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/212#comment:1>
> ipsecme 
>
> ___
> 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] FW: [ipsecme] #211: We should talk more about why this is a hard problem.

2012-03-21 Thread yogendra pal 
1. Let us not say this is a hard problem, it sounds like NP hard problem
(which indeed it's not)
Just rephrasing it, Suggested Resolution: Add a Requirements section that
lays out the problems that any solution must address.


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

Thanks and Regards,
Yogendra Pal
Ericsson, India
+919686202644

On Wed, Mar 21, 2012 at 6:56 AM, Stephen Hanna  wrote:

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

[IPsec] SUSPENSION OF THREAD #210: What should we call this effort?

2012-03-21 Thread Paul Hoffman 


Steve posted a large number of interesting technical questions that have been 
asked about the document. Spending energy on those is *much* more important to 
the WG than deciding the name. Further, some of the answers of those questions 
will help choose the "best" name.

I will resume the discussion of #210 after we have answers on the other issues.

--Paul Hoffman

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

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

2012-03-21 Thread Manish Kumar 

How about "Dynamic Secure VPN" ?

Thanks,
Manish


On 21/03/12 6:55 AM, "Stephen Hanna"  wrote:

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

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

Re: [IPsec] P2P VPN draft UNCLASSIFIED

2012-03-21 Thread Manish Kumar 

Although I prefer it over some of the other names, "discovery" isn't making
too good an adjective here. How about "Dynamic Secure VPN" without over
qualifying dynamic ?

Thanks,
Manish


On 19/03/12 1:27 PM, "Yoav Nir"  wrote:

> As Tero pointed out, some of the use cases don't end up in a full mesh,
> because sometimes administrators really want a trunk, so the end result could
> be a mesh among nodes in the same organization, and a trunk to another. Maybe
> even a partial mesh (with "secondary nodes" behind particularly bad NAT
> devices connecting to one of many "primary nodes")
> 
> So perhaps the name should not include the word "mesh". How about "dynamic
> discovery VPN" (DD-VPN)?
> ___
> 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] #210: What should we call this effort?

2012-03-21 Thread yogendra pal 
I am ok to any of two names which make sense:
Remote unknown VPN ( RUK-VPN) or On-demand VPN

Thanks and Regards,
Yogendra Pal
Ericsson, India
+919686202644

On Wed, Mar 21, 2012 at 6:55 AM, Stephen Hanna  wrote:

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



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

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

2012-03-21 Thread Yoav Nir 
"direct endpoint-to-endpoint connectivity may not be possible if both endpoints 
are NATed"

Why?  There are several protocols (SIP/RTP come to mind) that manage 
endpoint-to-endpoint connectivity even when both are behind NAT. Why shouldn't 
IPsec endpoints do this?

If this requires some new NAT traversal mechanism, perhaps using a hub gateway 
in place of the SIP SBC, then this should be part of the requirements.

This mechanism is needed even if only one endpoint is NATted, otherwise we're 
constraining who the initiator has to be.

Yoav

On Mar 21, 2012, at 3:31 AM, Stephen Hanna wrote:

> 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
> IƧ��[�(^rC�{S�֥I�.�+r�^��

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