On Aug 21, 2013, at 8:14 AM, Yaron Sheffer <yaronf.i...@gmail.com> wrote:

> Thank you for the new version. Two quick comments:
> 
> - 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.

> 
> Thanks,
>       Yaron
> 
> On 2013-08-21 06:47, Yoav Nir wrote:
>> 
>> 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, "internet-dra...@ietf.org" <internet-dra...@ietf.org>
>> 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
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>> 
> 
> Email secured by Check Point

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

Reply via email to