Re: [IPsec] Fwd: New Version Notification for draft-xu-risav-02.txt

[Michael Richardson <[e-mail]>]

Ben Schwartz <bemasc=[e-mail]> wrote:
    > We've just put out an extensively revised version of our RISAV proposal
    > (the I stands for IPsec).  We'd like to start getting feedback from the
    > IPsec experts.  We're also hoping to present this idea and solicit
    > feedback at IETF 115.

Thanks.
The question of what kind of tunnel or transport is a deep one, and whether
or not to encapsulate the traffic within an IP header has significant
architecture discussion.  Despite the experience of SR6 pushing through, I'm
not convinced that 6man will buy your use case.  There are some interesting
opportunities for privacy and defeating traffic analysis by adding an IP
header.  The IPTFS work (now in the RFC-editors Q
https://www.rfc-editor.org/current_queue.php#draft-ietf-ipsecme-iptfs )
also offers some interesting opportunities.

    > This is an early stage proposal with a lot of open questions (many of
    > which are noted in the draft), but the core idea is simple: use RPKI to
    > bootstrap an authenticated IPsec association between the source and
    > destination ASes of Internet traffic, so that inauthentic packets can
    > be discarded before they reach their destination.

But, what about: https://www.rfc-editor.org/rfc/rfc9255.html
It seems like you are trying to use RPKI for something which the RPKI people
don't want you do to.  (I mostly disagree, btw)
I see from the content in section 2.2 that you have an EE cert for the ACS.
I'm a bit unclear about whether step 1 is already the RPKI, or some new
process.

It seems that one would want many ACS systems. If successful, all of the
traffic between AS A and B would go through, and that could easily exceed the
bandwidth of a single system (or a single cluster).  Since AS A/B may
interconnect in many places, on many continents, they need many tunnels.
I think that this invokes the entire MED debate in BGP4, which I'm really
out-to-date on, but AFAIK, isn't solved.  Maybe adding IKEv2 provides
opportunities to make better policy decisions.

There are shades of RFC4322 in these ideas, but not the same.

Also, if universally successful, does this suddenly change how the DFZ looks?
Does it have to carry all of the routes to all of the places, or only the
routes to the ACS/ASBR?
Can you drop all IPv4 and just encapsulate to IPv6?
Is there a win in simplifying silicon here?

}4.1.  Transport Mode
}
}   To avoid conflict with other uses of IPsec, RISAV defines its own
}   variant of the IPsec Authentication Header (AH).  The RISAV-AH header
}   format is shown in Figure 2.

This is really dumb. Don't do this.
There are only conflicts because you think you are insert the header.
You can't and you shouldn't.  You really should create a tunnel with AH.
AH has the advantage that everyone knows it's AH, so skipping the outer
header and the AH means you can find the inner IP and do auditing or flow
analysis on it.  Since you have to modify hardware to do something, you might
as well do this.

}7.3.  MTU
}
}      TODO: Figure out what to say about MTU, PMTUD, etc.  Perhaps an
}      MTU probe is required after setup?  Or on an ongoing basis?

The answer is probably to do IPTFS, but that is in conflict with using AH.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-