Hi again,
Thanks for continuing to engage in this discussion.
This email is me getting out of the way of further progress of this draft.
Cheers,
Adrian
[snip]
[Linda2] Let me try again. How about the following write-up?
"To ensure security, enterprise traffic between their CPEs is encrypted and
remains inaccessible to any third parties, including the Cloud DC. For the
encrypted packets to be steered through the Cloud Backbone, the packet
header must contain information indicating the packet's intended route.
Given that the IPsec SA between CPEs is exclusively maintained between the
CPEs and is not accessible to Cloud GWs, the encrypted packet needs to be
carried by a tunnel between the source CPE and the ingress Cloud GW. This
tunnel can be another layer of IPsec, which adds processing overhead to the
Cloud GW to decrypt the outer IPsec tunnel solely for steering the encrypted
payload.
By steering the encrypted traffic through the Cloud Backbone without the
need for decryption and re-encryption at Cloud GWs, processing demands at
these GWs can be significantly reduced. This streamlined approach not only
maintains the integrity of the encrypted traffic but also optimizes
processing resources, enhancing overall efficiency within the cloud
infrastructure.
This document introduces a method for SD-WAN CPEs that utilizes GENEVE
Encapsulation [RFC8926] to encapsulate IPsec encrypted packets, directing
them to the nearest Cloud GWs. These gateways can determine whether the
packet needs to traverse the backbone without decryption by inspecting
Sub-TLVs within the GENEVE header, as specified in Section 4. Once
determined that the packet is intended for backbone traversal, the IPsec
encrypted payload is steered through the Cloud Backbone without decryption
to optimal egress Cloud GWs. These gateways then forward the original IPsec
encrypted payload to the destination CPEs. This method facilitates the Cloud
Backbone's connecting multiple SD-WAN segments without Cloud GWs decrypting
and re-encrypting payloads.
GENEVE is selected in this document as the encapsulation protocol due to its
widespread usage in Cloud DC sites."
[AF3] OK. It is clear in this text what you think you are doing and why. I
cannot say that I agree with your motivation, but it is clear. I don't have
(or intend to have) an implementation, so I should not stand in the way of
this.
[snip]
[AF2] Which takes us back to asking what the Geneve encapsulation an the
sub-TLVs buy us as the original IP header is now visible. Perhaps the
question is whether the IPsec SA is CPE-CPE or end-to-end. I don't think
that has been made clear. If the SA is between CPEs, the SD-WAN end-point
sub-TLV seems to only reproduce what is in the encapsulated IP header dst
field, and the SD-WAN tunnel originator Sub-TLV seems to reproduce the
encapsulated IP header src field. So, perhaps you are trying to build an
overlay which:
* Has very little to do with whether or not the payload is encrypted
* Is all about indicating the entry, exit, and transit GWs in the
overlay network
[AF2] Overlays and tunnels are great (q.v.) and I am just trying to
understand what it is you are trying to do with this work.
[Linda2] with the above changed write-up, is it more clear?
[AF3] Well, as I say, it is clear, but I don't agree. But that is no reason
for me to stand in the way.
[snip]
[Linda] add the following:
C-bit needs to be set, so that receiving node can drop the packet if it does
not recognize the option [RFC8926].
[AF2] OK. This has not shown up in -06, so presumably still in your edit
buffer. I don't know whether you are supposed to write "Type 1 with the
C-bit set" or "Type 129"
[AF2] Note that 8926 calls it the 'C' bit and the high-order bit.
[AF2] You haven't answered the point about the new registry
[Linda2] Yes, need IANA registry. Reflected in -7
[AF3] OK. I see the registry. I think you still have work to do on it
related to the 'C' bit. You don't have to do that now, but you will need to
do it.
You seem to have crashed the use of "TBD1" etc which were for Transit node
ID types (section 4.5) but you have reused those flags in section 11 for the
Multi-seg-SDWAN_subTypes
And you'll have to give IANA a clue about selecting from the range 128-255
to make sure the C-bit is set.
Note that in the body text you have two cases of subType3
---
4.6 and 4.7
Obviously, you are going to have to specify these TLVs in a future
version. For the include case, you are going to have to say whether this
is an ordered list, whether the inclusion is mandatory, and whether the
list is strict or loose. You may also have to worry about the option
length in the GENEVE header especially in the case of IPv6.
[Linda] Yes. Will add. Just at this moment, Azure is not sure what
information they are willing to provide .
[AF] Apologies, I thought this was an IETF spec. If this document is
describing a proprietary protocol, then the document needs a lot of work!
[Linda] I meant to say that they may not want internal IP address exposed.
Node ID or Region ID are all okay.
Add the TLV
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Include-Transit| length |Transit_Type |I|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transit node ID |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 Include-Transit Sub-TLV
Multiple Include-Transit Sub-TLVs can be included in one GENEVE header to
represent multiple nodes or regions to be included when the packet is
steered through the Cloud Backbone.
Transit_type:
TBD1: when Transit node ID is represented as a numeric number, such as a
Cloud Availability Region or Zone numeric identifier.
TBD2: when Transit node ID is represented as string, such as a Cloud
Availability Region or Zone name.
TBD3: when Transit node ID is represented as an IP address.
I-bit:
When set to 0: it indicates it needs best effort to steer through the
transit node ID.
When set to 1, it indicates that the Transit Node ID must be included
through the Cloud Backbone. If the Transit Node ID cannot be traversed, an
alert or alarm must be generated to the enterprise via an out-of-band
channel. It is out of the scope of this document to specify those alerts or
alarms.
[AF2] That is making progress. Thanks. I think you are still missing:
* Is this an ordered list or just a set?
[Linda2] No
[AF3] <snigger> "Is it an apple or an orange," he asked. "No," she replied.
[AF2]
* How is the string encoded?
[Linda2] strictly between the enterprise <-> Cloud Provider.
[AF3] So, is it a byte string or a character string? Is it printable? Is
internationalization supported? How does an implementation at the enterprise
manage to interwork with an implementation at the cloud provider?
[snip]
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
