Re: IPv6 header insertion in a controlled domain

[Gyan Mishra <[e-mail]>]

On Sun, Dec 8, 2019 at 5:03 PM <[e-mail]> wrote:

> Brian,
>
> >>>     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. ;-)
> >>
> >> Any other security issues you see?
> >
> > Two comments on this thread:
> >
> > 1) It isn't just AH that is broken; any form whatever of cryptographic
> authentication of the packet header or the packet as a whole between A and
> C is impossible unless the key is shared between A and B. But whether that
> matters or not is a domain-specific decision. If I'm outside the domain,
> why would I care?
>
> Right. I think Gyan's point was that header insertion made it harder to
> secure the tunnel between A and C.
> So mainly a problem for the controlled domain itself.
> ESP NULL would work fine probably, since it doesn't include payload length
> in the signature.
> And you can ensure whatever is inserted is also treated as mutable.
> Regardless, this is an inside the controlled domain problem, and one could
> probably define a suitable security scheme for it if required.
>
> > 2) For me the test that matters is not whether this all works, but
> whether the fact that it's happening can in principle be detected from
> outside the domain. If it can't be detected from outside, why would I care?
> >
> > Note that NAT fails test 2. I'm not convinced that SRH insertion inside
> a tunnel does so.
>
> I suppose header insertion has to pass both tests.
> It has to be transparent to the outside, and it has to be possible to
> secure within the domain.



   I think since this is within the operators domain that they have full
control of maintaining the trust boundaries and enforcement of what can be
seen outside the domain.

A good example of this enforcement in the MPLS world is that you don’t
allow any entity or customer outside the operator domain to trace through
the domain.  Real would scenario is using the “no mpls ttl-propagate” to
prevent traceroute through an operators mpls core.

My point is the onus is on the operator to enforce the boundary and allow
or not allow visibly into the operators network.  So 2 can be easily
accomplished but the onus is on the operator.

Ole had a valid point about AH that the probability of the nodes in the
domain having a common security stance is more probable then the operator
using AH within the domain.

>
>
> Cheers,
> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant