Subject: [IPsec] Fwd: New Version Notification for draft-sathyanarayan-ipsecme-advpn-01.txt

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Aug 2013 03:47:04 +0000

Hi IPsec-WG,

Based on the review comments from various working group members, we have
made a revision to our original proposal for ADVPN protocol. In this
revision, we have tried to address most review comments. More review
comments will be addressed in future revisions. Please take a look at it
and provide us your valuable comment.

Changes done in this revision:
 * Introduced new exchange type called SHORTCUT exchange, instead of SHORTCUT Notify payload.
 * Added few new notification payloads, which carries shortcut information and shortcut status.
 * Added new ID payload called Peer Address Identification Payload. This combines IPv4, IPv6 and FQDN Shortcut types into one.
 * Instead of using vendor-id to advertise ADVPN protocol, this draft proposes to use ADVPN_SUPPORTED notification payload. This notification payload also carries additional information like, capabilities supported by endpoints.
 * Now shortcut information carries shortcut peer's port number, as well. This improves NAT scenarios supported by this draft.

Thanks,
Praveen

On 8/20/13 4:18 PM, "[email-masked]" <[email-masked]>
wrote:

A new version of I-D, draft-sathyanarayan-ipsecme-advpn-01.txt
has been successfully submitted by Praveen Sathyanarayan and posted to the
IETF repository.

Filename:	 draft-sathyanarayan-ipsecme-advpn
Revision:	 01
Title:		 Auto Discovery VPN Protocol
Creation date:	 2013-08-20
Group:		 Individual Submission
Number of pages: 40
URL:             http://www.ietf.org/internet-drafts/draft-sathyanarayan-ipsecme-advpn-01.txt
Status:          http://datatracker.ietf.org/doc/draft-sathyanarayan-ipsecme-advpn
Htmlized:        http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-sathyanarayan-ipsecme-advpn-01

Abstract:
  This document defines a protocol for dynamically establishing and tearing
  down IPsec tunnels as needed without requiring non-scalable configuration.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 21 Aug 2013 08:14:18 +0300

Thank you for the new version. Two quick comments:

- I'm not very happy with the standard payload referencing an opaque VID 
payload.

- In Sec. 3.8, why are the TSx payloads "bare", with their payload 
headers stripped out?

Thanks,
	Yaron

On 2013-08-21 06:47, Yoav Nir wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Aug 2013 06:32:48 +0000

On Aug 21, 2013, at 8:14 AM, Yaron Sheffer <[email-masked]> wrote:

> - I'm not very happy with the standard payload referencing an opaque VID payload.

If all of the authorization is based on IP addresses and ports, it can be expressed in traffic selectors, and we don't really need to convey any "real" identity. However, if some of the policy is more complicated (such as next generation firewalls like to do - John is allowed to transfer files over Skype, but Jack is only allowed voice conversations), then passing the identity to the shortcut partner is important. Unfortunately, there is no vendor-neutral way to pass user records among gateways.

> - In Sec. 3.8, why are the TSx payloads "bare", with their payload headers stripped out?

Cut-and-paste error from -00. Will fix in -02.

> Email secured by Check Point