Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02
Tero Kivinen <kivinen@iki.fi> Thu, 23 March 2017 09:14 UTC
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8061314CC for <ipsec@ietfa.amsl.com>; Thu, 23 Mar 2017 02:14:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gETdNzwBMhpv for <ipsec@ietfa.amsl.com>; Thu, 23 Mar 2017 02:14:46 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540E61314CF for <ipsec@ietf.org>; Thu, 23 Mar 2017 02:14:39 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v2N9EYlk022597 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Mar 2017 11:14:34 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2N9EYvl023727; Thu, 23 Mar 2017 11:14:34 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22739.37370.402945.800855@fireball.acr.fi>
Date: Thu, 23 Mar 2017 11:14:34 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Wouters <paul@nohats.ca>
Cc: ipsec@ietf.org
In-Reply-To: <alpine.LRH.2.20.999.1703130903040.20456@bofh.nohats.ca>
References: <22644.61072.705632.343770@fireball.acr.fi> <alpine.LRH.2.20.999.1703130903040.20456@bofh.nohats.ca>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 4 min
X-Total-Time: 4 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/cJyT3MsWg09izBrqvUsWvKUAoR4>
Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 09:14:48 -0000
Paul Wouters writes: > > When an IPsec connection is terminated, the DNS forwarding must be > > unconfigured. The DNS forwarding itself MUST be be deleted. All > > cached data of the INTERNAL_DNS_DOMAIN provided DNS domainis MUST be > > flushed. This includes negative cache entries. Obtained DNSSEC > > trust anchors MUST be removed from the list of trust anchors. The > > > > This might cause security issues. I.e., if you have mail.example.com > > resolved using internal dns server to have IP-address of 10.0.0.1, and > > then someone manages to tear down the VPN connection, and suddenly all > > these mappings go away, the next time your mail client tries to fetch > > email, it does mail.example.com lookup using external DNS servers, and > > will get IP-address of 1.1.1.1 from ns.evil.org, then then it will > > connect to wrong mail server... > > If you are afraid of this attack, deploy DNSSEC on your domain. I most likely would have configfured my internal domain with DNSSEC, bu tthe DNSSEC trust anchors got deleted when tunnel went down, and when it revers to external DNS that might or might not be signed depending whether the top level domain or service provider you are using supports DNSSEC. > > Perhaps we should keep the mappings for some time, just in case the > > connection comes back few seconds later when the vpn reconnects... > > I switch regularly from redhat.com to public, and that would really > cause me problems. It is really important to wipe all the now > unreachable cached DNS data. > > If you wish to stall for a few seconds, I'd recommend you would be > dropping the DNS packets instead of lingering old state, and I would > say that is a pure local implementation issue and shouldn't go into > the RFC. But the MUST delete DNS forwarding etc will not allow me to do that. -- kivinen@iki.fi
- [IPsec] Review of draft-pauly-ipsecme-split-dns-02 Tero Kivinen
- Re: [IPsec] Review of draft-pauly-ipsecme-split-d… Valery Smyslov
- Re: [IPsec] Review of draft-pauly-ipsecme-split-d… Tero Kivinen
- Re: [IPsec] Review of draft-pauly-ipsecme-split-d… Valery Smyslov
- Re: [IPsec] Review of draft-pauly-ipsecme-split-d… Tero Kivinen
- Re: [IPsec] Review of draft-pauly-ipsecme-split-d… Paul Wouters
- Re: [IPsec] Review of draft-pauly-ipsecme-split-d… Tero Kivinen
- Re: [IPsec] Review of draft-pauly-ipsecme-split-d… Paul Wouters
- Re: [IPsec] Review of draft-pauly-ipsecme-split-d… Paul Wouters
- Re: [IPsec] Review of draft-pauly-ipsecme-split-d… Hu, Jun (Nokia - US)
- Re: [IPsec] Review of draft-pauly-ipsecme-split-d… Paul Wouters
- Re: [IPsec] Review of draft-pauly-ipsecme-split-d… Hu, Jun (Nokia - US)
- Re: [IPsec] Review of draft-pauly-ipsecme-split-d… Tero Kivinen
- Re: [IPsec] Review of draft-pauly-ipsecme-split-d… Paul Wouters