Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC
Thanks for your review, Pekka. A few notes: it doesn't go into much detail on how they solved difficult and more interesting issues, for example: - how they solved MTU problems caused by adding hop-by-hop header - given their deployment model, why didn't they try inserting a destination options header instead of hop-by-hop and if they tried, why it didn't work; - how did the rekeying of inter-AS solution work (not described) These would increase the value of the report. This would be very useful addition to the document. Authors? But note that the overall experience from the specific approach chosen here was that yes, its possible get it to working, but there are significant issues both for deployment and for the way the protocol bits are arranged. Remember that this was an experiment, not a design ready for standardization. MTU problems are in the list that is in Section 5.3. I object to publishing the draft as written. At least issue 1) below needs to be fixed before publication because the draft is confusing and misrepresentative of the scope of existing solution solution space. 1) Access Network SAV and Intra-AS SAV terminology misrepresents the applicability of BCP38/84 and needs to be rephrased. We use the term intra-AS source address validation to mean the IP source address validation at the attachment point of an access network to its provider network, also called the ingress point. IP source address validation at ingress points can enforce the source IP address correctness at the IP prefix level, assuming the access network owns one or more IP address blocks. This practice has been adopted as the Internet Best-Current-Practice [RFC2827][RFC3704]. This text (also to some degree the previous paragraph) and Figure 1 are confusing. In Figure 1, Intra-AS SAV occurs between two routers is construed as if it was only applicable between routers. BCP38 and BCP84 are applicable also in scenarios which are in the figure listed under Access Network SAV, not just under intras-AS SAV. Specifically, BCP38/84 can be applied on each LAN interface of a router. In case router connects just one host, that is also a sufficient solution and nothing else is needed. Right. This needs to be corrected in the draft. I am not commenting on the remaining issues, but I expect the authors to address them in a new revision of their document. Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC
On Fri, 28 Mar 2008, Jari Arkko wrote: This would be very useful addition to the document. Authors? But note that the overall experience from the specific approach chosen here was that yes, its possible get it to working, but there are significant issues both for deployment and for the way the protocol bits are arranged. Remember that this was an experiment, not a design ready for standardization. MTU problems are in the list that is in Section 5.3. A lot of issues are brought up in Section 5 (and elsewhere). For issues noted, for each I'd like to ask quostions such as: - was this noticed in the testbed? how? - was the issue relevant in that context; if not, why not? - if the issue was noticed, how was it worked around? which approaches worked (in that restricted context), which did not? - if the issue was not worked around, what kind of impact not doing so had in the testbed and in testing? I suspect some of the issues listed were addressed in some way (not necessarily in a globally applicable way). For example, wrt MTU issues, a statement like MTU increase was not an issue because the transit network provided 9000B MTU or Participating hosts were manually configured to use 1280B MTU would have been useful. So, when reading the report, I find it has basically the following kinds of content: 1) some general overview of the problem space 2) description of new mechanisms developed 3) description of the testbed where mechanisms were tested 4) description of issues to be considered in future work However, 4) seems to be mainly about 1) and 2); it would have been possible to write fundamentally the same draft without any significant testbed deployment. In other words, the experiences from the testbed and deployment itself are not extensively captured in the report, and as a result it is not obvious how useful the testbed was when considering follow-up activities in this space. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC
For issues noted, for each I'd like to ask quostions such as: - was this noticed in the testbed? how? - was the issue relevant in that context; if not, why not? - if the issue was noticed, how was it worked around? which approaches worked (in that restricted context), which did not? - if the issue was not worked around, what kind of impact not doing so had in the testbed and in testing? Yes, this would be useful. Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC
On Wed, 19 Mar 2008, Jari Arkko wrote: Just FYI, this draft is being AD sponsored as a report of a research effort that certain people have done in the source address validation space. To quote my ballot explanation: This draft documents an experimental design implemented in a research network for source address validation. The draft is not intended as a solution proposal but rather as a report of something that was done together with both the positive and negative experiences. I've reviewed this draft. I'm not sure what the draft intends to document as it doesn't go into much detail on how they solved difficult and more interesting issues, for example: - how they solved MTU problems caused by adding hop-by-hop header - given their deployment model, why didn't they try inserting a destination options header instead of hop-by-hop and if they tried, why it didn't work; - how did the rekeying of inter-AS solution work (not described) These would increase the value of the report. Even without those, publishing the report may be of some value. However, I object to publishing the draft as written. At least issue 1) below needs to be fixed before publication because the draft is confusing and misrepresentative of the scope of existing solution solution space. 1) Access Network SAV and Intra-AS SAV terminology misrepresents the applicability of BCP38/84 and needs to be rephrased. We use the term intra-AS source address validation to mean the IP source address validation at the attachment point of an access network to its provider network, also called the ingress point. IP source address validation at ingress points can enforce the source IP address correctness at the IP prefix level, assuming the access network owns one or more IP address blocks. This practice has been adopted as the Internet Best-Current-Practice [RFC2827][RFC3704]. This text (also to some degree the previous paragraph) and Figure 1 are confusing. In Figure 1, Intra-AS SAV occurs between two routers is construed as if it was only applicable between routers. BCP38 and BCP84 are applicable also in scenarios which are in the figure listed under Access Network SAV, not just under intras-AS SAV. Specifically, BCP38/84 can be applied on each LAN interface of a router. In case router connects just one host, that is also a sufficient solution and nothing else is needed. The figure needs to be redone. The mechanisms described for Access network SAV are only useful in contexts where multiple hosts attach to a router using a single interface (e.g., using a switch). Otherwise BCP38/84 mechanisms of Intra-AS SAV apply and access network SAV is not necessary. One way to approach this is to change the figure as follows: __ __ .-'' `': .-'' `': | | | | | +-++ | Inter-AS SAV | +-++ | | |Router+--+--+---|Router+ + | +--.---+ | | +--.---+ | Intra-AS | | | Intra-AS | | | SAV | +--+---+ \ SAV | +--+---+ | | |Router|\| |Router| | | +--.---+ \'_ +-+ _ | | \`'---''' / | | /| | | +--+| | | .-. Router || | ++/---\+| | || | | || | ||+--+|+--+|Intra-AS | |||Switch|||Router||SAV | ||+--+|+--+| | ||\_ | \ || |+-+--+\++|++ | ||Host|||Host|||Host| | `.+|++|++,' `--. / | _.-' `---+'' Access Network SAV Further, rephrase: It is important to enforce IP source address validity at the access network. That is, when an IP packet is sent from a host, the routers, switches or other devices should check to make sure that the packet carries a valid source IP address. If this access network source address validation is missing, then a host may be able to spoof the source IP address which belongs to another local host. To: When multiple hosts attach to the same network, switches could check to make sure that the packet carries a valid source IP address. If this access network source address validation is missing, then a host may be able to spoof the source IP address which belongs to another host in the same network. And: We use the term intra-AS source address validation to mean the IP source address validation
Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC
Just FYI, this draft is being AD sponsored as a report of a research effort that certain people have done in the source address validation space. To quote my ballot explanation: This draft documents an experimental design implemented in a research network for source address validation. The draft is not intended as a solution proposal but rather as a report of something that was done together with both the positive and negative experiences. Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
