RE:Pre-draft: SEAL as an IPv6 extension header (was:Fragmentation-related Security issues)

[Sreenatha setty <[e-mail]>]

Hi Fred,

      I went through SEAL as an IPv6 extension header draft. I have some
comments on the drafts.

 

            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?

      2. Security Consideration section of the draft contains  two spelling
mistakes:  

 

       " 4.  Security Considerations

 

          The SEAL extension header can be used to verify that ICMPv6
messages

          wre delivered by an on-path router and not an off-path attacker.
The

          header may also be used fro other authenticating purposes, e.g.,
if

          the destination shares a symmetric secret key with the source then

          the destination can verify that messages actually came from the

          source.  The packet identification field can also be used for
anti-

          replay sequencing."

 

Thanks & Regards,

Sreenatha Setty

[e-mail]

 

 

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Tuesday, January 10, 2012 11:24 PM
To: [e-mail]
Subject: ipv6 Digest, Vol 93, Issue 25

 

If you have received this digest without all the individual message

attachments you will need to update your digest options in your list

subscription.  To do so, go to 

 

https://www.ietf.org/mailman/listinfo/ipv6

 

Click the 'Unsubscribe or edit options' button, log in, and set "Get

MIME or Plain Text Digests?" to MIME.  You can set this option

globally for all the list digests you receive at this point.

 

 

 

Send ipv6 mailing list submissions to

      [e-mail]

 

To subscribe or unsubscribe via the World Wide Web, visit

      https://www.ietf.org/mailman/listinfo/ipv6

or, via email, send a message with subject or body 'help' to

      [e-mail]

 

You can reach the person managing the list at

      [e-mail]

 

When replying, please edit your Subject line so it is more specific

than "Re: Contents of ipv6 digest..."

 

 

Today's Topics:

 

   1. Re: Non-traditional PMTUD [was Re: Fragmentation-related

      security    issues] (Brian E Carpenter)

   2. Re: Fragmentation-related security issues (Brian E Carpenter)

   3. Re: Fragmentation-related security issues (Fernando Gont)

   4. AD review of draft-ietf-6man-3627-historic (Jari Arkko)

   5. Last Call: <draft-ietf-6man-3627-historic-01.txt> (RFC3627 to

      Historic status) to Informational RFC (The IESG)

   6. Pre-draft: SEAL as an IPv6 extension header (was:

      Fragmentation-related Security issues) (Templin, Fred L)

 

 

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

 

Message: 1

Date: Tue, 10 Jan 2012 09:40:45 +1300

From: Brian E Carpenter <[e-mail]>

To: Fred Baker <[e-mail]>

Cc: "[e-mail]" <[e-mail]>

Subject: Re: Non-traditional PMTUD [was Re: Fragmentation-related

      security    issues]

Message-ID: <[e-mail]>

Content-Type: text/plain; charset=UTF-8

 

On 2012-01-10 06:08, Fred Baker wrote:

> On Jan 6, 2012, at 8:26 PM, Fernando Gont wrote:

> 

>> I just said that PLPMTU has a long convergence time

> 

> Frankly, that sounds like an implementation issue. If we're willing to set
IW=10, it seems like one should be able to send the initial burst, or at
least the first retransmission, with messages of several sizes and see what
works. In other words, if the MSS is 9K (I wish), send a 9K, a 4K, a 1500
byte IP datagram (eg 1440 byte payload), and 1280. If we get an Ack in the
subsequent RTT acknowledging 8192 bytes, we learned something, and if the
only Ack acknowledges 1280, we learned something.

 

Right. And the point Fernando queried in my previous message was

simply trying to say "happy eyeballs doesn't do this" - it will leave

the user hanging if TCP connects but PMTUD or MSS negotiation fails.

 

   Brian

 

 

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

 

Message: 2

Date: Tue, 10 Jan 2012 09:49:39 +1300

From: Brian E Carpenter <[e-mail]>

To: Fernando Gont <[e-mail]>

Cc: Brian Haberman <[e-mail]>, [e-mail]

Subject: Re: Fragmentation-related security issues

Message-ID: <[e-mail]>

Content-Type: text/plain; charset=UTF-8

 

On 2012-01-09 22:37, Fernando Gont wrote:

> On 01/09/2012 05:32 AM, Florian Weimer wrote:

>>>> The ULA will have no meaning for ICMP messages that leave the

>>>> administrative domain.

>>> That doesn't matter,

>> How do you implement BCP38 filters if the address lacks clear ownership?

> 

> Same thing would happen as it currently happens with ICMP error messages

> sourced from private addresses: some get "mysteriously" dropped. -- i.e.

> using ULAs for the source address of ICMPv6 messages seems like a very

> bad idea.

 

It's a bad idea, but using link-local is even worse, because those

MUST be dropped.

 

I don't think ULAs will be stopped by ingress filters in the case that

people over on v6ops were complaining about, where ICMP echo replies

were sent by ISP-internal routers. ULAs will be stopped by ingress

filters if a customer site uses them for ICMP replies.

 

We agree that using a globally routeable address is best.

 

   Brian

 

 

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

 

Message: 3

Date: Mon, 09 Jan 2012 12:42:50 -0300

From: Fernando Gont <[e-mail]>

To: "Templin, Fred L" <[e-mail]>

Cc: Brian Haberman <[e-mail]>, "[e-mail]"

      <[e-mail]>,  Brian E Carpenter <[e-mail]>

Subject: Re: Fragmentation-related security issues

Message-ID: <[e-mail]>

Content-Type: text/plain; charset=ISO-8859-1

 

On 01/09/2012 12:18 PM, Templin, Fred L wrote:

>> Same thing would happen as it currently happens with ICMP 

>> error messages

>> sourced from private addresses: some get "mysteriously" 

>> dropped. -- i.e.

>> using ULAs for the source address of ICMPv6 messages seems like a very

>> bad idea.

> 

> What I care most about is the value of the source address

> from the perspecive of the ICMP message recipient. 

 

That depends on what you're using ICMP for. If it's for troubleshootinf

(ping, traceroute, etc.), the Source Address has some value. If the

ICMPs are meant to be processed by a transport layer (as in PMTUD), the

the Source Address is of no value (it could correspond to the address of

any intervenning router, and since virtually every router could be an

"intervenning router", you cannoT "validate" the source address.

 

 

> I think

> no matter the source address scope, the recipinet cannot

> use the source address alone as a means of authenticating

> the ICMP, since there is no guarantee that BCP38 is

> universally implemented. Right?

 

Right. See RFC 5927.

 

Thanks,

-- 

Fernando Gont

e-mail: [e-mail] || [e-mail]

PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

 

 

 

 

 

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

 

Message: 4

Date: Tue, 10 Jan 2012 16:55:19 +0200

From: Jari Arkko <[e-mail]>

To: [e-mail],     IETF IPv6 Mailing

      List <[e-mail]>

Subject: AD review of draft-ietf-6man-3627-historic

Message-ID: <[e-mail]>

Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 

I have reviewed this document, and as it obviously was ready to be moved
forward, asked for an IETF Last Call to be initiated. Thanks for writing the
document.

 

Jari

 

 

 

 

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

 

Message: 5

Date: Tue, 10 Jan 2012 08:00:47 -0800

From: The IESG <[e-mail]>

To: IETF-Announce <[e-mail]>

Cc: [e-mail]

Subject: Last Call: <draft-ietf-6man-3627-historic-01.txt> (RFC3627 to

      Historic status) to Informational RFC

Message-ID: <[e-mail]>

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

 

 

The IESG has received a request from the IPv6 Maintenance WG (6man) to

consider the following document:

- 'RFC3627 to Historic status'

  <draft-ietf-6man-3627-historic-01.txt> as an Informational RFC

 

The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

[e-mail] mailing lists by 2012-01-24. Exceptionally, comments may be

sent to [e-mail] instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.

 

Abstract

 

 

   This document moves RFC3627 (Use of /127 Prefix Length Between

   Routers Considered Harmful) to HISTORIC status to reflect the updated

   guidance contained in RFC6164 (Using 127-Bit IPv6 Prefixes on Inter-

   Router Links).  While a standards track document already supersedes

   an informational document and therefore RFC6164 is the appropriate

   guidance to follow when the two documents are in conflict, this links

   the two documents so that it is clearer that the IETF has updated

   guidance on the matter.

 

 

 

 

The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-6man-3627-historic/

 

IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-6man-3627-historic/

 

 

No IPR declarations have been submitted directly on this I-D.

 

 

 

 

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

 

Message: 6

Date: Tue, 10 Jan 2012 09:53:43 -0800

From: "Templin, Fred L" <[e-mail]>

To: "[e-mail]" <[e-mail]>

Subject: Pre-draft: SEAL as an IPv6 extension header (was:

      Fragmentation-related Security issues)

Message-ID:

 
<[e-mail]>

      

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

 

Please see below for a pre-draft for using the Subnetwork

Encapsulation and Adaptation Layer (SEAL) as an IPv6 extension

header. This extension header can be used by the source to

defeat off-path spoofing of ICMPv6 error messages. When the

source and destination share a secret symmetric key used for

calculating the integrity check vector, the extension header

also provides the destination with data origin authentication

and anti-replay.

 

Please send any comments to the list,

 

Fred

[e-mail]

 

--- cut here ---

 

 

 

 

Network Working Group                                    F. Templin, Ed.

Internet-Draft                              Boeing Research & Technology

Intended status: Informational                          January 10, 2012

Expires: July 13, 2012

 

 

                     The SEAL IPv6 Extension Header

                       draft-templin-sealopt.txt

 

Abstract

 

   The Subnetwork Encapsulation and Adaptation Layer (SEAL) provides a

   mid-layer header designed for the encapsulation of an inner network

   layer packet within outer network layer headers.  SEAL also supports

   a transport mode of operation, where the inner payload corresponds to

   an ordinary transport layer payload.  However, SEAL can also provide

   benefit when used as an IPv6 extension header.  Namely, the SEAL

   header when used as an extension header contains a digital signature

   (inserted by the source) that covers the leading 128 bytes of the

   payload beginning with the SEAL header itself.  The source can

   thereafter use the digital signature to verify that any ICMPv6

   mesages received actually came from a router on the path.

 

Status of this Memo

 

   This Internet-Draft is submitted in full conformance with the

   provisions of BCP 78 and BCP 79.

 

   Internet-Drafts are working documents of the Internet Engineering

   Task Force (IETF).  Note that other groups may also distribute

   working documents as Internet-Drafts.  The list of current Internet-

   Drafts is at http://datatracker.ietf.org/drafts/current/.

 

   Internet-Drafts are draft documents valid for a maximum of six months

   and may be updated, replaced, or obsoleted by other documents at any

   time.  It is inappropriate to use Internet-Drafts as reference

   material or to cite them other than as "work in progress."

 

   This Internet-Draft will expire on July 13, 2012.

 

Copyright Notice

 

   Copyright (c) 2012 IETF Trust and the persons identified as the

   document authors.  All rights reserved.

 

   This document is subject to BCP 78 and the IETF Trust's Legal

   Provisions Relating to IETF Documents

   (http://trustee.ietf.org/license-info) in effect on the date of

 

 

 

Templin                   Expires July 13, 2012                 [Page 1]




 

Internet-Draft                    SEAL                      January 2012

 

 

   publication of this document.  Please review these documents

   carefully, as they describe your rights and restrictions with respect

   to this document.  Code Components extracted from this document must

   include Simplified BSD License text as described in Section 4.e of

   the Trust Legal Provisions and are provided without warranty as

   described in the Simplified BSD License.

 

 

Table of Contents

 

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3

   2.  SEAL IPv6 Extension Header  . . . . . . . . . . . . . . . . . . 3

   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4

   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4

   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4

   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4

     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 4

     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5

   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Templin                   Expires July 13, 2012                 [Page 2]




 

Internet-Draft                    SEAL                      January 2012

 

 

1.  Introduction

 

   The Subnetwork Encapsulation and Adaptation Layer (SEAL)

   [I-D.templin-intarea-seal] provides a mid-layer encapsulation

   designed for the encapsulation of an inner network layer packet

   within outer network layer headers.  SEAL also supports a transport

   mode of operation, where the encapsulated payload corresponds to an

   ordinary transport layer protocol payload.  It is in essence a close

   analogy of the GRE encapsulation format [RFC1701].

 

   However, SEAL can also provide benefit when used as an IPv6 extension

   header [RFC2460].  Namely, the SEAL header when used as an IPv6

   extension header contains a digital signature (inserted by the

   source) that covers the leading 128 bytes of the payload beginning

   with the SEAL header itself.  The source can thereafter use the

   digital signature to verify that any ICMPv6 mesages received actually

   came from a router on the path.

 

 

2.  SEAL IPv6 Extension Header

 

   The SEAL IPv6 extension header is formatted as follows:

 

       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |  Next Header  |Hdr Ext Len = 2|    SEAL Header (format TBD)   |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                         Identification                        |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                 Integrity Check Vector (ICV)                  |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                          Reserved                             |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

                Figure 1: SEAL IPv6 Extension Header Format

 

   Next Header (8)  an 8-bit field that encodes the next header Internet

      Protocol number the same as for the IPv4 protocol and IPv6 next

      header fields.

 

   Next Header Length (8)  an 8-bit length of the extension header

      measured in 8-byte words.  Set to 2.

 

   SEAL Header (16)

      a 16-bit field that controls the operation of SEAL.  Format TBD.

 

 

 

 

 

Templin                   Expires July 13, 2012                 [Page 3]




 

Internet-Draft                    SEAL                      January 2012

 

 

   Identification (32)

      a 32-bit per-packet identification field.  Set to a monotonically-

      incrementing 32-bit value for each SEAL packet transmitted,

      beginning with 0.

 

   Integrity Check Vector (ICV) (32)

      a 32-bit header integrity check value.  Covers the leading 128

      bytes of the packet beginning with the SEAL extension header (or

      up to the end of the packet).  The value 128 is chosen so that at

      least the SEAL header as well as the inner packet network and

      transport layer headers are covered by the integrity check.

 

   The IPv6 source inserts a SEAL extension header whenever it wants to

   ensure that any resulting ICMPv6 error messages [RFC4443] came from a

   router on the path and not from an off-path attacker.  When the

   source receives an ICMPv6 error message, it verifies that the ICV

   value is correct based on a secret hashing algorithm of its choosing.

   The source should choose a hashing algorithm that would make it

   virtually impossible for an off-path attacker to guess.

 

 

3.  IANA Considerations

 

   The IANA is instructed to allocate an IPv6 extension header for SEAL.

 

 

4.  Security Considerations

 

   The SEAL extension header can be used to verify that ICMPv6 messages

   wre delivered by an on-path router and not an off-path attacker.  The

   header may also be used fro other authenticating purposes, e.g., if

   the destination shares a symmetric secret key with the source then

   the destination can verify that messages actually came from the

   source.  The packet identification field can also be used for anti-

   replay sequencing.

 

 

5.  Acknowledgments

 

   TBD.

 

 

6.  References

 

6.1.  Normative References

 

   [I-D.templin-intarea-seal]

              Templin, F., "The Subnetwork Encapsulation and Adaptation

 

 

 

Templin                   Expires July 13, 2012                 [Page 4]




 

Internet-Draft                    SEAL                      January 2012

 

 

              Layer (SEAL)", draft-templin-intarea-seal-42 (work in

              progress), December 2011.

 

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6

              (IPv6) Specification", RFC 2460, December 1998.

 

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control

              Message Protocol (ICMPv6) for the Internet Protocol

              Version 6 (IPv6) Specification", RFC 4443, March 2006.

 

6.2.  Informative References

 

   [RFC1701]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic

              Routing Encapsulation (GRE)", RFC 1701, October 1994.

 

 

Author's Address

 

   Fred L. Templin (editor)

   Boeing Research & Technology

   P.O. Box 3707

   Seattle, WA  98124

   USA

 

   Email: [e-mail]

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Templin                   Expires July 13, 2012                 [Page 5]




 

 

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

 

_______________________________________________

ipv6 mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/ipv6

 

 

End of ipv6 Digest, Vol 93, Issue 25

************************************