Kathleen Moriarty has entered the following ballot position for draft-ietf-ipsecme-tcp-encaps-09: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for documenting this practice to improve interoperability. This practice has been in place for a while and I think this is a helpful document. I have a few comments. I think it would be good for the introduction to be more explicit on where the problem lies that has resulted in this common practice of tunneling this traffic through TCP. The following sentence could be modified: OLD: Many network middleboxes that filter traffic on public hotspots block all UDP traffic, including IKE and IPsec, but allow TCP connections through since they appear to be web traffic. NEW (or something along these lines): Many network edge middleboxes that filter traffic on public hotspots block all UDP traffic, including IKE and IPsec, but allow TCP connections through since they appear to be web traffic. I think it's important to note that this is happening at the edge in case that is not clear enough with the phrase "public hotspots". If it's more than the edge where this is happening, and I'm not right about this suggested change, please just say so. For section 11 - I think it's worth adding more text to hit on the concerns Warren raised in one of his comments. Here are some thoughts in case it is helpful: I agree with Warren that the result of operators not being able to identify this traffic should be mentioned, although this is tricky. The port discussion in other AD reviews and discouraging the use of 443 may change this to be identifiable traffic over TCP 4500 with the required stream prefix only for legitimate uses, or in reality, 443 if this stays undocumented because of existing implementations. Warren commented on operators not being able to detect this traffic is an important one, but I think it's fine to say the intent is to circumvent ACLs or firewall rules as opposed to avoiding detection. Then saying that avoiding detection is a result or unintended side effect. Side comment not intended for any new text: It would be good if operators observed the blocked ports (UDP 500) and figured out that they should open the port, but this has been a problem for some time and not all networks have dedicated operators (who want to fix this and similar issues) or ones with the time and skill sets to fix the problem. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
