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

[Sreenatha setty <[e-mail]>]

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" <[e-mail]>

To: Sreenatha setty <[e-mail]>, "[e-mail]"

      <[e-mail]>

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

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

      (was:Fragmentation-related Security issues)

Message-ID:

 
<[e-mail]>

      

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: <[e-mail]>

 

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.