Re: [dhcwg] IESG Discusses/Comments on draft-ietf-dhc-dhcpv6-subid-00.txt

On Friday 20 January 2006 15:17, Bernie Volz (volz) wrote:
> There's also the assumption that a relay-agent, that will relay the
> message using IPsec, doesn't relay a relayed message except if received
> from an IPsec secured relay (since the relays down the chain and the
> server can't know which earlier hops were secured or not - except the
> last). A relay-agent only relay's a client message and an IPsec secured
> relay message? (There isn't anything that I found that explicitly states
> this in RFC 3315, so perhaps something to consider as we advance the
> document. Or do we feel that is naturally obvious.)

Generally speaking, if you state something clearly and explicitly in an RFC, 
there is a *chance* that all implementors will understand what you meant.   
If you don't state that thing in an RFC, there is a *chance* that a few 
implementors will understand what you meant or ask you.   So of the two 
options, I think being explicit is better.

> Isn't there inherently an assumption that a relay know whether it should
> only be a first hop relay and thus ONLY relay client traffic (and not
> relayed messages). 

No, there's no such assumption.

> This would be useful in both directions, since if so 
> configured, the relay would never want to relay a RELAY-REPLY either. (I
> guess servers could also be told the maximum hops expected and drop
> messages that have more than the maximum hops.)

That seems balky.   I like your first suggestion better.   In general I think 
it might be challenging to completely specify the behaviour you're suggesting 
here.

I hate to say it, given where we are in the process, but it might be better to 
require that a relay-forward option in a DHCPv6 packet that is itself being 
authenticated must always indicate whether or not the message being relayed 
was authenticated.  This would have to be done via a new option we haven't 
talked about yet.

I don't know if this is necessary, though - perhaps it's enough to simply 
explain the problem in the security considerations section and let the 
administrator impose a solution locally, which I think is basically what 
you're saying here.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg