Wednesday, 27 July 2011< ^ >
Room Configuration

[16:55:00] Wes George joins the room
[17:02:51] <Wes George> scribing to an empty room... neat
[17:02:55] <Wes George> agenda
[17:03:14] <Wes George>
[17:03:24] <Wes George> current wg drafts
[17:03:41] <Wes George> a number of individual drafts, see draft tracker - if you put karp in the name
[17:03:50] <Wes George> design guide completed IETF LC
[17:03:53] <Wes George> waiting on revision
[17:04:00] <Wes George> threats is in LC
[17:04:02] <Wes George> please review
[17:04:14] <Wes George> clarificatio n- IETF LC
[17:04:21] <Wes George> key-table - not much discussion
[17:04:27] <Wes George> housley has changes to make
[17:04:32] <Wes George> few weeks
[17:04:49] <Wes George> couple of docs following on, should use that doc for normative refs
[17:05:03] <Wes George> including ospf-analysis, ops-model
[17:05:28] mjethanandani joins the room
[17:05:29] <Wes George> sam hartman - I thought we asked for LC for ospf analysis
[17:05:47] <Wes George> thinks it's ready, ops model need to solicit some reviews to make progress
[17:05:54] <Wes George> need to et it in sync with crypto tables
[17:06:30] <Wes George> who has read routing-tcp-analysis - 4 or 5 hands
[17:06:34] <Wes George> need more readers and reviewers
[17:06:45] <Wes George> charter has more Routing protos that need to be evaluated
[17:06:48] <Wes George> ISIS, rsvp-te
[17:06:53] <Wes George> have some people looking at pim
[17:07:00] <Wes George> please contact chairs if you have expertise
[17:07:10] <Wes George> avoids duplication of efforts
[17:07:15] <Wes George> routing protos using TCP
[17:08:12] <Wes George> comments?
[17:08:15] <Wes George> moving on
[17:08:36] <Wes George> now discussing :
[17:08:53] <Wes George> vero zheng presennting
[17:09:07] <Wes George> presented 00 version in mpls in beijing
[17:09:22] <Wes George> slide 2
[17:09:27] David Cooper joins the room
[17:09:29] <Wes George> recently adopted WG doc
[17:09:46] <Wes George> current state analysis and gap analysis
[17:09:49] <Wes George> problems related to LDP
[17:10:11] <Wes George> problem with spoofed hello tearing down est LDP session by annoucning shorter holdtime
[17:10:23] <Wes George> reported as real problem in operational ntwks
[17:10:48] <Wes George> no security in 5036
[17:11:00] <Wes George> TCP auth not helpful, hello is udp
[17:11:18] <Wes George> slide 3
[17:11:21] <Wes George> objective
[17:11:35] <Wes George> new crypto auth tlv, optional
[17:12:18] <Wes George> slide 4
[17:12:23] <Wes George> changes since last version
[17:12:37] <Wes George> introduce 64-bit increasing seq num
[17:12:42] <Wes George> must be inncremented
[17:13:24] <Wes George> auth type field removed as redundant
[17:13:31] <Wes George> slide 5
[17:13:33] <Wes George> next steps
[17:13:37] <Wes George> need more feedback
[17:13:42] <Wes George> request adoption in MPLS WG
[17:14:15] <Wes George> chair: agreed that protocol doc will go through the group that owns it, but need significant review from KARP
[17:14:43] <Wes George> comments ?
[17:14:47] <Wes George> none
[17:14:59] <Wes George> paul hoffman:
[17:15:08] <Wes George> wg question - how are you trackingg what the other WGs are doing
[17:15:29] <Wes George> you want input from this group, but how will you know when the other WG doc is ready to move forward (if we've done enough review)
[17:15:36] <Wes George> there are usually crickets when you ask for review
[17:15:48] <Wes George> joel: ad's are aware of which docs need to be reviewed and coord
[17:15:52] <Wes George> they ask KARP chairs
[17:16:01] <Wes George> for timing, they have incentive to let us know early
[17:16:11] <Wes George> paul - them tracking here, rather than you tracking
[17:16:37] <Wes George> tcp-md5 doesn't help, can we use TCP-AO
[17:16:41] <Wes George> sean turner speaking
[17:16:52] <Wes George> vero: no, ldp hello is udp
[17:17:05] <Wes George> paul - so udp ao could help ;-)
[17:17:13] <Wes George> sam - it's called AH ;-)
[17:17:24] <Wes George> ok now discussing RKMP
[17:17:31] <Wes George> dacheng zhang presenting
[17:17:40] <Wes George>
[17:17:42] <Wes George> slide 2
[17:17:45] <Wes George> intro
[17:17:58] <Wes George> unicast kmp to be compatible with multicast
[17:18:03] <Wes George> integrated solution
[17:18:16] <Wes George> takes adv of ikev2
[17:18:27] <Wes George> payloads only useful for ipsec are removed
[17:18:37] <Wes George> slide 3
[17:18:39] <Wes George> exchanges
[17:19:01] <Wes George> slide 4 - rkmp_SA_INIT
[17:19:17] <Wes George> identical to IKE_SA_INIT in ikev2
[17:19:44] <Wes George> slide 5
[17:19:48] <Wes George> RKMP_SA_AUTH
[17:20:04] <Wes George> most of the payload of IKE_SA_AUTH exchnage
[17:20:07] <Wes George> slide 6
[17:20:11] <Wes George> child SA exch
[17:20:38] <Wes George> need to define values of the fields
[17:20:51] <Wes George> paul hoffman - why is the nonce optional?
[17:21:13] <Wes George> notify optional? it's there for re-key, but do you have multiple SAs negotiated?
[17:21:29] <Wes George> sam - you might have BGP and LDP for example
[17:21:34] <Wes George> assuming different SA for each protocol
[17:21:42] <Wes George> relevant environments that willhave mult sa
[17:21:50] <Wes George> they share the same IKE SA
[17:21:53] spturner joins the room
[17:21:55] <Wes George> .......we think
[17:22:01] <Wes George> that could change if fthere's a reason to
[17:22:04] <Wes George> steve kent
[17:22:17] <Wes George> in order to support routing protocls you may need more stuff in the payload, and still figuring out ?
[17:22:30] <Wes George> a: to figure out more info in protocol ID field
[17:22:39] <Wes George> steve: you threw away traffic selector payloads - those could be used here
[17:22:52] <Wes George> before you say we don't need those, you want to go and identify those other fields
[17:22:59] <Wes George> then people will agree that 's a good asertion
[17:23:07] <Wes George> sam: we did some analysis on that monday at lunch
[17:23:13] <Wes George> we think the only thing we need is protocol id
[17:23:18] <Wes George> we thought that wasn't in the TS field
[17:23:23] <Wes George> that's wrong (per steve)
[17:23:47] <Wes George> steve - ok, if that's the case, my point was the higher level one -before you throw away something, then the answer is yes we need mutiple
[17:23:58] <Wes George> SA, traffic selectors are designs to accomodate
[17:24:16] <Wes George> to justify why deviating - when you throw away, you reduce the code reuse opportunity
[17:24:41] <Wes George> sam: what we're trying to say is that the traffic selector info you care obut for IPsec is diff than what you care about (actual bits) for routing protocols
[17:25:03] <Wes George> harold- we still need that info, and for routing these kinds of things, you might want to define a trafic selector payload type
[17:25:09] <Wes George> SA payload is quite complicated
[17:25:32] <Wes George> sam - that's fine, at some level I think maybe the comments are too detailed, agree, but there are a lot of other folks that need to review
[17:25:48] <Wes George> dan hartmans - doi and ikev1 ?
[17:25:54] <mjethanandani> This is Mahesh. In the next draft, we have put a case of using TS for different routing protocols.
[17:25:57] <Wes George> sam - we've talked, made position clear
[17:26:02] Benno Overeinder joins the room
[17:26:11] <Wes George> mahesh, at the mic?
[17:26:24] <mjethanandani> NO. I am in the chat room.
[17:26:38] <mjethanandani> Attending remotely.
[17:26:39] <Wes George> understand, do you want me to channel to the mic?
[17:26:47] <mjethanandani> Yes, please.
[17:26:50] <Wes George> ack
[17:28:14] <Wes George> chairs: moving on
[17:28:23] <Wes George> next slide - iterface to RKMP
[17:28:37] <Wes George> should be slide 7 I thin
[17:29:18] <Wes George> slide 8
[17:29:21] <Wes George> interface to key table
[17:29:31] <Wes George> slide 9
[17:29:36] <Wes George> interface to routing protocol
[17:29:49] hartmans joins the room
[17:30:36] <Wes George> uma chenduri
[17:30:43] <Wes George> question on interface to key table
[17:31:03] <Wes George> you're using the same ikev2 keys, are you giving the same set of keys to tcp-ao
[17:31:04] <Wes George> ?
[17:31:14] <mjethanandani> This is Mahesh again. Is there a case about having a single SA across different routing protocols? I guess I see it now in the future work.
[17:31:27] <Wes George> what kind fo keys are you giving to TCP-AO
[17:31:38] <Wes George> sam - ikev2 uses a separate key that you're giving to esp
[17:31:51] <Wes George> ack, will ask
[17:33:57] kivinen joins the room
[17:34:32] <Wes George> now discussing
[17:34:37] <Wes George> keyur patel presenting
[17:34:41] <Wes George> slide 2
[17:34:49] <Wes George> motivation
[17:35:06] <Wes George> slide 3
[17:35:11] <Wes George> KMPRP
[17:35:45] <Wes George> new dedicated port for ikev2, to distinguis from ipsec
[17:35:46] <Wes George> slide 4
[17:35:52] <Wes George> protocol exchanges
[17:37:34] <hartmans> The protocol master key is not the IKE SA key
[17:37:47] <Wes George> next slide - KMPRP state machine
[17:38:39] <Wes George> next slide - kmprp sa payload
[17:39:12] <Wes George> next slide - transforms
[17:39:33] <Wes George> next slide- kmprp operation
[17:41:04] <Wes George> next slide - KMPRP key mgmt database
[17:41:49] <Wes George> slide - routing protocol interactions
[17:42:32] <Wes George> slide - KMPRP operations
[17:43:06] <Wes George> questions?
[17:43:19] <Wes George> uma chanduri speaking
[17:43:52] <Wes George> are ikev2 exhcanges restricted or is it all
[17:43:57] <Wes George> keyur: currently restricted
[17:44:15] <Wes George> brian: not sure what other auth you mean - eap, not really approrpriate
[17:44:21] <Wes George> uma : eap still applicable
[17:44:51] <Wes George> certificat usage for routing? is that required
[17:44:57] <Wes George> brian : no decisions
[17:45:03] <Wes George> protocol and symantic reuse
[17:45:07] <Wes George> haven't mandated a profile yet
[17:45:09] <Wes George> dan hartmans
[17:45:15] <Wes George> what credential in eap
[17:45:31] <Wes George> uma - epa eke, eliminates cert usage, password auth
[17:45:36] <Wes George> sam -
[17:45:55] <Wes George> in the ops model doc, we have a good discussion of the various types of keys you might want ot use on routers
[17:46:13] <Wes George> rather than having this every time on a RP draft, let's do it once in the ops-model draft, and comment there
[17:46:26] <Wes George> then the consensus is less rough and we can stop having the discussion
[17:46:29] <Wes George> dan - like the answer
[17:46:34] <Wes George> about using eke
[17:46:41] <Wes George> would be a good key exchange
[17:46:51] <Wes George> why do we need this overhead if the group thinks that this is useful
[17:46:56] <Wes George> why not define a KMP that does that?
[17:47:14] <Wes George> operators gui is identical but they get the crypto
[17:47:37] <Wes George> sam - only doing that wouldn't handle several of the use cases in the design guide
[17:47:43] <Wes George> encourage you to read and comment ops model
[17:48:00] <Wes George> uma - general support ike 2 approach
[17:48:19] <Wes George> brian - reason I think that ikev2 is a good idea vs inventing a protocool, we have this available already on these devices
[17:48:31] <Wes George> if you go to the trouble of key management, may as well use what's available
[17:48:41] <Wes George> wanted to make a point about protocols and trnasforms - we've defined our own
[17:48:50] <Wes George> the existing onees don't match tcp-ao and others
[17:48:57] <Wes George> seemed better to define something specific and accurate for those
[17:49:08] <Wes George> we did include traffic selectors for the exact same reasons as comments earlier
[17:49:13] <Wes George> may be bgp on more than one port
[17:49:19] <Wes George> intersteing discussion, still need tohave it
[17:50:07] <Wes George> tero kivinen - we're starting to use ikev2, since I'm IANA for registries, I have to start thinking about registry
[17:50:14] Benno Overeinder leaves the room
[17:50:17] <Wes George> might be nice to have the same numbers for payloads
[17:50:25] <Wes George> might not want tcp-ao and esp the same though
[17:50:41] <Wes George> some questions around how we share but still have differerent registries
[17:51:01] <Wes George> brian - easy way to do this would be have these protools use true ikev2
[17:51:04] <mjethanandani> So we have two drafts addressing a similar problem if not the same. How do the chairs suggest we move forward? This is Mahesh again.
[17:51:11] <Wes George> ok stby
[17:51:13] <Wes George> will channel
[17:51:16] Benno Overeinder joins the room
[17:52:20] <Wes George> joel - rule of thumb - for a while authors work on their ideas, one hopes that they talk to each other, the hope is that one solution emerges
[17:52:21] <Wes George> if not, the group will kick one
[17:52:37] <Wes George> keyur - we chatted monday, we'll work towards merging docs
[17:52:58] <Wes George> ok
[17:53:02] <Wes George> now discussing
[17:53:04] <Wes George> PIM
[17:53:47] <Wes George> slide 2
[17:54:07] <Wes George> gap anaylsis covers pim-sm, bsr, etc
[17:54:17] <Wes George> anything multicast based on pim
[17:54:56] <Wes George> rfc 5796 mandates manual keying
[17:55:28] <Wes George> need to know what we want to get to and where we are, rather than saying this is waht we want to do to fix
[17:55:46] <Wes George> slide 3
[17:55:47] <Wes George> gaps
[17:56:09] <Wes George> no replay protection
[17:56:42] <Wes George> bill atwood - if you are using manual keying, the ipsec docs, not 5796 say you MUST turn off replay protection
[17:57:05] <Wes George> 5796 does makes it clear that if you have a kmp in place, replay should be turned on
[17:57:14] <Wes George> dacheng - rfc 2406
[17:57:37] <Wes George> multiple pim routers on the link, manual setup is tedious
[17:58:40] mjethanandani leaves the room
[17:59:48] <Wes George> result slide
[17:59:51] <Wes George> slide4 ?
[18:00:13] <Wes George> paul hoffman?- licensing issues?
[18:00:27] <Wes George> bill atwood - you have to pay cisco extra for support for IPsec
[18:00:38] <Wes George> paul - oh right, thought you meant IPR
[18:02:42] <Wes George> draft proposals?
[18:02:49] <Wes George> 1/2 and 2/2
[18:04:00] <Wes George> comments?
[18:04:04] <Wes George> paul hoffman
[18:04:28] <Wes George> there seemed to be a big leap of belief - because some vendors charge more for ipsec over pim that we should come up wit ha new protocol
[18:04:39] <Wes George> perhaps this is a vendor problem, not a protocol problme
[18:04:55] <Wes George> not convinced that ikev2/ipsec covers what you want in pim
[18:05:48] <Wes George> joel - asking the room
[18:06:00] <Wes George> should business issues like vendor charges from feature be removed from gap analysis
[18:06:09] <Wes George> hum for support
[18:06:31] <Wes George> sam - how you ask the question affects the answer you get
[18:06:43] <Wes George> different version - should deploymgn issues be considerd in the gap analysis
[18:06:53] <Wes George> deployability is covered
[18:07:11] <Wes George> problem (not as chair) we start gettingg into vendors charging /not charging is difficult because it can change
[18:07:20] <Wes George> sam - fact that people aren't deploying seems relevant
[18:07:28] <Wes George> doesn't seem harmful for list off reasons people cited
[18:07:34] <Wes George> must be part of an explanation
[18:08:04] <Wes George> steve kent - deployability is important but as paul pointed out, if one takes the example that vendors charge for x, there's no basis for assuming that vendoor won't charge for new protocol y
[18:08:18] <Wes George> operational complexity is a fine argument, but some vendors do charge. the question asked was appropriate
[18:08:41] <Wes George> sam - steve, i think there's some reason to assume vendors will charge less for mandatory to implements'
[18:08:45] <Wes George> steve - no, thank you
[18:08:58] <Wes George> bill atwood -a gap analysis should analyze gap,not propose solution
[18:09:17] <Wes George> pim-sm has different requieremts from ospf
[18:09:42] <Wes George> the inband solution that is part of osv2, they've transformed that to osv3 because ospf has certain packets that are prioritized
[18:09:53] <Wes George> you mess it up if you do ike on a separat blade
[18:09:55] <Wes George> not true for pim
[18:10:02] <Wes George> so those arguments fall out
[18:10:19] <Wes George> not requirement to integrate with the protocol as tightly in pim as in ospf
[18:10:35] <Wes George> the ospf stuff has been there for years, the pim only for one yera, so it's not surpriosig that there is no deployment
[18:10:46] <Wes George> once karp makes it easy, my hope is that we'll see both more widely deployed
[18:11:04] <Wes George> jeff - some boxes you do end up having extra hardwarea or extra load to run ipsec
[18:11:21] <Wes George> observation is that ipsec is a tool that happens to meet the security reqs. if it's availble it's preferable
[18:11:41] <Wes George> because it is being used for mor ethan one protocol
[18:11:56] <Wes George> it is worth considering that ther eare some penaltiles for putting ipsec on a box
[18:12:11] <Wes George> measuring risk - penalty to run things security is part of that
[18:12:22] <Wes George> there's no reason that a secondary solution can't be put forward
[18:13:08] <Wes George> confidentiality may not be a consideration in PIM
[18:13:14] <Wes George> our choices are to push for
[18:13:22] <Wes George> ipsec, knowing that there may be pushback
[18:13:36] <Wes George> alternatively, standardsized templates that have worked for other things
[18:13:45] <Wes George> paul hoffman - ipsecme chair
[18:14:12] <Wes George> extend your request for comparison - WG shouldn't take the bad reasons about IPsec overhead if it's being replaced with somethin with equivalnet overhead
[18:14:24] <Wes George> encryption/authentication take about the same CPU power
[18:14:34] <Wes George> we've heard this argument a lot - esp just do TLS, less overhead
[18:14:39] <Wes George> but it's not really
[18:15:14] <Wes George> i believe that if there were a better way to do ipsec, we'd have done it
[18:15:49] <Wes George> brian : the reaons that ospfv3 is lookingg to move away from ipsec - manual keyingg is something that you should only do for testing
[18:16:01] <Wes George> therefore they can't do anti-replay because they do manual keying - that's a gap
[18:16:18] <Wes George> people look at other things so that they can hanlde anti-replay alternate
[18:17:08] <Wes George> if we solve that in ipsec for manual keyingg then that might make it more attractive
[18:17:31] <Wes George> want to make sure that the implementation is better, but not necessarily eliminate manual keying
[18:17:40] <Wes George> paul hoffman - if oper community is used to manual keying
[18:18:05] <Wes George> if they're going to come up with a new proto so that they can do manual keying and then move on from there, the gap analysis only covers the first part
[18:18:17] <Wes George> are we looking at this as a two-phase solution?
[18:18:19] <Wes George> separately?
[18:18:40] <Wes George> should we come up with a solution thta works for manual keyin and then works for auto keying as well for every routing protocol?
[18:18:46] <Wes George> or two differnet solutions?
[18:18:48] weiyinxing joins the room
[18:18:53] <Wes George> if two different, thelatter will never get used
[18:19:23] <Wes George> would like more guidance on what we should be focusing on
[18:19:27] <Wes George> one solution or two
[18:23:43] <Wes George> my comments at the mic - please don't do two steps - do one that is better so that operators actually see benefit in the transition
[18:24:02] <Wes George> no objection to removing comments about vendors charging for ipsec support
[18:24:28] <Wes George> now discussing
[18:24:36] <Wes George> slide 2
[18:24:40] <Wes George> requirements to meet
[18:26:22] <Wes George> existing auth mechanisms
[18:27:27] <Wes George> slide - issues of inter-session replay atttacks
[18:28:37] <Wes George> slide - candidate solutions
[18:30:21] <Wes George> slide - impacts of bfd replays
[18:30:58] <Wes George> questions?
[18:31:10] <Wes George> jeff haas - bfd chair
[18:31:19] <Wes George> hmac cipher - not currently supported
[18:31:32] <Wes George> manav currenntly has drafts adopted in bfd group
[18:31:41] <Wes George> request that this group reviews those drafts to make sure issues are covered
[18:31:56] <Wes George> discriminator could act as a nonce for purposes of preventing replays
[18:32:07] <Wes George> offer advice to ensure those discriminators have enough entropy in them
[18:32:24] <Wes George> joel - request that you send a note to the list identifyin the docs
[18:33:09] <Wes George> now discussing
[18:34:00] <Wes George> slide 2
[18:34:03] <Wes George> overview
[18:34:49] <Wes George> no psuedoheader in the auth for ospfv2
[18:34:51] <Wes George> slide 3
[18:34:55] <Wes George> seq num ext 1/3
[18:35:20] <Wes George> if rec'd seq number is greater/equal
[18:35:21] <Wes George> only 32
[18:35:24] <Wes George> bit
[18:35:56] <Wes George> slide 4
[18:36:00] <Wes George> num ext 2/3
[18:36:16] <Wes George> boot count (first part of 64 bit counter) maintained in NV storage
[18:36:57] <Wes George> slide 5
[18:37:01] <Wes George> seq num ext 3/3
[18:37:29] <Wes George> slide 6 - key selection rules
[18:38:04] <Wes George> back to slide 5
[18:40:44] <Wes George> my comments at mic - don't call it reboot counter, call it wrap counter and be done with it
[18:40:46] <Wes George> slide 6
[18:41:49] <Wes George> slide 7
[18:41:54] <Wes George> ip source address protection
[18:43:15] <Wes George> brian - does everyone know what apad is?
[18:43:39] <Wes George> currently set as zero, proposing putting this value (ip add) in this field
[18:43:50] <Wes George> why is repeated l/4 ?
[18:44:06] <Wes George> you wuldn't need to repeat it, put in first 4 bytes and follow with apad
[18:44:11] <Wes George> brian - would like discussion
[18:44:33] <Wes George> sam - assuming hmac is strong, no security reason to prefer one solution over the other
[18:44:38] <Wes George> cost of coyping bytes?
[18:44:54] <Wes George> brian - can't imagine why you'd want to do construction, can you just copy 4 or 16 bytes in
[18:45:02] <Wes George> and figure out how many time you have to put it in
[18:45:15] <Wes George> acee: are there any digests that aren't 4 bytes?
[18:45:24] <Wes George> sam - remember this is v2 only
[18:45:34] <Wes George> brian - so the question is why not just copy the 4 bytes in
[18:45:45] <Wes George> acee- were some attacks that were possible even with 64-bit ext
[18:45:58] <Wes George> not requiring ospf routers to retain seq num state after the neighbor goes away
[18:46:12] <Wes George> when the state goes away, if a router goes out of service, you could replay a whole session
[18:46:18] <Wes George> we didn't think that was a problme
[18:46:28] <Wes George> recommend: note in security considerations
[18:46:37] <Wes George> slide 8 - next steps
[18:47:17] <Wes George> sam - encourage the review of the key table selection stuff
[18:47:38] <Wes George> paul hoffman - motivation on boot counter/wrap counter?
[18:47:49] <Wes George> ipsec no one is expected to save that state?
[18:48:03] <Wes George> sam - want replay protection for manual keying
[18:48:24] <Wes George> next slide - packet sample
[18:49:46] <Wes George> back to agenda slides, slide 7
[18:49:53] <Wes George> ospf discussion -
[18:50:30] <Wes George> another draft that preceded the gap analysis that did the same for ospfv3, and it's in IETF LC
[18:50:39] <Wes George> has the boot count construct and other things - good time for reviews
[18:51:05] <Wes George> sam - specficially ask that people review those gap analysis against thes two docs and make sure we fixed the things we thought that we needed to fix
[18:51:25] <Wes George> IPsec for manual keying?
[18:51:28] <Wes George> opinions?
[18:51:42] <Wes George> session ends
[18:51:46] Wes George leaves the room
[18:51:56] weiyinxing leaves the room
[18:52:24] spturner leaves the room
[18:54:42] kivinen leaves the room
[18:54:52] David Cooper leaves the room
[18:59:36] hartmans leaves the room
[19:05:03] spturner joins the room
[19:05:24] spturner leaves the room
[19:08:51] spturner joins the room
[19:25:15] hartmans joins the room
[19:31:10] hartmans leaves the room
[19:37:54] spturner leaves the room
[19:39:21] spturner joins the room
[19:39:54] spturner leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!