[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Karen Seo: Thomas Narten -- clarification, etc.]
>>>>> "Thomas" == Thomas Narten <narten@raleigh.ibm.com> writes:
Thomas> If the sender "recognizes" the option, but the receiver
Thomas> does not, presumably there is no issue. The receiver will
Thomas> not know what to do with the header and toss the
Thomas> packet. It doesn't really make sense for a receiver to
Maybe. Or, maybe some headers are designed to be passed to some (unknown to
IPsec) upper layer.
Second, you have to do AH checking first. If not, then the bad guy
just changes headers to bad values, and the receiver discards them. If
the header was covered by AH, then it should really cause an
authentication fail, (which should mean to some user that something
bad is happening) rather than an "invalid option" header.
Thomas> skip/ignore an extension header it does not
Thomas> understand. This check will take place before IPSec
Thomas> processing takes place.
Third, I'm not even sure that this is true. I think that a robust
implementation will need to liberal in what it accepts.
Thomas> If the sender doesn't "recognize" the option, but the
Thomas> receiver does, here is where the issue comes up. The
If the sender doesn't recognize the option, why would it put the
option in?
] Network Security Consulting and Contract Programming | SSH IPsec [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
References: