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.temp...@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-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Templin, Fred L
Sent: Friday, January 13, 2012 9:37 AM
To: Sreenatha setty; fltemp...@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-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Sreenatha setty
Sent: Thursday, January 12, 2012 8:45 PM
To: fltemp...@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.temp...@boeing.com>
To: Sreenatha setty <sreenath...@huawei.com>, "fltemp...@acm.org"
<fltemp...@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:
<e1829b60731d1740bb7a0626b4faf0a65c793af...@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.i...@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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
