Subject: [secdir] secdir review of draft-ietf-ospf-dynamic-hostname

From: Samuel Weiler <[email-masked]>
Date: Thu, 2 Jul 2009 01:13:23 -0400 (EDT)

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG. These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The dynamic hostname TLV is an optional in-band mechanism to provide 
human-friendly symbolic names that map to router IDs.

The security considerations section 1) encourages the use of OSPF 
authentication and 2) calls out the grand fun possible if a 
misconfigured or compromised router sends bad mappings.  While that's 
probably less fun than could be had from just sending bad routing 
data, it adds an extra level of complexity to the debugging when these 
new symbolic names, as shown in config and debugging tools, don't 
match the expected router IDs.  But I'm not sure anything more really 
needs to be said here.

Resource exhaustion, as raised by Robert Sparks, looks to be a 
possibility, but I could go either way on whether it's worth adding 
words about it specifically -- do we need to call out the potential 
for resource exhaustion for every field in every protocol?

I'd let the doc go as-is.

-- Sam

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 2 Jul 2009 22:26:17 -0400

Many Thanks for your review, Sam.

--
Thumb typed by Carlos Pignataro.

On Jul 2, 2009, at 1:14 AM, "Samuel Weiler" <[email-masked]>  
wrote:

> security area directors.  Document editors and WG chairs should  
> treat these comments just like any other last call comments.
>
>
> misconfigured or compromised router sends bad mappings.  While  
> that's probably less fun than could be had from just sending bad  
> routing data, it adds an extra level of complexity to the debugging  
> when these new symbolic names, as shown in config and debugging  
> tools, don't match the expected router IDs.  But I'm not sure  
> anything more really needs to be said here.
>