Re: SRH insertion vs SRH insertion + encapsulation

[Brian E Carpenter <[e-mail]>]

Ole,

On 08-Sep-19 15:02, Ole Troan wrote:
> Ron,
> 
>> IMHO, EH insertion modifies the semantics of the IPv6 source address. Today, the IPv6 source address indicates the source of an IP packet and **ALL** of its contents. If transit routers are allowed to insert extension headers, downstream routers can no longer identify the source of a packet and all of its contents.
>>
>>  
>>
>> Granted, in some cases, transit routers are allowed to modify a packet (e.g., Hop Count, DHCP, mutable options). But there is a big difference between changing a field whose value is know to me mutable and inserting a new option.
>>
> 
> 6296?
> 
> And I am pointing that out because of what feels like moral righteousness and hypocrisy to me, not because I think header insertion is a good idea or even doable. 

I think the real question here is whether we want it to be possible *in principle* to verify that a packet has not been modified in transit, except for fields that are known to be mutable. NPTv6 is indeed a case where we consciously made this worse. ("NPTv6 involves modifying IP headers in transit, so it is not compatible with security mechanisms, such as the IPsec Authentication Header, that provide integrity protection for the IP header.") Addresses are not mutable as far as AH is concerned.

If we are willing to say that a feature is useable only within a domain where AH is not used, that seems OK, but only if the concepts of a domain, its membership, and its boundary nodes, are well defined. (To be clear, I don't think draft-voyer-6man-extension-header-insertion-06 is anywhere near explaining how a domain is defined and managed.) Or the IETF decides to declare AH dead. In any case, it's wider than a 6man decision.

   Brian