Re: IPv6 header insertion in a controlled domain

[[e-mail]]

Gyan,

> > > I think the in flight eh insertion done on the node doing the encapsulation node A  is safer from a security perspective then an intermediate node adding a eh header without encapsulation.  I think even though you add an encapsulation but if the node doing the encapsulation is not the one adding the eh header it’s no different in my opinion then the node A not doing an encapsulation at all which was proposed initially by Spring.  
> > > 
> > > So we have to enforce that the EH insertion is only done by the node performing the encapsulation.
> > 
> > With regards to your comment that node B doing insertion on a packet with SA=A and DA=C, is equivalent to doing insertion on the original packet without encapsulation, I think the risks of that is defined in Mark's draft/8200.
> > 
> > Let me dig down on the security issue a bit.
> > Still given the simple example I gave earlier.
> > Can you ellaborate on what security issue you see, and why doing insertion at B is less secure than at A?
> > 
> >      I was thinking the obvious man in middle attack tampering with v6 header by intermediate node and possible impact to AH if used.
> 
> If AH is used, wouldn't A add the signature, and C when validating would know that B added the header and could do verification accordingly?
> For a controlled domain where all of A,B and C are acting in cohort, then that wouldn't be too far fetched to assume.
> At least a lot more probable than that AH would be used at all. ;-)
> 
>     With AH the hash signature has to match between source and destination so in this case with eh insertion it would not

Right, but C could in theory restore the packet before checking the signature.
In a similar way to what is already required by using a routing header.

A more likely outcome is to declare that AH isn't supported in this case.

Best regards,
Ole