Subject: [magma] MRD discussion follow up

From: Jim Martin <[email-masked]>
Date: Mon, 1 Mar 2004 23:27:27 -0800

All,
	As a result of the presentation of  draft-ietf-magma-mrdisc-00.txt in 
the MAGMA meeting today, there seemed to be two major issues. The first 
was the removal of the option capability, the second, our "enhanced" 
security section.
	The concern over options focused on extensions to support MSNIP 
capabilities distribution and additional security data for 
authentication. A poll of the room indicated that there was (limited) 
support to re-introduce options to the protocol. The solutions proposed 
included:

1) Revert to the TLV option format from the previous rev of the spec, 
putting the Querier Interval and Robustness back into options.
2) Revert to the TLV option format from the previous rev of the spec, 
leaving the Querier Interval and Robustness values as fixed fields in 
the header, and define a pad option to use for testing.
3) Leave the spec as it is now, with the addition of language that 
specifies that any additional data beyond the fixed message length be 
ignored. Future extensions would then define the use of that additional 
data.

	The security concern was that we had no clear plan on how and when we 
were going to address the on-link security issue. SEND is near 
completion, and there's no reason the work on securing MRD using some 
of their models can't happen now. The (perceived ... no hum was taken) 
consensus was that we should take securing of MRD on as a work-item, 
but as a separate document, thus not blocking the progression of the 
MRD base spec.

	- Jim

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Pekka Savola <[email-masked]>
Date: Wed, 3 Mar 2004 09:57:47 +0200 (EET)

On Mon, 1 Mar 2004, Jim Martin wrote:
> capabilities distribution 

There appear to be pushback to this.

> and additional security data for 
> authentication. 

This was so vague in the meeting in the meeting that I'm hesistant to 
do so, just that we could plug back something like this in 5 years, if 
MRD even gets widespread deployment.

As you don't use ND here, with all the funkiness required -- securing 
the traffic should be possible with IPsec easily, but of course the 
switches won't do it.

Remember that there is very little security in a physical link in the 
first place.

There seem to be some possibilities which could provide a start for a
security at a different level.  You could suggest that the switch be
able to verify that the L2 address of the router is X1, X2, .., XN.  
That would move the problem to be securing Layer 2 using a number of
mechanisms -- and when you could spoof your MAC addresses, you could
do a lot more harm anyway, so MRDISC wouldn't be interesting anymore.

> ignored. Future extensions would then define the use of that additional 

I'd go with 3).

> of their models can't happen now. 

Practically, SEND is not feasible for switches IMHO.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Wed, 3 Mar 2004 09:57:47 +0200 (EET)

I'd go with 3).