Re: NAT etc. (was: Spam Control Considered Harmful)
Date: Sat, 1 Nov 1997 17:37:57 -0500 From: "Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us> To: "You're welcome" <nanog@merit.edu> Subject: Re: NAT etc. (was: Spam Control Considered Harmful) [...] Well, yes, Paul, but unless I misunderstood you, that's exactly the point. If a client inside a NAT cloud does a DNS lookup to a supposedly authoritative server outside, and the NAT box is _required_ to strip off the signature (which it would, because it has to change the data), then it's not possibile, by definition, for any client inside such a NAT box to make any use of SecDNS.
The point is that you _can't_ regenerate the signature, usefully to the client, anyway, precisely because _it is a signature_.
Presumably, the NAT could, o Verify the signature of the DNS responses it receives, and dump any responses that don't meet its [authentication] criteria, or o Sign the the response it creates and let the client verify the NAT's signature. Presumably, the client will trust the NAT. -tjs
Does anyone know if ANS, digex, mci etc. provide communities that encompass their internal/customer routes? If certain ones don't, is there any reason that they have against such a community? Thanks. BR Bradley Reynolds breynolds@iagnet.net Internet Access Group
Does anyone know if ANS, digex, mci etc. provide communities that encompass their internal/customer routes?
Can you be a little more precise? Most providers probably use communities to tag subsets of the routes they carry, and some set of those communities, either through inclusion or exclusion, almost certainly describes the set of customer routes carried by that provider. (I'm sure this can be stated more clearly.) GTE certainly does, I'm pretty sure MCI still does, etc. Now, will we "provide" these communities? Do you mean send-community to a customer? To a peer? Many of a provider's internal communities would be at best irrelevant and at worst potentially harmful in the context of another AS's policy. With no good way to delete such communities while preserving communities that describe their customer base (and ixnay on "match community... set community") why would a provider want to send all community tags to either a customer or a peer? Another question is, "Why do you want this info?" Taking full transit routes from a provider and trying to set localpref or MED based on whether the destination is a customer or peer network? If you are taking transit, there are good arguments for *not* running default-free.
If certain ones don't, is there any reason that they have against such a community?
See above. Some/most providers can probably be convinced to send community-tagged routes to customers (hey, the customer's not *always* wrong, and it depends on how much proprietary configuration info a provider is worried about conveying -- of course, I find this last amounts to mostly hogwash). Nobody's going to send them to peer networks. ---- Kirby Files Network Engineer GTE Internetworking kfiles@bbnplanet.com
On Sun, 2 Nov 1997, Kirby Files wrote:
Can you be a little more precise? Most providers probably use communities to tag subsets of the routes they carry, and some set of those communities, either through inclusion or exclusion, almost certainly describes the set of customer routes carried by that provider. (I'm sure this can be stated more clearly.) GTE certainly does, I'm pretty sure MCI still does, etc.
What the basic question involved was whether providers have some sort of community in place to distribute to customers concerning their customer/internal routes. Also, it would be nice if the provider would distribute this information to the customer. Therefore, I was wondering which providers had such communities and which providers were willing to distribute said communities to customers.
Another question is, "Why do you want this info?" Taking full transit routes from a provider and trying to set localpref or MED based on whether the destination is a customer or peer network? If you are taking transit, there are good arguments for *not* running default-free.
It would seem to me to be helpful when coming up with policy to route traffic bound for internal/customer networks of an upstream to that upstream (unless that link is down). Sometimes the path selection does not allow this and we are forced to use foolish kludges like as path prepending and other neanderthalic clubbings. Bradley Reynolds brad@iagnet.net No Inflated Title Internet Access Group
On Sat, Nov 01, 1997 at 07:44:55PM -0600, Tim Salo wrote:
Date: Sat, 1 Nov 1997 17:37:57 -0500 From: "Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us> To: "You're welcome" <nanog@merit.edu> Subject: Re: NAT etc. (was: Spam Control Considered Harmful) [...] Well, yes, Paul, but unless I misunderstood you, that's exactly the point. If a client inside a NAT cloud does a DNS lookup to a supposedly authoritative server outside, and the NAT box is _required_ to strip off the signature (which it would, because it has to change the data), then it's not possibile, by definition, for any client inside such a NAT box to make any use of SecDNS.
The point is that you _can't_ regenerate the signature, usefully to the client, anyway, precisely because _it is a signature_.
Presumably, the NAT could,
o Verify the signature of the DNS responses it receives, and dump any responses that don't meet its [authentication] criteria, or
o Sign the the response it creates and let the client verify the NAT's signature. Presumably, the client will trust the NAT.
Yup, it could, but as I noted to Paul, in the cases Sean is advocating, the client and the NAT box may not be within the same span of administration, either. IE: no, you may _not_ trust the NAT op. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
Yup, it could, but as I noted to Paul, in the cases Sean is advocating, the client and the NAT box may not be within the same span of administration, either. IE: no, you may _not_ trust the NAT op.
In today's internet, the DNS management, the routing administration, and the ADM engineer are all outside of central administration. This is analagous to the case you bring up, and yet we work well. Proxy aggregation of address space occurs, and yet the world goes on. That the NAT administration would be different from that of the flow endpoints is orthagonal to the discussion. Perhaps you mean that the client won't know where to go because the information is changed. Well, yes, that's what NAT does. Send it to an agent aware of the change, or reference that modulation, and it will come together. -a
On Sun, Nov 02, 1997 at 12:31:45PM -0500, Alan Hannan wrote:
Yup, it could, but as I noted to Paul, in the cases Sean is advocating, the client and the NAT box may not be within the same span of administration, either. IE: no, you may _not_ trust the NAT op.
In today's internet, the DNS management, the routing administration, and the ADM engineer are all outside of central administration.
This is analagous to the case you bring up, and yet we work well.
Proxy aggregation of address space occurs, and yet the world goes on.
That the NAT administration would be different from that of the flow endpoints is orthagonal to the discussion.
No, I'm afraid I don't think that's true. This is a question of _trust_, and if I don't wish to allow the operator of a NAT box to proxy my trust in a nameserver operator, there really isn't any good way around that. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
Yup, it could, but as I noted to Paul, in the cases Sean is advocating, the client and the NAT box may not be within the same span of administration, either. IE: no, you may _not_ trust the NAT op.
And as I noted in my reply, the real opportunities for NAT are when one side of the NAT trusts the NAT and the other side considers it "just another public client".
participants (6)
-
Alan Hannan -
Bradley Reynolds -
Jay R. Ashworth -
Kirby Files -
Paul A Vixie -
Tim Salo