Re: [OPSEC] review draft-gont-opsec-icmp-ingress-filtering-02

Hi,

I had not read this document before, but I’ll piggy back two quick additional comments:

1. Since this doc seems to (mostly) use IPv4 examples, it should likely cover IPV4 NAT implications (i.e., modifying the IP header but not the embedded header, or masking an attack because lack of check).

2. Since RFC 4884, PS, updates both 792, 4443, it seems important to also cover the multi-part (e.g., Figure 2)

Thanks!

— Carlos.

> On Jul 15, 2016, at 12:53 AM, joel jaeggli <joelja@bogus.com> wrote:
> 
> Greetings,
> 
> I reviewed this probably later then I should have after volunteering to
> do so.
> 
> The mechanism proposed in
> 
> draft-gont-opsec-icmp-ingress-filtering
> 
> is akin to a strict mode RPF check for the IP Destination header
> contained in an ICMP error message though in practical terms a device
> such as a firewall without recourse to a routing table would probably
> employ an access list for enforcement.
> 
> While similar to other antispoofing measures one can employ to prevent
> spoofed traffic with internal source addresses from ingressing a network
> it may be technically infeasible to implement in the same mediation
> devices e.g. routers or switches, a problem we also noted with icmp6
> payload inspection in RFC 7690 section 4.
> 
> I'm sympathic generally to this draft, section 5 implementation details
> could be rewriten more cleanly to suggest how it is implemented. e.g.
> 
>   IF    embedded packet's Destination Address is from within my network
>   THEN  forward as appropriate
> 
> The destination match is due to a learned route (which assumes some
> minimal level of path or routing symmetry  which firewalls tend to
> require anyway); or an access list.
> 
> Thanks
> joel
> 
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] review draft-gont-opsec-icmp-ingress-filtering-02

Attachment: signature.asc