Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traffic-visibility-05
"QIU Ying" <qiuying@i2r.a-star.edu.sg> Wed, 15 July 2009 02:56 UTC
Return-Path: <qiuying@i2r.a-star.edu.sg>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C78B3A691B for <ipsec@core3.amsl.com>; Tue, 14 Jul 2009 19:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.511
X-Spam-Level:
X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=1.087, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HF2LGVnhvQxt for <ipsec@core3.amsl.com>; Tue, 14 Jul 2009 19:56:57 -0700 (PDT)
Received: from gw2.scei.a-star.edu.sg (gw2.scei.a-star.edu.sg [192.122.140.11]) by core3.amsl.com (Postfix) with ESMTP id C3FFC3A68B9 for <ipsec@ietf.org>; Tue, 14 Jul 2009 19:56:56 -0700 (PDT)
Received: from mailfe01.teak.local.net ([10.217.253.173]) by gw2.scei.a-star.edu.sg (8.14.1/8.14.1) with ESMTP id n6F2iRns008609; Tue, 14 Jul 2009 19:44:27 -0700
Received: from t3400 ([10.217.141.123]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 10:46:03 +0800
Message-ID: <E12B577D22E64DE1806D838CDC751259@t3400>
From: QIU Ying <qiuying@i2r.a-star.edu.sg>
To: "Grewal, Ken" <ken.grewal@intel.com>, Yaron Sheffer <yaronf@checkpoint.com>, ipsec@ietf.org
References: <2E5D69B62A99425C894AA9B258004990@t3400> <C49B4B6450D9AA48AB99694D2EB0A4832C2438DC@rrsmsx505.amr.corp.intel.com>
Date: Wed, 15 Jul 2009 10:42:03 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_021E_01CA0538.E3C6E250"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-OriginalArrivalTime: 15 Jul 2009 02:46:03.0872 (UTC) FILETIME=[6522B600:01CA04F6]
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-07-15_03:2009-07-03, 2009-07-14, 2009-07-14 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0907140202
Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traffic-visibility-05
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2009 02:56:59 -0000
Hi, Ken Agree that Option 1 is better as it applies lesser new IANA numbers. But in this case, it seems redundancy to copy the value of Next Header field in the ESP trailer to here. How about simply setting the value as ESP here? I think it more meet the original concept of Next Header. Maybe I am missing something Regards Qiu Ying ----- Original Message ----- From: Grewal, Ken To: QIU Ying ; Yaron Sheffer ; ipsec@ietf.org Sent: Wednesday, July 15, 2009 1:31 AM Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-traffic-visibility-05 Thanks Qiu Ying - great observation. We had originally proposed using a bit from the WESP flags (integrity only) for differentiating between ESP-encrypted and ESP-NULL traffic, but changed this to using a value of zero in the next header for efficient encoding, although this is overloading the meaning of next header. With your observation, the current definition is not practical so we have the following options: 1.. Revert back to using a bit in the flags to differentiate between encrypted / NULL traffic. 2.. Allocate a new protocol value for the next header field to indicate encrypted data, which seems like an overkill. As we are already asking for a new protocol value for WESP, option 1 seems to be the better choice. Other opinions? Thanks, - Ken ------------------------------------------------------------------------------ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of QIU Ying Sent: Tuesday, July 14, 2009 12:37 AM To: QIU Ying; Yaron Sheffer; ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traffic-visibility-05 Since the zero of next header value is used for HOPOPT already, maybe applying a new value for this intention is better to avoid the confliction. Regards Qiu Ying ----- Original Message ----- From: QIU Ying To: Yaron Sheffer ; ipsec@ietf.org Sent: Tuesday, July 14, 2009 3:30 PM Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traffic-visibility-05 Regarding the Next Header in section 2, what will be happened if the value of Next Header is zero (i.e. IPv6 Hop-by-Hop option) and the packet is not encrypted? Regards Qiu Ying ----- Original Message ----- From: Yaron Sheffer To: ipsec@ietf.org Sent: Sunday, July 05, 2009 3:48 AM Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-traffic-visibility-05 This is the beginning of a two-week WG Last Call, which will end July 18. The target status for this document is Proposed Standard. The current document is at http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-05. If you have not read the document before now, please do so. Having fresh eyes on the document often brings up important issues. If you HAVE read it before, please note that there have been several revisions since San Francisco, so you might want to read it again (plus it's a short document). Send any comments to the list, even if they are as simple as "I read it and it seems fine". Please clearly indicate the position of any issue in the Internet Draft, and if possible provide alternative text. Please also indicate the nature or severity of the error or correction, e.g. major technical, minor technical, nit, so that we can quickly judge the extent of problems with the document. Thanks, Yaron -------------------------------------------------------------------------- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you."
- [IPsec] WG Last Call: draft-ietf-ipsecme-traffic-… Yaron Sheffer
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… Jack Kohn
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… Yoav Nir
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… QIU Ying
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… gabriel montenegro
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… gabriel montenegro
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… Yoav Nir
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… QIU Ying
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… Grewal, Ken
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… QIU Ying
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… Grewal, Ken
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… Bhatia, Manav (Manav)
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… QIU Ying
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… QIU Ying
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… Bhatia, Manav (Manav)
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… Yaron Sheffer
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… Bhatia, Manav (Manav)
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traf… Grewal, Ken
- [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-… Yaron Sheffer
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-road… Paul Hoffman
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-road… Laganier, Julien
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-road… Greg Daley
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-road… Scott C Moonen
- Re: [IPsec] WG Last Call: draft-ietf-ipsecme-road… Yoav Nir
- [IPsec] Comments on draft-ietf-ipsecme-roadmap-03 Suresh Krishnan