Subject: re:draft-wu-l3vpn-ipsec-gre-00

From: "ma yc" <[email-masked]>
Date: Thu, 15 Nov 2007 19:26:32 +0800

Hi

Interesting draft. Please check my personal
view below.

1. I agree that GRE should be protected
by IPsec in some scenario. I just wonder
if it is necessary that GRE tunnels between
the same peer should be protected by different
IPsec tunnels. Is there any use case for such
deployment?

2. As per RFC 4301, the MUST supported selector
does not include GRE key. So i do not think any current
IPsec implementation supports that. To
mandate the implementations to support that,
GRE key need to be added as part of RFC 4301.

3. I am not so familiar with GRE, i have one question
about the header processing. Since all the fields after
protocol type are optional, how does a GRE implementation
tell the bits after protocol type is GRE key or checksum or
sequence number?

Thank you.
Regards
Yuanchen

>Hello, all
>
>
>
>Below is our new draft which posted recently,
>
>http://www.ietf.org/internet-drafts/draft-wu-l3vpn-ipsec-gre-00.txt

---

From: "Yingzhe Wu" <[email-masked]>
Date: Thu, 15 Nov 2007 11:49:26 -0800

Hi YC,
Thanks a lot for your comments.
Please see inline for my reply.

BR/
Yingzhe

-----Original Message-----
From: ma yc [mailto:[email-masked]] 
Sent: Thursday, November 15, 2007 3:27 AM
To: [email-masked]
Subject: re:draft-wu-l3vpn-ipsec-gre-00

Hi

YZ> The proposed GRE tunnel is per VPN. Different VPNs may have different
security requirements, hence it would be beneficial there is per-VPN based
differentiated security protection.

YZ> Yes, your observation is correct.

YZ> There are bit setting at the beginning of the GRE header to indicate a
particular field is present or not, such as Key, Checksum etc. While used in
this proposal, the 'K' bit must be set and 'C' bit must be cleared.

Thank you.
Regards
Yuanchen