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 --------------------------------------------------------------------