headers
Vishwas Manral | 22 May 02:14
Picon

Section 2.3: Endpoint-to-Gateway P2P VPN

Hi folks,

I have been trying to understand the use case for End-point to Gateway use case as written in the current draft.

Finding the closes gateway, seems to be rightly routing or ALTO (Application Level Transport Optimization) problem, rather than an IPsec one. Am I missing the point altogether?

Thanks,
Vishwas


_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 4 comments |
headers
Vishwas Manral | 22 May 01:13
Picon

auto-discovery VPN

Hi Guys,

We intend to be calling our effort formerly called Mesh VPN as "auto-discovery VPN". This name has been chosen based on discussions between the authors of the draft and verified with the co-chairs. :)

Thanks,
Vishwas


_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 1 comment |
headers
Vishwas Manral | 14 May 23:05
Picon

#213 - Multiple interfaces or mobile endpoint

Hi,

Description: 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?

Detail Arguments: From what I understand if we are talking of mobile end points, there are 2 ways we could have mobility:

    1. Behind a gateway which is moving.

     2. Device itself is moving. 

The current tunnel mechanisms I know of is tied to an interface. If there is a choice of multiple mobile endpoint interfaces, we should allow for the ability to maintain the tunnel.

I am unsure of the above description of gateways? Could someone explain the same please?

Suggested Resolution: We need to clarify what the gateway functionality in the description means. We then need to clarify the problem statement with the use cases.

Thanks,
Vishwas

==========================================================
  # 216 Multiple interfaces or mobile endpoint
           Solution-specific or requirement
           Tero: Is there a use case where the end point moves from
                   outside the gateway to inside
           Paul: Mobility is a use case, but not just for multiple
                    interfaces
           Steve: Either a new use case, or within the existing ones

==========================================================


_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 3 comments |
headers
Vishwas Manral | 12 May 01:34
Picon

Issue #218 - Exhaustive configuration

Hi,

Description: Exhaustive configuration

Detail Arguments:Tero rightly mentioned that the configuration is a proprietary issue. However there are a few things, that make the configuration hard. Change of IP address of a spoke, NAT, configuration limited by weakest link(device) in the chain.

Suggested Resolution: In my view reducing configuration is a big issue. Point out issues with this in greater detail in the draft.

Thanks,
Vishwas
===============================================
Meeting minutes:

               # 218 Exhaustive configuration
                        Explain that this doesn't scale in 3.1.
                        Tero: It is also proprietary and can't be interoperable
                        Brian: We can push out configs if needed
                        Paul: Remember the massive failure of the IPS WG
                                Also issue with NATs if the endpoint hasn't
                                talked first

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 0 comments |
headers
Vishwas Manral | 12 May 01:03
Picon

Issue #213/ #214 - Allow for non-direct end point connectivity

Hi,

Description: Direct endpoint-to-endpoint connectivity may not be possible. Should gateways figure things out completely or just punt endpoints to a closer gateway?

Detail Arguments: As Izaac and John Lesser pointed out this is more of a routing issue. Though current solutions do not allow such connectivity unless through a hub, I think from the security plane, we should not preclude such connectivity. This could be achieved either transparently (no IPsec component except the SPD involved), or by stitching tunnel traffic.

Suggested Resolutions: Specify explicitly that issues around direct connectivity between endpoints are more of a Routing issue. However IPsec should not prevent such a connectivity model.

Thanks,
Vishwas
=======================================================
Meeting notes:
                 # 213 In use case 2.1, direct endpoint-to-endpoint connectivity
                  may not be possible
                          Need to mention challenges in use cases section
                          Paul: reminded that there will be a separate requirement
                          section
                  # 214 Should gateways figure things out completely or just punt
                  endpoints to a closer gateway?
                          Core gateway configuring is a solution, so premature
                          Also in #213

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 4 comments |
headers
Vishwas Manral | 12 May 00:11
Picon

Issue #219 - Star topology as an admin choice

Hi,

I would like to start off by trying to resolve the issue. The notes from the IETF are attached below.

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

Detail arguments: My take is similar to what Yaron and Yaov seem to state. There is no reason to exclude star topology at all from the Problem statement/ requirements document. In fact both the proprietary solutions I know of allow for such a topology. I however understand that some of the functionality on the Hub (of the star) could be achieved by using PFP flags in the SPD entry.

Suggested Resolution: State in the document that Star topology is not excluded from the solution. The problem of configuration is however mainly limited to the Hub. For every spoke added/ deleted/ modified the configuration on the Hub needs to be changed, which is not desirable. May be update Section 3.2 with the same too.

Thanks,
Vishwas
===========================================================
Notes from meeting minutes:

                  # 219 Star topology as an admin choice
                          People don't need to use this if they don't want to
                          Say this in the security considerations
                          Yoav Nir:
                                  Has to be a requirement that any solution can
                                  implement different policies
                          Yaron Sheffer:
                                  Agrees with Yoav, maybe becomes a use case
                                  Take this to the list

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 7 comments |
headers
Mike Belopuhov | 10 May 14:19
Picon
Favicon

ESP AAD construction for GCM with ESN

Hi,

The RFC 4106 "The Use of Galois/Counter Mode (GCM) in IPsec
Encapsulating Security Payload (ESP)" doesn't explicitly state
how are ESN octets distributed in the AAD.

Given that SPI and low-order 32 bits are coming from the actual
packet and most likely occupy one cache line, I'd expect AAD to
look like this to exploit cache locality and simplify processing:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               SPI                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Low-order 32 bits (part of the packet)           |
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   |           High-order 32 bits (external memory buffer)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Could you please confirm or disconfirm this observation.

Thanks in advance,
Mike
Permalink | Reply | 0 comments |
headers
Yaron Sheffer | 8 May 21:46
Picon

Mesh VPN I-D (temporary name) - new author

Hi everybody,

Vishwas Manral has agreed to join Steve Hanna as co-author of this 
draft, now at -00 ( 
http://tools.ietf.org/html/draft-ietf-ipsecme-p2p-vpn-problem-00). I'd 
like to thank them both.

While Vishwas and Steve are busy working on the next version, feel free 
to read and comment on the current version.

Regards,

     Yaron
Permalink | Reply | 4 comments |
headers
Nick Hilliard | 16 Apr 12:53
Picon

draft-bhatia-moving-ah-to-historic

I'd like to add a voice of support to this draft.  AH adds little except
complication to ipsec implementations and confusion to end users.

Regarding ipv4 NATs, they are ubiquitous and will become more so once ipv4
scarcity is realised worldwide (particularly in asia, which is currently
the fastest growing global region, and has already reached RIR exhaustion).

There was a previous comment about this draft about the NAT/AH issue being
a NAT problem rather than an AH problem.  Well, yeah, in the purest sense
this is true, but we live in the real world and need to work within its
limitations.  You can apply fixups and ALGs to lots of protocols which are
NAT sensitive, but AH is cryptographically incompatible with NAT and this
cannot be fixed.

I see little value in the IETF formally supporting a protocol which simply
cannot work for most end-users on the basis of the access addressing
provided.  Formal deprecation / designation to historic status is
appropriate in this case.

Also +1 to the following arguments:

- ESP + NULL == substantially equivalent
- less mailing list chatter

Nick
Permalink | Reply | 2 comments |
headers
Paul Wouters | 15 Apr 03:07
Picon

looking for someone who can read/interpret Cisco vpn logs


Hi,

I'm trying to figure out an interop issue with a Cisco device, but can't
make head or tails from the cisco logs. If there is anyone on this list
could help me interpret such losgs, please contact me off list.

Thanks,

Paul
Permalink | Reply | 0 comments |
headers
Yoav Nir | 12 Apr 20:17
Picon
Favicon

Fwd: New Version Notification for draft-nir-ipsecme-erx-03.txt

Hi all.

This is the 3rd iteration of the draft I presented about in Paris.

We would like this working group to accept this, and have it added to charter. Of course, if it gets accepted,
we volunteer to be authors. If it is not accepted, we will try to progress it as an individual submission,
but we believe that this changes IKE enough that it should come from the working group.

Yoav & Qin

Begin forwarded message:

> From: "internet-drafts <at> ietf.org" <internet-drafts <at> ietf.org>
> Subject: New Version Notification for draft-nir-ipsecme-erx-03.txt
> Date: April 12, 2012 1:33:48 PM GMT+03:00
> To: Yoav Nir <ynir <at> checkpoint.com>
> Cc: "sunseawq <at> huawei.com" <sunseawq <at> huawei.com>
> 
> A new version of I-D, draft-nir-ipsecme-erx-03.txt has been successfully submitted by Yoav Nir and
posted to the IETF repository.
> 
> Filename:	 draft-nir-ipsecme-erx
> Revision:	 03
> Title:		 An IKEv2 Extension for Supporting ERP
> Creation date:	 2012-04-12
> WG ID:		 Individual Submission
> Number of pages: 7
> 
> Abstract:
>   This document describes an extension to the IKEv2 protocol that
>   allows an IKE Security Association (SA) to be created and
>   authenticated using the EAP Re-authentication Protocol extension as
>   described in RFC 5296bis.
> 
>   NOTE TO RFC EDITOR: Replace 5296bis in the previous paragraph with
>   the RFC number assigned to that document.
Permalink | Reply | 6 comments |

Gmane