> -----Original Message----- > From: Alberto García [mailto:alberto@xxxxxxxxxx] > Sent: Tuesday, March 06, 2012 9:07 AM > To: 'Dan Wing'; 'IETF discussion list' > Cc: 'Transport Directorate'; tsv-area@xxxxxxxx; joe.abley@xxxxxxxxx; > 'marcelo bagnulo braun' > Subject: RE: tsv-dir review of draft-garcia-shim6-applicability-03 > > Hi Dan, > Thank you very much for your review > > | -----Mensaje original----- > | De: Dan Wing [mailto:dwing@xxxxxxxxx] > | Enviado el: jueves, 01 de marzo de 2012 3:56 > | Para: 'IETF discussion list' > | CC: 'Transport Directorate'; tsv-area@xxxxxxxx; joe.abley@xxxxxxxxx; > | 'marcelo bagnulo braun'; alberto@xxxxxxxxxx > | Asunto: tsv-dir review of draft-garcia-shim6-applicability-03 > | > | I have reviewed this document as part of the transport area > directorate's > | ongoing effort to review key IETF documents. These comments were > written > | primarily for the transport area directors, but are copied to the > document's > | authors for their information and to allow them to address any > issues > | raised. When done at the time of IETF Last Call, the authors should > consider > | this review together with any other last-call comments they receive. > Please > | always CC tsv-dir@xxxxxxxx if you reply to or forward this review. > | > | This draft is basically ready for publication, but has nits that > should > be fixed > | before publication. > | > | > | > | Nits: > | > | Section 1: > | > | Such problems are not specific of Shim6, but > | are suffered by the hosts of any site which is connected to > multiple > | transit providers, and which receives an IPv6 prefix from each of > the > | providers. > | > | It might be useful to add a non-normative reference to RFC5220 at > the end > | of that sentence. > Ok > > | > | > | Section 3.4: > | > | The use of HBA is more efficient in the sense that addresses > require > | less computation than CGA, involving only hash operations for > both > | the generation and the verification of locator sets. However, > the > | locators of an HBA set are determined during the generation > process, > | and cannot be subsequently changed; the addition of new locators > to > | that initial set is not supported, except by re-generation of the > | entire set which will in turn cause all addresses to change. > | > | I think that paragraph is too harsh, as it implies the old addresses > have > to be > | invalidated immediately. I expect existing connections could > continue > with > | the old addresses, and, if the host wanted to, could even have new > | connections use the old addresses. If that is not possible, the > draft > should > | explain why. If that is possible, the draft should probably explain > it > is > | possible. > | > > I have rewritten the paragraph: > > "The use of HBA is more efficient in the sense that addresses > require > less computation than CGA, involving only hash operations for both > the generation and the verification of locator sets. However, the > locators of an HBA set are determined during the generation process, > and cannot be subsequently changed; the addition of new locators to > that initial set is not supported. Therefore, a node using an HBA > as > ULID for a Shim6 session can only use the locators associated to > that > HBA for the considered Shim6 session. If the node wants to use a > new > set of locators, it has to generate a new HBA including the prefixes > of the new locators (which will result with very high probability in > different addresses to those of the previous set). New sessions > initiated with a ULID belonging to the new HBA address set could use > the new locators." > > Do you think it is now more clear? Yes, thanks. > | > | Section 4: > | > | In order to configure source and destination address selection, > tools > | such as DHCPv6 can be used to disseminate a [RFC3484] policy > table to > | a host. > | > | It might be useful to add a non-normative reference to draft-ietf- > 6man- > | addr-select-opt. > Sure > > | > | > | Section 4: > | > | The sentence ending with "properties exhibited by REAP." needs a > reference > | to RFC5544, which seems to be the RFC defining REAP. > Ok > > | > | > | > | Section 7.7, "Shim6 and IPv6 NAT", the problem could be overcome by > the > | Shim6 node knowing its IPv6 address after NPTv6 translation. > Probably > not > | worth adjusting the document, though, as NPTv6 is experimental. > > Well, this would not work for HBA, since in this case the addresses are > fixed once generated. NPTv6 does not change the host portion of the address (it only changes the network portion -- the IPv6 prefix), so HBA should work with NPTv6. > It could work for the CGA, since the Shim6 host could sign dynamically > the > translated address. But in this case a protocol would be needed to > convey > the translated address to the Shim6 node which has to sign it. A threat > analysis of this operation should be performed, in order not to > introduce > new vulnerabilities in the process... > As you suggest, I think this is not worth. I agree, it can be discussed in a later document, should someone find it useful to have Shim6 work with NPTv6. > | > | > | Section 7.7: > | > | Note that an Application Level Gateway designed to modify the > Shim6 > | control packets would not be able to generate a valid signature, > in > | case a CGA is being used, or a Parameter Data Structure binding > the > | translated locator to the other locators of a node, in case a HBA > is > | being used. Therefore, the same failure cases described before > would > | remain. > | > | Applications are layer 7, Shim6 is layer 3, so an "Application Layer > Gateway" > | that modifies Shim6 control packets seems an abuse of terminology. > | Suggest: > | > | OLD: > | Note that an Application Level Gateway designed to modify the > Shim6 > | control packets would not be able to generate a valid signature, > in > | NEW: > | Note that modification of the Shim6 control packets by the IPv6 > NAT > | > .............^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > | ^ > | would not be able to generate a valid signature, in > > Changed. Thanks. -d > Thanks again, > Alberto > > | > | -d > | > | > | > | > | > | > | _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf