Subject: [magma] Magma Meeting notes

From: Brian Haberman <[email-masked]>
Date: Thu, 21 Nov 2002 12:09:01 -0500

All,
      These are the unfiltered meeting minutes from the meeting.
Many thanks to Marshall for being scribe.  Comments, updates,
and questions encouraged.

Regards,
Brian

--

Salon II INT	magma	Multicast & Anycast Group Membership WG *
</ietf/02nov/magma.txt>

Document status
MLDv1 source address selection is in last call - proposed standard
MLDv2 specification is at the IESG
Source filtering API is awaiting author response to comments

Thaler - I'll take the action item on that

ready for last call
MSNIP - proposed standard
Proxy
Snooping -informational
IGMPv3/MLDv2 for SSM and

Thaler - I may have reservations about MSNIP as a proposed standard as 
there may
be alternatives. As experimental it would be OK.

Q. Problems with the MSNIP spec -
I tried to understand the design rational for the host state .

If you have 2 or more router, the host state information is router 
based, so you
have to double or triple your information.

And what if there is no router but lots of hosts - the state information 
could
be used by lots of hosts ?

Audience - How many hosts would be a problem - a million ? How much state is
really kept ? What's the problem - the computation or the storage ?

A second concern - the scenario is SSM based - what about proxy based.
If you want to run MSNIP on a proxy, this is not addressed. IGMP does 
not have
receiver subscription information.

Brian - I think that based on Dave's comments the MSNIP draft will go as
experimental.

-- Charter update
Originally, wanted to do v4 first, v6 afterwards.
Now, given the  speed of developments, Bill and I cajoled the author's to
include v6 as well. The only issue is the IGMPv3/MLDv2 MIB - whether 
these can
be combined or not.

Bill Fenner - there are benefits both ways. If separate, each can be 
extensions
of
the existing MIBs. If together, then the old managers would not be able 
to get
information about the new st

Brian - Also the names of the variables and the granularity of time tags 
would
be different.

Dave Thaler - There are other changes to the MIBs that are ongoing so it may
make more sense to combine them.

Bill Fenner - I agree that neither the naming or the granularity is a show
stopper. It just has to be taken care of.

--Snooping draft
Need a baseline of what to do - this is a strictly informational document.

the 6th version of the draft is answers to open issues etc. from switch 
vendors
- conclusions - ready for last call.

Beau Williamson - when you have a conflict between include and exclude
Draft says the first person "rules" - whereas IGMPv3 says, includes 
override.

Bill Fenner - This sounds wrong.

Audience member - What happens to snooping switches when we upgrade IGMP 
or MLD
?

Brian - There is some sentiment in the MBONE working group that snooping 
is not
aa good idea.

Audience member - Yes, we should document this stuff but say that 
snooping is
not a good idea.

-- MCOP
how it works
receiver sends igmp/ mld as normal.
Router sends a MCOP validate message to a MCA with a Database.
Once it is validated, a verify message is sent back and the join can go as
normal.

this may be implemented over Diameter once this is published.

Receivers should use RFC3122 inverse NDP to find out global scope 
address of the
client.

Open issues -
How is the client informed that access is denied ?
Could use IGMP "administratively prohibited" messages but these are
supposed to have TTL-1. Should this be changed ?

Next steps
Finalize implementation
MCA+database protocol

Can MCOP be used to filter MSDP SA's
Should the number of group joins per host be limited.

Want to publish as experimental.

Dave Thaler - 4 main points from Japan
- didn't talk about what the actual threat model is
The threat model is something like the Ramen worm.

Beau Williamson
I am constantly getting requests from network administrators to limit the
groups or the number of groups that users are allowed to join or send.

Dave Thaler -
What do you when the MCA doesn't know anything about the group ?
A.) We could do either as a policy issue - it's policy not protocol

Dave Thaler - Why can't you use an existing protocol.
Also, is the right WG for this ?

Daniel - I think that some means of access control is needed - whether 
this is
the right one is another question.

Also, I am not convinced that the clients IP address will be enough for an
identifier.

Beau Williamson - I would like to see something like this move forward - 
it is
desperately needed.

However, at the very least the authentication needs to move beyond IP 
address,
and there needs to be more on rate limiting.

You are assuming the same range model that is the same as autoRP and BSR 
- real
address ranges have holes.

Answer - You use the longest matching prefix

Brian - If you get these addresses dynamically, then you will have gotten a
token, which you could pass to the

There is not a clear definition of the threat model. Authentication is 
not in
our charter, and this model does not involve IGMP/MLD and so  this does 
belong
here. Let's first figure out the problem and then figure out the protocol.
<clapping>

--IGAP - Tsunemasa Hayashi
IGMP for user Authentication Protocol

architecture

ISP/NSP connection to Internet
Also, a CDN
both attached to edge router

IP Multicast in CDP
Successful services need
- access control
- limit to intra domain multicast to avoid interprovider issues
- collaborations between content providers and network providers

At present
No user access control
no user usage information mechanism
multicast content security is being developed, but does not provide all 
needed
functionality.

IGAP adds a protocol framework to transport user information to IGMP
enables providers to
  - enforce access control by a group
- collect per user usage information

IGAP is only used between edge router and end user.

Initial IGAP is based on IGMPv2
Basically, edge router connects to a AAA server
wants to make this a WG draft

Eubanks - asked why IGAP needs a modification to the user - edge router
interaction.
Answer - User authentication is based on more than the User IP address.

Toerless - I do not think that the working group should accept any draft 
based
on IGMPv2, unless it is historical only.

Audience member - This seems strong as it implies as IGMPv2 is harmful, 
and any
way IGMPv3 is still in draft status.

Beau Williamson - This is effectively IGMPv4, and the chances of getting it
deployed is very low. And what happens when a user sends IGMP instead of 
IGAP ?
Then the router will

Brian - This is not really a network layer functionality - it has been done
before at a higher layer in unicast, and that would be appropriate here.

Audience - This is a piggy back protocol. IGMP happens to be a protocol to
register interest, and we have seen elsewhere in the IETF attempts to 
use this
functionality to do other things just because it exists.

Toerless - Multicast is different, as you can be sent traffic that you 
cannot
use.

Audience member - And I do not see any attempts to synchronize all of these
proposals.

Thomas Hardjono - I think we need a requirements document and also need 
to worry
about layers - some of this stuff should not be done at the transport 
layers.

-- Dave Thaler - Non IGMP Specific Security

General Internet case
Receiver node
gets a group key from the group key server
hop by hop transmission between call the ISP's in the chain.
Why hop by hop - because you can only assume a security relationship between
neighboring ISP's

In general, there is no security relationship between a user and the ISP.

General Case needs -
An ISP needs to
- do some sort of accounting per client
- needs to use ACL's, for ingress filtering, say.

Content provider needs to control who views the content

These goals are not multicast specific

One solution
When the receiver "connects" you can place ACL's based on relationship at
connect time.

You can  secure  hop by hop messages in the same fashion

Port ACL's can change over time.

Per group security and keys can be done between apps and group key servers
Also data can be encrypted

-- Protecting bandwidth
  - You can charge the users
  - The _same_ problem exists with unicast data and is not solved there
  - If the receiver and content provider are on the same network, the 
content
authorizer can cause the ACL to be updated

Conclusions -

Group specific security in IGMP is not reasonable
Other solutions appear to solve this general case

-> No Need to change IGMP/MLD

Audience - I would argue that having a full mesh security solution
does more for  you than the existing piecemeal solutions.

Thaler - In the general case you do not have a full mesh security solution
because ISP's do _not_ trust one another.

Toerless - There should be some message back to the receiver if access is
denied.

Greg Shepard - People lining up expectations of multicast so that 
nothing gets
deployed is a problem. However, the problem is not multicast but not UDP.

Audience member - What we want to do is to control access.

Dave - there are two people who have an interest - the content provider 
and the
network operator. The content provider should authenticate and encrypt, the
network operator cares about bandwidth and therefore can apply "ACL's" (in a
generic sense - they might be port filters, source filters, etc.). These are
different problems.

Beau Williamson - The IGAP protocol may solve the multicast UDP problem, 
but not
the unicast UDP problem, so this  does not solve the general problem.

Tom P. If we have a general solution to the general problem, why do we 
need a
specific solution to a subset of the general problem.

IGAP presenter - What is the specific solution for the special case 
where the
content provider and the receiver are on the same network ?

Toerless - Do you mean that there will never be a need for this ?
Dave Thaler - I never would say never. I am just saying that I do not see it
right now.

Audience member
Two solutions from an ISP point of view
- we pay for each bit that passes from another ISP - BAD
- or, encryption.

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