> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Templin, Fred L > Sent: Monday, January 09, 2012 7:35 AM > To: Florian Weimer > Cc: Brian Haberman; [email protected]; Brian E Carpenter > Subject: RE: Fragmentation-related security issues > > > > > -----Original Message----- > > From: Florian Weimer [mailto:[email protected]] > > Sent: Monday, January 09, 2012 7:24 AM > > To: Templin, Fred L > > Cc: Fernando Gont; Brian Haberman; [email protected]; Brian E Carpenter > > Subject: Re: Fragmentation-related security issues > > > > * Fred L. Templin: > > > > > What I care most about is the value of the source address > > > from the perspecive of the ICMP message recipient. 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? > > > > No, the recipient faces a different, even more difficult > > challenge: even > > if the source address is validated based on BCP38, the > > recipient doesn't > > know if the node with that address was actually on the path of the > > triggering packet and thus authorized to send the ICMP message. > > Right - that is exactly why something like SEAL is useful. > With SEAL, the ICMP recipient can know that the sender of > the ICMP message is on-path, because the packet-in-error > contains a digital signature that the recipient himself > provided. That is why I said that the source address alone > cannot be used to authenticate the ICMP message.
BTW, this is specified in Section 4.4.7 of http://tools.ietf.org/html/draft-templin-intarea-seal-42 (it does not appear in RFC5320, which will be deprecated by the RFC-to-be based on this new draft.) Thanks - Fred [email protected] > Thanks - Fred > [email protected] > > > -- > > Florian Weimer <[email protected]> > > BFK edv-consulting GmbH http://www.bfk.de/ > > Kriegsstraße 100 tel: +49-721-96201-1 > > D-76133 Karlsruhe fax: +49-721-96201-99 > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
