Dear all, 1. 2012-06-29 à 14:24, Suresh Krishnan: ... > submit the -02 identical to -00.
Done with tools.ietf.org/html/draft-ietf-softwire-4rd-02 > We can handle any further issues using the issue tracker. Will learn how to do it. 2. Please take the copied email below and tools.ietf.org/html/draft-ietf-softwire-4rd-01 as: - identification of a possible security improvement of 4rd from 4rd-02 - description of the solution, presented as an update of the draft combined with some editorial improvements.) Authors propose to the WG to update -02 by a re-issue of -01 as -03. Any objection? Regards, RD > De : Rémi Després <[email protected]> > Date : 2012-06-19 15:28 > À : Softwires WG <[email protected]> > Objet : Novelty in draft-ietf-softwire-4rd-01 > > Dear all, > > The main difference between -00 and -O1 concerns protection against address > or protocol corruption during 4rd-domain traversal: > Problem: the CNP only protected IPv4 addresses of full-or-shared-address CEs? > In particular, they didn't protect IPv4 addresses embedded in BR-destined > IPv6 addresses (an overlook) > Solution: include a checksum of IPv4 addresses and protocol in the flow label > field > . It provides the desirable protection in a simple and intuitive way > . It remains compatible with the flow-label specification (see below) > > > Relationship with FLs of RFC6437 is analyzed as follows: > > a) RFC6437 says "A node that forwards a flow whose flow label value in > arriving packets is zero MAY change the flow label value. In that case, it > is RECOMMENDED that the forwarding node sets the flow label field for a flow > to a uniformly distributed value as just described for source nodes. ... In > such cases, a flow can be defined by fewer IPv6 header fields, typically > using only the 2-tuple {dest addr, source addr}." > > b) In CEs and BRs, arriving packets are IPv4, i.e. equivalent to packets > without FLs. > > c) In RFC2119, "RECOMMENDED" means that "there may exist valid reasons in > particular circumstances to ignore a particular item, but the full > implications must be understood and carefully weighed before choosing a > different course". > > d) Implications, which have been well understood, have also been well > weighted: > - With this, FLs of 5-tuple flows aren't evenly distributed FLs, contrary to > what is recommended > - BUT this maintains IPv4 addresses-and-port protection without needing any > extra header between the IPv6 header and the unchanged IP payload, a > desirable feature of 4rd. > > Comments on all aspects of the proposal are welcome. > > Regards, > RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
