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

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

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.

>From the perspective of the destination, the digital signature provides a light
weight data origin authentication and integrity checking capability for the
leading 128 bytes of the packet. The Identification field additionally provides
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 digital
signature. However, I could also see an arguement for a smaller number,
e.g., 64, 80, 96, etc.

________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Sreenatha setty
Sent: Wednesday, January 11, 2012 8:42 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE:Pre-draft: SEAL as an IPv6 extension header (was:Fragmentation-related Security issues)


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

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