Hi Manav,
I think that the authentication trailer should follow the LLS and should
secure LLS as well as the other OSPF data. Even if an implementation
doesn't want to completely support LLS, I think it is reasonable to
require that in order to support the AT extension it can know how to
find the AT when there is an LLS block.
I would also like to see this draft include similar Session ID and Nonce
as defined in
draft-bhatia-karp-ospf-ip-layer-protection-01.txt although perhaps make
it an optional feature.
Thanks,
Michael
On 01/19/2011 04:05 AM, Bhatia, Manav (Manav) wrote:
Hi Acee,
I think the idea behind this logic was for the purposes of backward
compatibility. I agree that this is not right if *all* routers support
the AT capability. However, if you have even one router that does not
support this, then you would probably need this mechanism.How would an
implementation, that is AT incapable, send an OSPFv3 + LLS block to a
router, if the receiving end always implicitly assumes the presence of
an authentication trailer? One could argue that if the AT router has
turned ON authentication then it MUST only accept packets with the AT
block, but then we are taking a giant leap of faith where we're assuming
that ALL routers will simultaneously turn on the AT mechanism.
If folks think that this opens a security hole, then vendors could add a
knob that could toggle this behavior. By default, the knob could assume
the presence of an authentication trailer if auth has been turned on.
The second state would be where authentication trailer is assumed to be
present only if the AT bit is set.
If folks agree to this, then we could add a note about this in the next
revision.
Cheers, Manav
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
