Re: potential new IETF WG on anonymous IPSec
Bill Stewart wrote: At 12:57 PM 9/9/2004, Hal Finney wrote: > http://www.postel.org/anonsec To clarify, this is not really "anonymous" in the usual sense. Rather it is a proposal to an extension to IPsec to allow for unauthenticated connections. Presently IPsec relies on either pre-shared secrets or a trusted third party CA to authenticate the connection. The new proposal would let connections go forward using a straight Diffie-Hellman type exchange without authentication. It also proposes less authentication of IP message packets, covering smaller subsets, as an option. I read the draft, and I don't see how it offers any improvement over draft-ietf-ipsec-internet-key-00.txt or Gilmore's proposal touse "open secret" as a not-very-secret pre-shared secret that anybody who wants to can accept. That is part of the solution, but not all, as noted below. It does introduce some lower-horsepower alternatives for authenticating less than the entire packet, and suggests using AH which I thought was getting rather deprecated these days, but another way to reduce horsepower needs is to use AES instead of 3DES. That is corrected in draft-touch-tcp-antispoof, which contains the BGP focus of anonsec-00; anonsec-01 (to appear in about 2 weeks) focuses on just the anonsec portion of 00. Also, the author's document discusses protecting BGP to prevent some of the recent denial-of-service attacks, and asks for confirmation about the assertion in a message on the IPSEC mailing list suggesting "E.g., it is not feasible for BGP routers to be configured with the appropriate certificate authorities of hundreds of thousands of peers". Routers typically use BGP to peer with a small number of partners, though some big ISP gateway routers might peer with a few hundred. (A typical enterprise router would have 2-3 peers if it does BGP.) If a router wants to learn full internet routes from its peers, it might learn 1-200,000, but that's not the number of direct connections that it has - it's information it learns using those connections. And the peers don't have to be configured "rapidly without external assistance" - you typically set up the peering link when you're setting up the connection between an ISP and a customer or a pair of ISPs, and if you want to use a CA mechanism to certify X.509 certs, you can set up that information at the same time. Thanks for that input; the claim that BGP in core Internet routers required intractible setup for TCP-MD5 has been refuted by experience noted during the TCPM WG meeting in San Diego as well. This section of tcp-antispoof will be updated accordingly. Joe Bill Stewart [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: potential new IETF WG on anonymous IPSec
Ian Grigg wrote: Bill Stewart wrote: Also, the author's document discusses protecting BGP to prevent some of the recent denial-of-service attacks, and asks for confirmation about the assertion in a message on the IPSEC mailing list suggesting "E.g., it is not feasible for BGP routers to be configured with the appropriate certificate authorities of hundreds of thousands of peers". Routers typically use BGP to peer with a small number of partners, though some big ISP gateway routers might peer with a few hundred. (A typical enterprise router would have 2-3 peers if it does BGP.) If a router wants to learn full internet routes from its peers, it might learn 1-200,000, but that's not the number of direct connections that it has - it's information it learns using those connections. And the peers don't have to be configured "rapidly without external assistance" - you typically set up the peering link when you're setting up the connection between an ISP and a customer or a pair of ISPs, and if you want to use a CA mechanism to certify X.509 certs, you can set up that information at the same time. On the backbone, between BGP peers, one would have thought that there are relatively few attackers, as the staff are highly trusted and the wires are hard to access - hence no active attacks going on and only some passive eavesdropping attacks. Also, anyone setting up BGP routing knows the other party, so there is a prior relationship. My understanding of the attacks this past spring is that: a) they were indeed on the backbone BGP peers b) that those peers had avoided setting up preshared keys or getting mutually-authenticatable certificates because of the configuration overhead (small on a per-pair basis, but may be large in aggregate) While inspired by this issue, there may be other solutions (e.g., IMO IPsec) which are more appropriate for BGP peers. The whole point of the CA model is that there is no prior relationship and that the network is a wild wild west sort of place Except that certs need to be signed by authorities that are trusted. - both of these assumptions seem to be reversed in the backbone world, no? So one would think that using opportunistic cryptography would be ideal for the BGP world? iang I wouldn't think that the encryption need be opportunistic; in the BGP backbone world, as you noted, peers are known a-priori, and should have certs that could be signed by well-known, trusted CAs. Joe signature.asc Description: OpenPGP digital signature
Re: potential new IETF WG on anonymous IPSec
Bill Stewart wrote: At 02:17 PM 9/16/2004, Joe Touch wrote: Ian Grigg wrote: On the backbone, between BGP peers, one would have thought that there are relatively few attackers, as the staff are highly trusted and the wires are hard to access - hence no active attacks going on and only some passive eavesdropping attacks. Also, anyone setting up BGP routing knows the other party, so there is a prior relationship. My understanding of the attacks this past spring is that: a) they were indeed on the backbone BGP peers b) that those peers had avoided setting up preshared keys or getting mutually-authenticatable certificates because of the configuration overhead (small on a per-pair basis, but may be large in aggregate) The interesting attacks were a sequence-number guessing attack using forged TCP RST packets, which tell the TCP session to tear down, therefore dropping the BGP connection (typically between two ISPs). The attackers didn't need to be trusted backbone routers - they could be randoms anywhere on the Internet. BGP authentication doesn't actually help this problem, because the attack simply kills the connection at a TCP layer rather than lying to the BGP application. FWIW, the other system we were referring to - TCP-MD5 - works at the TCP layer. It rejects packets within TCP, before any further TCP processing, that don't match the MD5 hash. It isn't BGP authentication. This is why I refer to it as TCP-MD5 rather than BGP-MD5, even though the latter is more common. Joe signature.asc Description: OpenPGP digital signature
Re: potential new IETF WG on anonymous IPSec
Ian Grigg wrote: ... I wouldn't think that the encryption need be opportunistic; in the BGP backbone world, as you noted, peers are known a-priori, and should have certs that could be signed by well-known, trusted CAs. Let's see if I can make these assumptions clearer, because I still perceive that CAs have no place in BGP, and you seem to be assuming that they do. I should have said "could have certs". BGP could use shared secrets or CAs; it may be the case that anonymous security (as at least I call it) doesn't map well to BGP, in which you usually know who you want to trust. It may still help, though - e.g., in the case of the recent TCP RST attacks, it would have. The rest of your note focuses on the difference between two-party trust and trust using a shared third party. The former degenerates to the latter where I sign your cert, though ;-) I agree that for BGP the two-party case is probably more relevant, though there some BGP peerings are based on trust relationships of sets of parties that can - or already do - have trusted third-party coordination outside BGP. Joe signature.asc Description: OpenPGP digital signature
