[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.