Re: [Gen-art] GEN-Art review of draft-ietf-dhc-relay-id-suboption-07

Ted Lemon <Ted.Lemon@nominum.com> Wed, 07 October 2009 06:27 UTC

MIME-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <4ACB9A5F.4090300@ieca.com>
Date: Tue, 06 Oct 2009 23:28:42 -0700
Content-Transfer-Encoding: 7bit
Message-ID: <2D28B9BF-867C-4162-8A24-84C7CF56E781@nominum.com>
References: <4ACB9A5F.4090300@ieca.com>
To: Sean Turner <turners@ieca.com>
Cc: Review Team <gen-art@ietf.org>, draft-ietf-dhc-relay-id-suboption.all@tools.ietf.org, General
Subject: Re: [Gen-art] GEN-Art review of draft-ietf-dhc-relay-id-suboption-07
Precedence: list

On Oct 6, 2009, at 12:28 PM, Sean Turner wrote:
> Major #1 It's not clear to me whether both relay identifier types MUST
> be supported or whether implementations are free to pick which one(s)
> they support?  If you add one of the following (or something  
> similar) in
> Section 5 then my concern is addressed:
>
> Implementations MUST support both RELAY_IDENTIFIER_DUID and
> RELAY_IDENTIFIER_ASCII.
>
> Implementations MUST support RELAY_IDENTIFIER_DUID and [SHOULD or MAY]
> support RELAY_IDENTIFIER_ASCII.
>
> Implementations MUST support RELAY_IDENTIFIER_ASCII and [SHOULD or  
> MAY]
> support RELAY_IDENTIFIER_DUID.

Yeah, this seems like an interoperability problem just waiting to  
happen.   Personally I would like to see this go away and the draft  
_only_ use a DUID.   If the DUID types defined in 3115 aren't  
adequate, add a new type that does what you want for this application  
(and, please, is restricted to this application).

> Major #2  In the security considerations it says look to RFC 3046 and
> RFC 4030 for security considerations and then says SHOULD use the  
> relay
> agent authentication option from RFC 4030.  RFC 3046 is targeted at
> network infrastructures that are "trusted and secure" and RFC 4030
> allows the relay agent to be part of this trusted and secure network.
> If an implementation doesn't use the relay agent authentication  
> option,
> then the relay agent can't be part of the "trusted and secure"  
> network.
>  This makes me think that the relay agent authentication option from
> RFC 4030 ought to be a MUST not a SHOULD?

Yes, this text is confusing.   This document makes no changes to  
practice that require more or less security than is provided by  
existing relay agent options in RFC4036.   Thus, the security  
considerations in RFC3046 should be adequate.

If the security considerations from RFC3046 are not adequate, the  
document needs a section prior to the security considerations section  
that explains the use of RFC4030 in the context of this document - in  
what circumstances it is required, and in what circumstances it is not.

[Gen-art] GEN-Art review of draft-ietf-dhc-relay-… Sean Turner
Re: [Gen-art] GEN-Art review of draft-ietf-dhc-re… Ted Lemon