[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IPSECKEY] Security Considerations (pass 2)
-----BEGIN PGP SIGNED MESSAGE-----
Rob> Content looks good.
Rob> Nits (many of which are really just a single tense agreement problem
Rob> that appears in many places throughout the text), plus one point
Thanks for all of this. I certainly can fix it myself, but never on the
same day as writing the original.
>> A protocol which permits the gateway field to delegate to a different
>> host MAY want to restrict this feature when end-to-end integrity is
>> not available.
Rob> Er, from what is the gateway field different? The RR owner name? How
Rob> should this test be applied when:
Rob> a) the RR owner name is an encoded address (reverse tree) and the
Rob> gateway field is a DNS name, or
Rob> b) the RR owner name is a "normal" DNS name and the gateway field is
Rob> one of the address forms?
Rob> Bit of a slippery slope.
Without integrity protection, one *might* want to permit only the situation
where "No gateway is present", or IP an IP address is present that it is ==
to the thing that one looked up originally. The first example is shows a node
that has delegate to self.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPsufHoqHRg3pndX9AQGDVQQAmFjdBx872p/QPXIXb6vO13TFFzWm9bQP
CeoypPRnQTF6RwJ1706/eqXPskjdDQWdevHxyTDsdpzDCVLffwe40prx3Rvx7dDc
102DIu0/2ibgtRULwSTsOKZmEJxb8qzEVFKEqofDDas04/5rwRBunsVztj+8p+51
vopcb/Ii6Ds=
=CRbq
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.