Re: [Secdispatch] Comments on draft-xu-ipsecme-risav-00.txt

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 28 March 2023 00:52 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4ED9C13AE53 for <secdispatch@ietfa.amsl.com>; Mon, 27 Mar 2023 17:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-kmxD-u0Rnb for <secdispatch@ietfa.amsl.com>; Mon, 27 Mar 2023 17:52:11 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C453BC15155C for <secdispatch@ietf.org>; Mon, 27 Mar 2023 17:52:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B6BF6389A2; Mon, 27 Mar 2023 21:25:34 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id G6_q9xjoF2C6; Mon, 27 Mar 2023 21:25:34 -0400 (EDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 1199E3899F; Mon, 27 Mar 2023 21:25:34 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1679966734; bh=vfUHPIoCgdgNusu7/CB7MbZPmSUTbyevfKEzZ7lb0ao=; h=From:To:Subject:In-Reply-To:References:Date:From; b=heVaU3yNQeF4rCmDRmAIvD89IC/U+oF7/kVMq3zD0Hu4im0n5sn1cd5ccf4g7Z5rC FidiRUo7j0rs+6V2xuVkm5YzSjJA1U9dwuV4tfM4ht2B2ymHPIyuNviSkcs2aiTCFp aVjwxTIrWzFQ5CCbZ1YoM4DGn+NUWGdzLgcc0kgCPckNS96pTCZIELeItVL4au0QbX pC+ZjVwaR0bWMZpyM7ljyO8y+HRxCopU/j2Z/7JIpn+2ca8i9EEjHKbbhqhvvibh4T cszyPa4awU77I96r2pWxg9kCSFirvbMuTq2PdFiW4YHKzrxu5U4E2EL6q2/0yUOwgs x21lXJ4o7ppkw==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DA97218C5; Mon, 27 Mar 2023 20:52:09 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tero Kivinen <kivinen@iki.fi>, IETF SecDispatch <secdispatch@ietf.org>
In-Reply-To: <25633.41128.91087.566196@fireball.acr.fi>
References: <CABcZeBNp2bneLHU000E0jZ_kD9Q7wYG+jMH5FDCfzz3e7faipQ@mail.gmail.com> <31867.1679894307@localhost> <25633.41128.91087.566196@fireball.acr.fi>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 27 Mar 2023 20:52:09 -0400
Message-ID: <11936.1679964729@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/chIwFbZeVAsPIncRTMFa0b05LZg>
Subject: Re: [Secdispatch] Comments on draft-xu-ipsecme-risav-00.txt
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2023 00:52:16 -0000

Tero Kivinen <kivinen@iki.fi> wrote:
    > It would be cheaper to just make sure that each AS will not allow
    > spoofing source addresses in the first place. And unless this gets
    > deployed in lots of places there is no protection against DoS, as the
    > attacker will simply use those AS which do not yet support this.

In an ideal command and control world, this would be easy.
What I think we see from the Operators (go to some NOG meetings, RIPE,
NANOG..) and from the savnet WGs, is that there are multiple complex
challenges that is preventing this from happening.   They are often
non-technical and we engineers might regard this issues as stupid.

    > The draft says that Inter-AS SAV requres different ASes to collaborate
    > and that makes it hard, and most likely that is the reason they are not
    > widely deployed.

    > This thing also requires coordination between ASes and what makes
    > authors to think this effort will be easier to deploy than those
    > earlier methods?

Because the inter-AS SAV requires dis-interested ASes to collaborate to help
the two ASs involved.  While this solution, while more expensive, involves
only the ASs that care.

    > Also I doubt the ICMP packet too big processing is going to work that
    > well, as there might not be enough data in the ICMP packet after they
    > remove the AH header so that the contained packet in ICMP looks like
    > whatever the original node sent out.

They will totally have to accomodate bigger than 1500 byte packets, and I
also have raised that issue.  I find the authors very inexperienced on this
topic and they have dismissed it out of hand.

    > On the other hand if they simply use ESP in tunnel mode then they can
    > use standard solutions for those issues, i.e., normal site to site VPN
    > products already solve those issues.

At the cost of significant impacts to often needed traffic analysis that is
used for load balancing/traffic engineer, and DoS impact.
(DDoS are still possible: but now you know who is doing it)
There are still jurisdictions where encryption is a problem, and I'd prefer
to know when they are being spoofed (or not), so we can blame the right parties.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide