On Tue, Nov 29, 2016 at 12:04 PM, Joe Touch <[email protected]> wrote: > Hi Brian, > > > On 11/29/2016 11:43 AM, Brian E Carpenter wrote: >> Joe, >> >> On 29/11/2016 17:38, Joe Touch wrote: >>> Hi, Brian, >>> >>> >>> On 11/28/2016 7:59 PM, Brian E Carpenter wrote: >>>> Hi, >>>> >>>> My first question is not whether it's a good idea to build an IP VPN over >>>> IP tunnels, because I'm sure it is. It is more whether we actually need >>>> a BCP describing how to do it, rather than just, say, open-source code >>>> for a VRF instance that does this. >>> +1 >>>> I think that question is definitely worth exploring, and is probably a big >>>> enough question to deserve a BOF (not necessarily a WG-forming BOF). But >>>> that needs to be based on a more problem-oriented and analytic draft, I >>>> think. >>>> It definitely needs expertise from the Transport Area as well as the >>>> Internet >>>> Area, to get the congestion management right. >>> -1 >>> >>> We already have RFC6040. >> Doesn't that only apply with ECN-capable end points? > > Yes. Where those aren't available, IP over IP tunnels (or IP over X over > IP) provide the same "congestion control" that all links do (i.e., none). > >> >>> This isn't a transport problem (if it is, it >>> has been done incorrectly - see below). >> No, but it might induce interesting transport problems if the tunnel behaves >> other than as a piece of wire. RFC6077 seems to identify a number of open >> problems in this area, but you certainly know more about this than I do. > > The place to go here if you want bandwidth guarantees or rate limits > within a tunnel is PWE, but again that's not transport. I'm not saying > there should be no congestion control, only that it's a different animal > than at the transport layer. > >> >>>> For the moment, I am quite unable to judge whether the proposal in this >>>> draft >>>> to use GRE-in-UDP or GUE is the best answer. >>> There can be no single answer to that question. Like regular links, >>> tunnels (virtual links) vary with their environment, and should. >>>> I also don't really understand >>>> the security model. There is some discussion of IPsec tunnels and RFC3884. >>>> If we use IPsec tunnels, why would we need DTLS? For that matter, if we use >>>> TLS tunnels, why would we need DTLS? >>> TLS is a very bad idea. We should never try to tunnel IP over TCP. >> I agree it's a terrible idea, but pragmatically situations can arrive where >> it's >> the only real option. > > Sure, but it's bad enough to try to avoid if there are other alternatives. > This is why we like DTLS as opposed to IPsec, to the network this just looks like UDP which presumably is more palatable to some network devices. DTLS can also be implemented by an application (e.g. in userspace). GUE with DTLS is nice because we can have both an extensible encapsulation header that might read readable by the network as well as a secured payload.
>>> DTLS might be available where IPsec isn't. >> If that is the case, it needs to be explained in more detail in the draft. > > Agreed. > >> Anyway it needs to be a clear choice: IPsec or DTLS, but not both. >> (This is a point that has also come up in the Anima WG, as it happens.) > > Agreed as well. > I'm not sure I understand why this is a binary choice. The draft isn't requiring any particular tunnel encapsulation and so security isn't be required (might depend on encapsulation). Or does this mean that we want to avoid using DTLS or TLS simultaneously on the same packets? (which does some like a bad idea...) Thanks, Tom > Joe > >> >> Brian >> >>>> I'm also quite unable to know how to position this proposal compared to >>>> https://tools.ietf.org/html/draft-templin-aerolink which has been >>>> in development for several years. They seem to tackle some of the same >>>> problems. >>> +1 >>>> Regards >>>> Brian Carpenter >>>> >>>> >>>> _______________________________________________ >>>> Int-area mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/int-area >>> > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
