Seems as if the reply to this sub-thread was overlooked, sorry.
In the ACP, a node has multiple IPsec connection, each of which acts like a
virtual link to another node and each of them will carry IPv6 packets
with arbitrary IPv6 source and destination adresses.
So the ideal, most compact option is:
Tunnel Mode. ESP payload (Next Header) is IPv6 (41)
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
This is not IPinIP. IPinIP would be if the IPv6 packet inside the ESP
encapsulation itself would have a next header field of 41 and and we
would have another IPv6 packet there.
I guess we could set the IP protocol selector to 41, but browsing through
RFCs, i can not find a single example where this is done, instead all
TSi examples use 0.
Transport Mode: Payload = ESP Next Header is GRE (47)
TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-ACP-LL-addr)
TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL-addr)
These two choices are somewhat arbitrary, i am sure some vendor
not following this draft will later come and complain that he
prefers GRE in tunnel mode or IPinIP tunnel or transport mode,
but those profiles can always easily be added through later RFCs
if there is sufficient support by updating the ACP RFC and would
work proprietarily between vendor devices anyhow even today. For now i think
it is most interesting for ACP to have what is the most compact header
(tunnel mode) and one alternative showing use of ttransport mode
and hopefully useful to vendors with legacy gear that most often
has GRE tunnel interfaces but not explicit IPsec interfaces.
Here is the current tentative text, please yell if NOK:
-- native:
<t> An ACP node that is supporting native IPsec MUST use IPsec in tunnel mode,
negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next Header of 41). It
MUST use local and peer link-local IPv6 addresses for encapsulation. Manual
keying MUST NOT be used, see <xref target="domcert"/>. Traffic Selectors
are:</t>
<t>TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)</t>
<t>TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)</t>
<t>IPsec tunnel mode is required because the ACP will route/forward packets
received from any other ACP node across the ACP secure channels, and not only
its own generated ACP packets. With IPsec transport mode (and no additional
encapsulation header in the ESP payload), it would only be possible to send
packets originated by the ACP node itself because the IPv6 address of the ESP
must be the same as of the outer IPv6 header.</t>
-- GRE:
<t>The requirements for ESP/IPsec/IKEv2 with GRE are the same as for native
IPsec (see <xref target="IPsec"/>) except that IPsec transport mode and next
protocol GRE (47) are to be negotiated. Tunnel mode is not required because of
GRE. Traffic Selectors are:</t>
TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-ACP-LL-addr)
TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL-addr)
<t>If IKEv2 initiator and responder support IPsec over GRE, it has to be
preferred over native IPsec. The ACP IPv6 traffic has to be carried across GRE
according to <xref target="RFC7676"/>.</t>
--
Cheers
Toerless
On Thu, Feb 27, 2020 at 12:41:55AM +0200, Yoav Nir wrote:
>
>
> > On 26 Feb 2020, at 19:56, Michael Richardson <mcr+i...@sandelman.ca> wrote:
> >
> >
> > Yoav Nir <ynir.i...@gmail.com> wrote:
> >> The draft says ???IPsec tunnel mode is required ???, so it???s not
> >> transport. What goes in the TS payloads?
> >
> > TSi=HostA-LL/128, TSr=HostB-LL/128, Protocol = GRE(47) or IPIP(41)
>
> If that???s the intention, I don???t see why this should be tunnel mode. Both
> GRE and IPIP are tunnels, and they do not require ESP tunnel mode to add yet
> another IP header.
>
> Yoav
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
