[Gen-art] RE: Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt
Black_David@emc.com Tue, 12 December 2006 23:39 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuHDR-0001Ue-PO; Tue, 12 Dec 2006 18:39:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuHDR-0001UV-8H for gen-art@ietf.org; Tue, 12 Dec 2006 18:39:17 -0500
Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuHDP-0005lr-UN for gen-art@ietf.org; Tue, 12 Dec 2006 18:39:17 -0500
Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBCNd1qv015309; Tue, 12 Dec 2006 18:39:01 -0500 (EST)
Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBCNcxV6029848; Tue, 12 Dec 2006 18:38:59 -0500 (EST)
From: Black_David@emc.com
Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 18:38:59 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Dec 2006 18:38:58 -0500
Message-ID: <F222151D3323874393F83102D614E055068B89FF@CORPUSMX20A.corp.emc.com>
In-Reply-To: <20061212225125.68694.qmail@web80613.mail.yahoo.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt
Thread-Index: AcceQBamxNFVDEoVQ3SgAqdQJC3vFAABCjcQ
To: mohanp@sbcglobal.net, gen-art@ietf.org, rfg@acm.org, psavola@funet.fi, Hannes.Tschofenig@siemens.com
X-OriginalArrivalTime: 12 Dec 2006 23:38:59.0175 (UTC) FILETIME=[B2541F70:01C71E46]
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.12.150932
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: david.kessens@nokia.com, Black_David@emc.com, fred.baker@cisco.com, kurtis@kurtis.pp.se
Subject: [Gen-art] RE: Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org
Mohan, > Thanks for the review. I am trying to understand the "interface" > related comments that you made. > > >Section 5.2 discusses the consequences of whether the endpoint > >of an IPsec tunnel-mode SA is modeled as an IPv6 interface or > >not. It should say that there is always an IPv6 interface at > >the endpoint of a IPv6-in-IPv4 tunnel, and the discussion of > >whether to model the SA as an interface is concerned with > >whether the functionality of an IPv6 interface is realized by > >the IPsec SA or outside of it. > > > In some implementations e.g., linux, to protect the traffic > using IPsec tunnel mode SA, traffic matching the selectors is > given to IPsec for protecting the traffic. IPsec is just another > software module that is neither visible as an interface nor in the routing > tables. By this it means that IPsec is not modeled as an interface at all. > If in addition to the above, IPsec creates an interface and hence > visible to routing so that it can get packets matching the route > pointing to the interface rather than through "traffic selectors matching". > By this it means that IPsec is modeled as an interface. > These are the models that this document is talking about. So, how > can we say that there is always an interface ? Could you > clarify further ? Let's start with a router. In order for a router to forward an IPv6 packet, it has to send it through an IPv6 interface, hence, somewhere between where the forwarding table is consulted and where the packet hits the wire, there is an "IPv6 interface". For a host, there is an IPv6 interface somewhere in the stack between the application and the wire. That is the basis for the statement that "there is always an IPv6 interface at the endpoint of an IPv6-in-IPv4 tunnel". For the IPv6-in-IPsec-in-IPv4 protocol stack in this draft, you describe two different approaches to achieving the functionality. For the first one: > In some implementations e.g., linux, to protect the traffic > using IPsec tunnel mode SA, traffic matching the selectors is > given to IPsec for protecting the traffic. IPsec is just another > software module that is neither visible as an interface nor in the > routing tables. There is an IPv6 interface above IPsec, and then the traffic gets handed to the IPsec selectors to deal with. For the second one: > If in addition to the above, IPsec creates an interface and hence > visible to routing so that it can get packets matching the route > pointing to the interface rather than through "traffic selectors matching". > By this it means that IPsec is modeled as an interface. The IPv6 interface is part of the IPsec implementation. I would like to see the draft discuss where the IPv6 interface is located as opposed to the current text that could imply that there may not be an IPv6 interface. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Gen-ART review of draft-ietf-v6ops-ipse… Black_David
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Fred Baker
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Pekka Savola
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Mohan Parthasarathy
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Mohan Parthasarathy
- [Gen-art] RE: Gen-ART review of draft-ietf-v6ops-… Black_David
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Fred Baker
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Mohan Parthasarathy
- [Gen-art] RE: Gen-ART review of draft-ietf-v6ops-… Black_David
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Pekka Savola
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Mohan Parthasarathy
- RE: [Gen-art] Re: Gen-ART review ofdraft-ietf-v6o… Black_David