[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