Hi, I have read draft-moskowitz-ipsecme-rfc7402-beet-update-03. I found the document clearly written, and a welcome update to RFC7402, and the document should be adopted.
I would reword section 3.2: OLD: The wire packet format is identical to the ESP transport mode wire format as defined in Section 3.1.1 of [RFC4303]. However, the resulting packet contains outer IP addresses instead of the inner IP addresses received from the upper layer. The construction of the outer headers is defined in Section 5.1.2 of [RFC4301]. The following diagram illustrates ESP BEET mode positioning for typical IPv4 and IPv6 packets. NEW: The apparent wire packet format (ignoring the encryption) of the contents of the packet identical to the ESP transport mode wire format as defined in Section 3.1.1 of [RFC4303]. However, the contents describe an inner packet whose constant IP addresses are described in the Security Association. The construction of the outer headers is defined in Section 5.1.2 of [RFC4301]. BEET mode is functionally equivalent to a tunnel mode SA with those two src/128 and dest/128 addresses (src/32 and dst/32 for IPv4) as the only selectors. The following diagram illustrates ESP BEET mode positioning for typical IPv4 and IPv6 packets. While the way that 3.5 describes the outgoing processing, point 1, is correct, I think it's also hard to reconcile with the processing model of RFC4301. Step 1 would never happen in 4301 processing model, because the inner source/destination would be looked up in the PAD to find an SPD, and that SPD would be an SA in BEET mode. The aside about addresses being implied occurs only, I think, when the SA is attached to a ULP socket. I think the text buries the lead, which is quite simple, and it would be better to just have a section about BEET mode use with other ULPs. I think the paragraph "Instead of literally..." in each section is not helpful. I think most (non-vibe) coders will figure out that deleting 40 bytes and then inserting 40 bytes will figure out that one can just overwrite. It's 2026, so please describe BEET for IPv6 first, and then write exceptions for IPv4. So the IPv4 option handling section shoud do all the work. I'm unclear how to handle IPv6 Hop-by-Hop options, or IPv6 Extension Headers which are not ULP. I question the complexity of handling any IPv4 options. 3.6 point 3 asks about UDP encapsulation of ESP. Conceptually, I think it best to think of the UDP encap/decap as being a separate stage, and I think it's therefore up to the UDP decap, which still has the original outer header and UDP header, to be the thing that observes changes in NAPT44 mappings, and sends appropriate update messages. It seems that this use of 94 (ipip) is a bit of an abuse of that NH :-( (I don't recall this part at all. But, I never implemented BEET) I would rather that IPv4-in-IPv6 and IPv6-in-IPv4 sections 3.8.2/3.8.3/3.8.4 were not buried under fragment handling. In particular, this is the first (only?) place where it is mentioned how v6 Extension Headers are to be processed. MORE THOUGHTS: 1. If I were doing this work from scratch, I would have made BEET "mode" a highly "efficient" compression mechanism of the IP header for tunnel mode. Then, one would be able to just "not compress" if there are things like IPv4 fragments. 2. Back in the day, one interesting reason to use BEET mode was that is suppressed the inner IP addresses. That is, they are not revealed to the other party, so they can never confuse. In particular, there is no reason why the two parties need to have the same addresses on each end. This enables 1:1 NAT, potentially, NAPT if the port numbers are managed well. This goes back to the two sites with the same 10.x.y.z need a VPN, and each end can number the other end into some unique "other" prefix, potentially with SA per 3-tuple flow using populate from packet. 3. Perhaps we now need to say something about how/if BEET mode can be used with IP-TFS. IP-TFS brings us better handling of too-big packets. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ** My working hours and your working hours may be different. ** ** Please do not feel obligated to reply outside your normal working hours **
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
