On 23-Jan-21 20:36, Fernando Gont wrote: > Hi, Joe, > > On 21/1/21 14:17, Joseph Touch wrote: >> >> >>> On Jan 20, 2021, at 3:27 PM, Fernando Gont <fgont@xxxxxxxxxxxxxxx> >>> wrote: >>> >>> On 20/1/21 17:25, Joe Touch wrote: >>>>> On Jan 20, 2021, at 12:07 PM, Phillip Hallam-Baker >>>>> <phill@xxxxxxxxxxxxxxx> wrote: >>>>> >>>>> 0) Nowhere does the 'end to end' principle demand that the >>>>> source and destination addresses on an IP packet remain >>>>> constant >>>> IP addresses is the only means for identifying an Internet >>>> endpoint per RFC 1122. While I agree that there may be utility of >>>> having proxied endpoints (e.g. NATs) with effectively internal >>>> addresses behind them, it doesn’t help the case to begin with >>>> this inaccurate assertion. >>> >>> I'd have agreed with you. BUt since >>> draft-ietf-spring-srv6-network-programming has been approved by the >>> IESG, you probably cannot make such assertion anymore. >> >> One draft that doesn’t update or obsolete numerous others does not >> undermine 40 yrs of E2E. >> >> Esp. when (AFAICT) that doc series never mentions how transport >> protocols are supposed to deal with indeterminate endpoint addresses >> in their pseudo headers or the impact to security protocols at the >> transport (not transport content) layer. > > One *internet-draft* certainly doesn't undermine E2E. However, I guess > that an *RFC* published as a "Proposed Standard" probably does > (undermine) E2E? -- (draft-ietf-spring-srv6-network-programming has been > approved by the IESG). > > At the end of the day, I guess we cannot publish a PS that clearly > breaks E2E, while at the same time claim or pretend that we keep/have > E2E.... Much as I had concerns about draft-ietf-spring-srv6-network-programming, I think we should be clear about what e2e is about. It *isn't* about idealised transparency or even about forbidding packet mangling. For example, what we said in RFC1958 is: "The basic argument is that, as a first principle, certain required end- to-end functions can only be performed correctly by the end-systems themselves." That wasn't the last word, of course: see RFC3724, for example. Of course, that version of e2e does mean that any kind of packet mangling needs to be checked to see if it harms the e2e principle. For example, the e2e principle tells us that the decision to retransmit a damaged or lost packet needs to be taken at the originating host (which is why performance enhancing proxies are obnoxious). And it tells us that decryption keys must only be available at the final destination. But IMHO it *doesn't* tell us that a routing header must not be deleted by the penultimate hop, because it's of no value to the final destination anyway. (Logically, it's also a no-op, because the final destination ignores routing headers. Go figure.) Birian > (Full-disclosure: I was on the side of keeping E2E > (https://www6.ietf.org/iesg/appeal/gont-2020-04-22.txt)) > > Thanks, >
