RE: [Syslog] Charter comments from IESG Review
On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote: Of course, a threat model should also be developed, but please keep in mind that anything other than signatures breaks what this WG has fought for since Vancouver. syslog-protocol should be finished (I hope we are there soon) as well as syslog-transport-udp. Then, these both should be taken to a rest and syslog-sign be modified in the sense of -transport and being worked on. I think this can probably done quickly, because -sign is almost complete and just needs to be modified to take advantage of -protocol. To be honest, though, I have to admit that I expect many of the upcoming implementations to violate syslog-protocol by just implementing -protocol and -transport-udp, but not -sign. But that's probably not something to care about... I know that some other mails discussed the same topic and a misunderstanding has already been resolved about whether to support transport-udp or not. I would say that addressing the security concerns at the transport level is way easier management and implementation wise than implementing syslog-sign. And in addition they address a different problem: 1) transport level implements security mechanisms on a per hop-by-hop basis, the message itself is not authenticated, each of the relay stations can modify the message 2) syslog-sign implements per-message, end-to-end authenticity where the relay hosts cannot modify messages as they are individually signed by their origin. So I'd go with using TLS/DTLS on the transport first and then possibly adapting syslog-sign when the transport issues are resolved. -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
I agree with Balazs suggestion and his reasoning. Rainer -Original Message- From: Balazs Scheidler [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 10:52 AM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] Charter comments from IESG Review On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote: Of course, a threat model should also be developed, but please keep in mind that anything other than signatures breaks what this WG has fought for since Vancouver. syslog-protocol should be finished (I hope we are there soon) as well as syslog-transport-udp. Then, these both should be taken to a rest and syslog-sign be modified in the sense of -transport and being worked on. I think this can probably done quickly, because -sign is almost complete and just needs to be modified to take advantage of -protocol. To be honest, though, I have to admit that I expect many of the upcoming implementations to violate syslog-protocol by just implementing -protocol and -transport-udp, but not -sign. But that's probably not something to care about... I know that some other mails discussed the same topic and a misunderstanding has already been resolved about whether to support transport-udp or not. I would say that addressing the security concerns at the transport level is way easier management and implementation wise than implementing syslog-sign. And in addition they address a different problem: 1) transport level implements security mechanisms on a per hop-by-hop basis, the message itself is not authenticated, each of the relay stations can modify the message 2) syslog-sign implements per-message, end-to-end authenticity where the relay hosts cannot modify messages as they are individually signed by their origin. So I'd go with using TLS/DTLS on the transport first and then possibly adapting syslog-sign when the transport issues are resolved. -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
On Tue, 2006-01-10 at 22:02 +1100, Darren Reed wrote: On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote: I would say that addressing the security concerns at the transport level is way easier management and implementation wise than implementing syslog-sign. I disagree with the statement about management as the problem is the same for using a secure protocol at either transport or application level. My reasoning is that people are used to encrypting channels with SSL, they are used to the PKI requirements it involves, they are familiar with SSL cipher suites, CA verification parameters and the like, in summary SSL/TLS itself is a familiar cryptographic framework. Syslog-sign on the other hand is different, it is true that it is going to use X.509 PKI, but all the other familiarity is gone. My point regarding managebility is that network operators use TLS already with a lot of applications (HTTPS is the primer example), compared to this using syslog/TLS is simple. 1) transport level implements security mechanisms on a per hop-by-hop basis, the message itself is not authenticated, each of the relay stations can modify the message 2) syslog-sign implements per-message, end-to-end authenticity where the relay hosts cannot modify messages as they are individually signed by their origin. So I'd go with using TLS/DTLS on the transport first and then possibly adapting syslog-sign when the transport issues are resolved. (1) and (2) are complimentary and one do not exclude the other from being necessary. True, (1) and (2) are independent, my point was to give priority to the first one as it already solves a lot of problems and will help us keep focused. -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
Hi Sam WG, I understand the reasoning behind requiring a security mechanism. I just want to remind everyone that a major drawback in Vancouver was that we had lost some backwards-compatibility to existing syslog implementations. The weeks after Vancouver we worked hard to find a minimum consensus on how we could provide the needed backwards compatibility. When we mandate a security mechanism, we must be very careful not to invalidate all these attempts. Why? Simply because any transport-layer requirement (DTSL, SSL, SSH, whatever) would NOT be compatible with currently existing syslog implementations. So due to this requirement, we can not create a backwards-compatible spec (not even in the sense that existing receivers can put messages in the right bins). So in my point of view the only option is to use structured-data embedded signatures. As they do not modify the message format AND work over UDP, they allow old receivers to receive messages and put them into the right bins while new receivers can enjoy their benefits. In my point of view, anything further (like required confidentiality) conflicts with the backwards-compatibility approach and thus with the rest of the new charter. So I propose we update the charter to include that item and make sure syslog-sign advances. Syslog-protocol can than require all messages to be signed via syslog-sign. Of course, a threat model should also be developed, but please keep in mind that anything other than signatures breaks what this WG has fought for since Vancouver. syslog-protocol should be finished (I hope we are there soon) as well as syslog-transport-udp. Then, these both should be taken to a rest and syslog-sign be modified in the sense of -transport and being worked on. I think this can probably done quickly, because -sign is almost complete and just needs to be modified to take advantage of -protocol. To be honest, though, I have to admit that I expect many of the upcoming implementations to violate syslog-protocol by just implementing -protocol and -transport-udp, but not -sign. But that's probably not something to care about... Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Hartman Sent: Thursday, January 05, 2006 11:12 PM To: [EMAIL PROTECTED] Subject: [Syslog] Charter comments from IESG Review Hi. The IESg reviewed the proposed syslog charter at today's telechat and decided that it requires revision. The main concern seems to be the lack of a mandatory to implement security mechanism. I indicated this might be the case in the Vancouver meeting. so, you definitely need to have some sort of mandatory to implement security mechanism. I'm not quite sure what needs to be said about this in the charter. But the working group will need to: 1) Identify a threat model for syslog 2) Define mechanisms to address these threats. So, questions for the threat model include things like whether confidentiality is important or whether integrity of mesages is sufficient. Depending on the threat model here are some possible solutions: 1) Require some transport like syslog over TLS|DTLS be implemented. 2) Require that all senders implement signatures stored in structured data as an option. I don't think you need to commit to one of these options now. However, you do need to reflect the security issues in the charter. --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
Tom, If so, yes, both S/MIME and OpenPGP support this model. However I'll point oun that it is not a requirement that syslog work that way; for example RFC 3195 certainly has connections. I'll look at those, thanks. I agree syslog could be, perhaps should be for meaningful security, but often at present is not, so I wanted to see what security was possible with just one way communication They use pre-shared secrets. It's probably best if you look at syslog-sign, which provides the necessary mechanisms for syslog. Please note that it still transmits data in clear-text (which I consider a requirement to remain backwards-compatible). Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes: Rainer Hi Sam WG, I understand the reasoning behind requiring a Rainer security mechanism. I just want to remind everyone that a Rainer major drawback in Vancouver was that we had lost some Rainer backwards-compatibility to existing syslog Rainer implementations. Rainer The weeks after Vancouver we worked hard to find a minimum Rainer consensus on how we could provide the needed backwards Rainer compatibility. Rainer When we mandate a security mechanism, we must be very Rainer careful not to invalidate all these attempts. Agreed. Rainer Why? Simply Rainer because any transport-layer requirement (DTSL, SSL, SSH, Rainer whatever) would NOT be compatible with currently existing Rainer syslog implementations. So due to this requirement, we can Rainer not create a backwards-compatible spec (not even in the Rainer sense that existing receivers can put messages in the Rainer right bins). Let's be clear about what backward compatibility we're looking for. Do we require that new senders be able to be configured to talk to old receivers? Or do we require that old receivers be able to put any message from a new sender into the right place? In particular what you're seeming to say implies that we cannot define new transports because doing so would be backward incompatible. I don't think that is what we said. If we do define a new transport, presumably both UDP and the secure transport would be mandatory to implement. Rainer So in my point of view the only option is to Rainer use structured-data embedded signatures. As they do not Rainer modify the message format AND work over UDP, they allow Rainer old receivers to receive messages and put them into the Rainer right bins while new receivers can enjoy their benefits. This is a valid approach. This means delaying protocol until syslog-sign is ready. Note that Russ, Bill Fenner and I have serious questions about syslog-sign because it does not reuse CMS, OpenPGP or some other format. We would need these questions answered before it could go forward in its current form. You would also need to make syslog-sign mandatory to implement and would need to believe that people wern't going to just ignore that. Rainer In my point of view, anything further (like required Rainer confidentiality) conflicts with the Rainer backwards-compatibility approach and thus with the rest of Rainer the new charter. I'm going to ask you to do the analysis in terms of what is required from a security standpoint. If that analysis ends up being incompatible with backward compatibility requirements, then we'll have to evaluate tradeoffs. However if there is a solution compatible both ith security and backward compatibility, that's better. --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes: Rainer Tom, If so, yes, both S/MIME and OpenPGP support this model. However I'll point oun that it is not a requirement that syslog work that way; for example RFC 3195 certainly has connections. I'll look at those, thanks. I agree syslog could be, perhaps should be for meaningful security, but often at present is not, so I wanted to see what security was possible with just one way communication Rainer They use pre-shared secrets. Not typically. They typically use public keys. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
-Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Monday, January 09, 2006 1:08 PM To: Rainer Gerhards Cc: Tom Petch; [EMAIL PROTECTED] Subject: Re: [Syslog] Charter comments from IESG Review Rainer == Rainer Gerhards [EMAIL PROTECTED] writes: Rainer Tom, If so, yes, both S/MIME and OpenPGP support this model. However I'll point oun that it is not a requirement that syslog work that way; for example RFC 3195 certainly has connections. I'll look at those, thanks. I agree syslog could be, perhaps should be for meaningful security, but often at present is not, so I wanted to see what security was possible with just one way communication Rainer They use pre-shared secrets. Not typically. They typically use public keys. Sorry, yes, I was totally wrong in my wording. What I intended to say was that the keys are exchanged on a medium different then the current session (e.g. key servers). So this means some other protocol is required to obtain that information (and it is processed outside of the syslog protocol). Thus, I wanted to say, it does not necessarily need to change the simplex nature of syslog (but some initial negotiation is necessary, which I do not think to be a problem). Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes: Rainer Sorry, yes, I was totally wrong in my wording. What I Rainer intended to say was that the keys are exchanged on a Rainer medium different then the current session (e.g. key Rainer servers). This is not typically how things work for S/MIME. In S/MIME I will typically inclue a certificate (which includes my public key) in-band with some signature data. If I was generating a lot of signatures I might only sometimes include my certificate to save on space and bandwith. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
Sam, Rainer Why? Simply Rainer because any transport-layer requirement (DTSL, SSL, SSH, Rainer whatever) would NOT be compatible with currently existing Rainer syslog implementations. So due to this requirement, we can Rainer not create a backwards-compatible spec (not even in the Rainer sense that existing receivers can put messages in the Rainer right bins). Let's be clear about what backward compatibility we're looking for. Do we require that new senders be able to be configured to talk to old receivers? I depens on what you mean with that - if to be configured to talk to old receivers means they must not use -protocol but rfc 3164 instead, this is not what was discussed on this list (-protocol-14 had addressed this already). Or do we require that old receivers be able to put any message from a new sender into the right place? Not over any transport, but the core need behind the recent changes was that -protocol/-transport-udp messages should allow an old sender to put it into the right bin. This implies plain text transmission. In particular what you're seeming to say implies that we cannot define new transports because doing so would be backward incompatible. I don't think that is what we said. If we do define a new transport, presumably both UDP and the secure transport would be mandatory to implement. This looks like I misunderstood your intension. I thought that unsecured UDP should no longer be supported. So what you actually said is that we can go ahead with the unsecured UDP as long as we also mandate a (different) secure transport. If that is the case, I am reliefed, because this is something that can practically be done. And, yes, configuring a sender to use unsecured udp (-transport-udp) for one target and a secured transport for another target is definitely a good option. We just need to be able to interoperate with the unsecured plain text udp syslog world. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes: Rainer This looks like I misunderstood your intension. I thought Rainer that unsecured UDP should no longer be supported. That was not my intent. Rainer So what Rainer you actually said is that we can go ahead with the Rainer unsecured UDP as long as we also mandate a (different) Rainer secure transport. What I said is that you need to have a mandatory-to-implement mode of operation that meets your security goals. You can certainly support transport-udp. One way to do this is to have a new secure transport. Another way to do this (assuming you decide confidentiality need not be a security goal) is to use something like syslog-sign. Personally I think a new transport might be more important than syslog-sign but so long as the WG clearly articulates its security goals, those goals make sense, and the wg then meets the goals, the preference between syslog-sign and transport is a WG matter. Also, I agree that you have described the threats to syslog in adequate detail already; the question is which threats do you want toaddress. You do need to explain that in your documents and you need to justify that decision. So, how much needs to be done for the charter? Well, I'd like text added to the deliverable for -protocol noting that it will require a secure mode of operation. If you are going to decide that syslog-sign is the right path, then you should add text about that to the charter. I don't think you need to choose a transport before chartering, although I caution that transport wars are a good way to lose WG momentum; look at the ISMS work over the past few IETFs for an example. --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
Sam I was about to say that we were getting into useful detail but that we could sort out the charter without it, but you seem to saying not. That is, I was hoping that where the charter says The goal of this working group is to address the security and integrity problems it might say The goal of this working group is to identify the security problems, perform a threat analysis and document a solution to the perceived threats, without committing us to either a -sign or a secure transport approach (and yes, we did start the transport wars, some time ago, with SSH v TLS:-( Tom Petch - Original Message - From: Sam Hartman [EMAIL PROTECTED] To: Rainer Gerhards [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 09, 2006 2:35 PM Subject: Re: [Syslog] Charter comments from IESG Review Rainer == Rainer Gerhards [EMAIL PROTECTED] writes: Rainer This looks like I misunderstood your intension. I thought Rainer that unsecured UDP should no longer be supported. That was not my intent. Rainer So what Rainer you actually said is that we can go ahead with the Rainer unsecured UDP as long as we also mandate a (different) Rainer secure transport. What I said is that you need to have a mandatory-to-implement mode of operation that meets your security goals. You can certainly support transport-udp. One way to do this is to have a new secure transport. Another way to do this (assuming you decide confidentiality need not be a security goal) is to use something like syslog-sign. Personally I think a new transport might be more important than syslog-sign but so long as the WG clearly articulates its security goals, those goals make sense, and the wg then meets the goals, the preference between syslog-sign and transport is a WG matter. Also, I agree that you have described the threats to syslog in adequate detail already; the question is which threats do you want toaddress. You do need to explain that in your documents and you need to justify that decision. So, how much needs to be done for the charter? Well, I'd like text added to the deliverable for -protocol noting that it will require a secure mode of operation. If you are going to decide that syslog-sign is the right path, then you should add text about that to the charter. I don't think you need to choose a transport before chartering, although I caution that transport wars are a good way to lose WG momentum; look at the ISMS work over the past few IETFs for an example. --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
Tom == Tom Petch [EMAIL PROTECTED] writes: Tom without committing us to either a -sign or a secure transport Tom approach (and yes, we did start the transport wars, some time Tom ago, with SSH v TLS:-( I really think that you need to identify your deliverables in the charter. Either sign is or is not a critical path deliverable. (Similarly, if you go the transport route, you need a critical path deliverable of a secure transport.) --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
- Original Message - From: Sam Hartman [EMAIL PROTECTED] To: Tom Petch [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, January 06, 2006 10:27 PM Subject: Re: [Syslog] Charter comments from IESG Review Tom == Tom Petch [EMAIL PROTECTED] writes: Tom Sam I struggle to think what a security system would look Tom like when the protocol is purely simplex, apart from a MAC to Tom give integrity with some shared secret transmitted totally Tom out of band. By this do you mean without two-way communication? Yes, I meant without two-way communication If so, yes, both S/MIME and OpenPGP support this model. However I'll point oun that it is not a requirement that syslog work that way; for example RFC 3195 certainly has connections. I'll look at those, thanks. I agree syslog could be, perhaps should be for meaningful security, but often at present is not, so I wanted to see what security was possible with just one way communication Tom Petch ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
Hi Sam, On Thu, 5 Jan 2006, Sam Hartman wrote: Hi. The IESg reviewed the proposed syslog charter at today's telechat and decided that it requires revision. The main concern seems to be the lack of a mandatory to implement security mechanism. I indicated this might be the case in the Vancouver meeting. so, you definitely need to have some sort of mandatory to implement security mechanism. I'm not quite sure what needs to be said about this in the charter. But the working group will need to: 1) Identify a threat model for syslog Is Section 8 in draft-ietf-syslog-protocol-16.txt sufficient? Alternatively, Section 6 in RFC 3164 is fairly comprehensive. 2) Define mechanisms to address these threats. So, questions for the threat model include things like whether confidentiality is important or whether integrity of mesages is sufficient. Depending on the threat model here are some possible solutions: 1) Require some transport like syslog over TLS|DTLS be implemented. RFC 3195 requires the use of RFC 3080 which requires TLS. 2) Require that all senders implement signatures stored in structured data as an option. That's likely addressed through syslog-sign. I don't think you need to commit to one of these options now. However, you do need to reflect the security issues in the charter. The questions for you: - Do we need to produce a threat model in a new document? - Can we state that the threats will be addresses in syslog-sign and 3195bis? I will also note that there is a group of implementors who have already done syslog/tls. I suspect they would like to codify this in a standard and that may also address the threats. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
Chris == Chris Lonvick [EMAIL PROTECTED] writes: Chris Is Section 8 in draft-ietf-syslog-protocol-16.txt Chris sufficient? Alternatively, Section 6 in RFC 3164 is fairly Chris comprehensive. Both of these look good. My main question with them is whether you believe it is a requirement to address all these threats or whether addressing a subset is sufficient. 2) Define mechanisms to address these threats. So, questions for the threat model include things like whether confidentiality is important or whether integrity of mesages is sufficient. Depending on the threat model here are some possible solutions: 1) Require some transport like syslog over TLS|DTLS be implemented. Chris RFC 3195 requires the use of RFC 3080 which requires TLS. Noted. 2) Require that all senders implement signatures stored in structured data as an option. Chris That's likely addressed through syslog-sign. Agreed. I don't think you need to commit to one of these options now. However, you do need to reflect the security issues in the charter. Chris The questions for you: Chris - Do we need to produce a threat model in a new document? No, although you probably need to decide which threats you are addressing. Chris - Can we state that the threats will be addresses in Chris syslog-sign and 3195bis? I will also note that there is a Chris group of implementors who have already done syslog/tls. I Chris suspect they would like to codify this in a standard and Chris that may also address the threats. You need to require everyone who implements syslog-protocol to implement your mandatory to implement security mechanism. That could be syslog-sign or 3195bis, but you'd have to actually make that normative requirement in protocol. I think the real question here is what mechanism can you choose that people will actually implement. --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
Sam I struggle to think what a security system would look like when the protocol is purely simplex, apart from a MAC to give integrity with some shared secret transmitted totally out of band. Are there any examples of simplex security elsewhere in the IETF? Tom Petch - Original Message - From: Sam Hartman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 05, 2006 11:12 PM Subject: [Syslog] Charter comments from IESG Review Hi. The IESg reviewed the proposed syslog charter at today's telechat and decided that it requires revision. The main concern seems to be the lack of a mandatory to implement security mechanism. I indicated this might be the case in the Vancouver meeting. so, you definitely need to have some sort of mandatory to implement security mechanism. I'm not quite sure what needs to be said about this in the charter. But the working group will need to: 1) Identify a threat model for syslog 2) Define mechanisms to address these threats. So, questions for the threat model include things like whether confidentiality is important or whether integrity of mesages is sufficient. Depending on the threat model here are some possible solutions: 1) Require some transport like syslog over TLS|DTLS be implemented. 2) Require that all senders implement signatures stored in structured data as an option. I don't think you need to commit to one of these options now. However, you do need to reflect the security issues in the charter. --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
Tom == Tom Petch [EMAIL PROTECTED] writes: Tom Sam I struggle to think what a security system would look Tom like when the protocol is purely simplex, apart from a MAC to Tom give integrity with some shared secret transmitted totally Tom out of band. By this do you mean without two-way communication? If so, yes, both S/MIME and OpenPGP support this model. However I'll point oun that it is not a requirement that syslog work that way; for example RFC 3195 certainly has connections. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
