Re: [Secdispatch] [IPsec] RISAV proposal at SECDISPATCH

[Benjamin Schwartz <[e-mail]>]

On Tue, Mar 14, 2023 at 11:39 AM Michael Richardson <[e-mail]>
wrote:

>
> TL;DR> Important work needing New WG in Routing Area.
>
> Hi, I thought I had read previous versions of RISAV... maybe under a
> different draft name.


Yes, it was previously draft-xu-risav.  (The replacement is marked in the
Datatracker.)


>   I find this version much better than I saw before.
>

Thanks!  We did try to incorporate your feedback.

...

> The concerns that I have about this document is that the IPsec/AH parts of
> it
> are rather simple.  The IPv6 header insertion and MTU parts of this
> document
> are, I think very controversial given the SR6 experience: SR6 was said to
> be
> always within an AS, and that any leaks would be a bug.  But, the ENTIRE
> point of RISAV is to communicate between ASs.
>

Yes, that's definitely a concern in Transport Mode.  (See this thread in
6man:
https://mailarchive.ietf.org/arch/msg/ipv6/78Frr7aQR0sT7yKKkFXucv2tL-8/).
Note that Tunnel Mode does not have this problem.

I also think that there is a lot of BGP-like TE that is missing from this
> proposal.   Although I run a BGP AS with multiple uplinks, I don't know all
> the latest stuff about MED and how to deal with situations where two ISPs
> connect in multiple places.
>

Section 6.2 incidentally describes how one might do quite a bit of traffic
engineering using existing IKEv2 options.  We'll need more input to know if
it's sufficient.

In Transport Mode, the thought is mainly to _avoid_ traffic engineering,
and instead be able to deploy RISAV with confidence that your existing TE
will not be altered.

The other concern that I have with RISAV is that it seems unreasonable that
> an AS have only a single ACS.  Maybe this can be accomplished via an
> anycast
> situation,


Yes, personally I imagine implementing the ACS as an anycast service.


> which to me implies some kind of MOBIKE-like situation where the
> anycast IKEv2 respond answers with it's topologically useful IP.
>

Section 9.2 suggests using IKEv2 Redirect (RFC 5685).  Please let us know
if you see a better way.


> I can imagine a situation where the ACS together, pick an appropriate pair
> of
> ASBRs to form a tunnel between them.
>
> Should a global ISP should be hairpinning traffic across the Pacific when
> it
> secures traffic between two AsiaPacific entities?
>

Obviously not, and RISAV intends to avoid that.

While this could be dispatched to IPSECME, I don't think that is the right
> choice.  I think that we might need a new WG in the routing area with a
> SecAD
> owning it.
>

I like the idea of a new WG, especially since IPSECME seems quite busy.
However, I do think the various multi-SA/multi-sender drafts in IPSECME
(esp. [1][2]) should be in the same WG as RISAV, as it depends heavily on
that capability.

--Ben Schwartz

[1]
https://datatracker.ietf.org/doc/html/draft-mrossberg-ipsecme-multiple-sequence-counters-00
[2]
https://datatracker.ietf.org/doc/html/draft-ponchon-ipsecme-anti-replay-subspaces-00