RE: RE:Pre-draft: SEAL as an IPv6 extensionheader(was:Fragmentation-related Security issues) (Templin, Fred L)

Sreenatha setty <sreenatha.b@huawei.com> Mon, 16 January 2012 11:51 UTC

Return-Path: <sreenatha.b@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616EA21F8582 for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2012 03:51:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.383
X-Spam-Level:
X-Spam-Status: No, score=-6.383 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhCxLgMiZmoh for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2012 03:51:21 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 68BB321F8581 for <ipv6@ietf.org>; Mon, 16 Jan 2012 03:51:21 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXW00K5F3LJUH@szxga05-in.huawei.com> for ipv6@ietf.org; Mon, 16 Jan 2012 19:51:19 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXW00ISE3LJHO@szxga05-in.huawei.com> for ipv6@ietf.org; Mon, 16 Jan 2012 19:51:19 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGL58956; Mon, 16 Jan 2012 19:51:01 +0800
Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jan 2012 19:50:57 +0800
Received: from blrnshtipl6nc (10.18.1.36) by szxeml416-hub.china.huawei.com (10.82.67.155) with Microsoft SMTP Server id 14.1.323.3; Mon, 16 Jan 2012 19:50:48 +0800
Date: Mon, 16 Jan 2012 17:20:43 +0530
From: Sreenatha setty <sreenatha.b@huawei.com>
Subject: RE: RE:Pre-draft: SEAL as an IPv6 extensionheader(was:Fragmentation-related Security issues) (Templin, Fred L)
In-reply-to: <E1829B60731D1740BB7A0626B4FAF0A65C793AF6EB@XCH-NW-01V.nw.nos.boeing.com>
X-Originating-IP: [10.18.1.36]
To: "'Templin, Fred L'" <Fred.L.Templin@boeing.com>
Message-id: <8F4DB39B04694D3FB200A2F934DF564D@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4841
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_N1o1336Fe/h/W4o0UkSptA)"
Thread-index: AczRritoWWU5eFohSYun74sigPsbGwAXpFLAABD05nAAfLHN4A==
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 16 Jan 2012 06:07:28 -0800
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jan 2012 11:51:23 -0000

Hi Fred,

    Since SEAL Extension header is need to be processed only by destination
node, why it should not be treated as NEW DESTINATION OPTION OF TYPE SEAL
rather than NEW EXTENSTION HEADER?  I went through the new draft proposed by
S. Krishnan and other members by name "An uniform format for IPv6 extension
headers". Thins drafts specify that any new extension header proposal should
explain the facts why it can not be treated as Option's in any of the
Existing Extension header and detailed explanation should be given to
clarify why it must be treated as Extension Header?

  
Thanks - Sreenatha

 

 

  _____  

From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] 
Sent: Saturday, January 14, 2012 5:40 AM
To: Sreenatha setty; ipv6@ietf.org
Subject: RE: RE:Pre-draft: SEAL as an IPv6
extensionheader(was:Fragmentation-related Security issues) (Templin, Fred L)

 

FYI, I have posted a new version that addresses these issues:

 

https://datatracker.ietf.org/doc/draft-templin-sealopt/

 

Thanks - Fred

 


  _____  


From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
Templin, Fred L
Sent: Friday, January 13, 2012 9:37 AM
To: Sreenatha setty; fltemplin@acm.org
Cc: ipv6@ietf.org
Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension
header(was:Fragmentation-related Security issues) (Templin, Fred L)

Hi Sreenatha,

 

You are right that the draft needs to be clarified on this point. The

answer is that whether or not there is a shared secret key the

destination node can validate or not validate the signature as it

deems fit. If the destination willl not validate the signature, then it

simply ignores the SEAL option and processes the next option.

 

If the destination sees the SEAL option as an unknown option

type, then it should ignore the option and process the next

option. This would seem to indicate that the SEAL digital signature

should appear as a Destination Option and not as its own header

extension, because the destination would discard any packet with

an extension header having an unknown "Next Header" value. I

will update the draft with these changes.

 

Thanks - Fred

 


  _____  


From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
Sreenatha setty
Sent: Thursday, January 12, 2012 8:45 PM
To: fltemplin@acm.org
Cc: ipv6@ietf.org
Subject: RE:Pre-draft: SEAL as an IPv6 extension
header(was:Fragmentation-related Security issues) (Templin, Fred L)

Hi Fred,

      In the draft, the behavior of destination node in processing the SEAL
header is need to be cleared.  If nodes are not exchanging symmetric key and
it received SEAL extension header packet and the packet is not ICMPv6 error
packet, how destination node should process the SEAL header? It should
simply ignore the SEAL header and go to next header processing or it should
try to validate the signature in SEAL header?

 

Thanks - Sreenatha

      

-----------------------------------------------------

From: "Templin, Fred L" <Fred.L.Templin@boeing.com>

To: Sreenatha setty <sreenatha.b@huawei.com>, "fltemplin@acm.org"

      <fltemplin@acm.org>

Cc: "ipv6@ietf.org" <ipv6@ietf.org>

Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header

      (was:Fragmentation-related Security issues)

Message-ID:

 
<E1829B60731D1740BB7A0626B4FAF0A65C793AF16B@XCH-NW-01V.nw.nos.boeing.com>

      

Content-Type: text/plain; charset="us-ascii"

 

Hi Sreenatha,

 

Since posting my message, I have submitted an actual draft that deprecates

the list-posted pre-draft:

 

https://datatracker.ietf.org/doc/draft-templin-sealopt/

 

The posted version makes the observation that the source can use the SEAL

option either in coordination with the destination (in which case the source

includes a digital signature that the destination can verify) or
independently

from the destination (in which case the source can include any type of

signature it likes). Your question seems to stem from the former case:

 

> 1. SEAL IPv6 extension header functionality is similar to AH header
functionality

> which is already standardized in RFC 2402(IP Authentication Header). AH
header

> also calculates the ICV of the packet [Section 3.3.3.1.2 ICV Computation
for IPv6

> in RFC 2402] which is used to check the integrity of the packet. So what
is the

> advantage of using SEAL header over AH header?

 

When the source and destination share a secret key used for digital
signature

calculation and verification, it is true that SEAL somewhat resembles AH.

However, the SEAL source only calculates the digital signature over the
leading

128 bytes of the packet beginning with the SEAL header itself. So, unlike
AH,

the digital signature does not cover the entire packet and does not cover a

pseudo-header of the IPv6 header.

 

This has two important implications. First, when a router on the path needs
to

drop an IPv6 packet with a SEAL option and return an ICMP error message, the

packet-in-error within the ICMP will include enough of the leading portion
of the

SEAL packet so that the source can verify that the ICMP was generated by an

on-path router. The same is not true for AH, since the AH ICV covers the
entire

packet, and the packet-in-error field within the ICMP message may not
include

the entire packet. Second, the digital signature will remain valid even if
the IPv6

header is subject to network address translation.

 

------------------------------

 

Message: 3

Message-ID: <mailman.1071.1326393779.3200.ipv6@ietf.org>

 

ight

weight data origin authentication and integrity checking capability for the

leading 128 bytes of the packet. The Identification field additionally prov=

ides

the destination with a means to detect replayed packets. Note that this

provides less authentication assurance than AH, since a middlebox on the

path could alter the "tail" of the packet beyond the leading 128 bytes. But=

,

it defeats off-path spoofing attacks.

 

Note again that, when the source and destination are not engaged in a

digital signing and verification relationship, the source could sign the

message any way it wants, e.g., by writing a constant or time-varying

nonce. In that case, the destination would be vulnerable to an off-path

attacker guessing the nonce and hence should not use the nonce as

a data origin authentication signature.

 

Thanks - Fred

 

PS The number 128 was chosen so that enough of the packet would be

included to provide sufficient inter-packet diversity in calculating the di=

gital

signature. However, I could also see an arguement for a smaller number,

e.g., 64, 80, 96, etc.