Re: Request To Advance: <draft-ietf-6man-rpl-routing-header-03.txt>

[Alexandru Petrescu <[e-mail]>]

[if needed I can trim the To/Cc, I just dont know]

Hello Brian, Chairs, ADs, 6man, roll,

This draft-ietf-6man-rpl-routing-header-03 is way too brief about the
security risks of RPL RH.  It basically states that this RPL RH is not
risky when looked at from the outside, and does not seem to talk about
risks from within RPL network.  This perspective contradicts the RPL
draft which says "[RPL networks] are vulnerable to passive eavesdropping
attacks [and more]".

This RPL RH is intended to be used with RPL protocol.  RPL's draft
security text states that AH and message auth code should be used over
the entire IPv6 headers; hence over this RPL RH as well.

However, there is no example of how to do it.  Whereas it is known how
to apply AH over Routing Header Type 0 (some advice in RFC4302).

For RPL RH, we had an agreeing discussion on the RoLL WG email list
September 10th, 2010, about a step-by-step description of using AH over
RPL RH.  See the first attached email and url:
http://www.ietf.org/mail-archive/web/roll/current/msg05418.html
My agreement to that discussion is ok, but does not show in these
archives I dont know why, but I attached it as well to this email.

I suggest inserting that example of using AH over RPL RH into the RPL RH
draft.  Maybe as an appendix, as an example.  I find it very useful to
implementer.

(note: I do not know whether Robert Cragie who wrote that proposal on
the mailing list agrees or even needs to insert it in the draft).

Thank you for considering this issue, and I will follow this issue,

Alex

Le 30/03/2011 17:12, Brian Haberman a écrit :
> Jari&  Ralph, On behalf of the 6MAN WG, the chairs request the
> advancement of:
>
> Title     : An IPv6 Routing Header for Source Routes with RPL
> Author(s) : J. Hui, et al. Filename  :
> draft-ietf-6man-rpl-routing-header-03.txt Pages     : 19 Date      :
> 2011-03-29
>
> as a Proposed Standard.  A 6MAN WG Last Call ended on December 6,
> 2010 and this version addresses all comments raised.
>
> Regards, Brian&  Bob
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

--- Begin Message ---

  Hi Alex,

Thank you for focusing on a pertinent issue. You are right to highlight 
what we do with a RH4 header as I believe secured DAO ACK is the (only) 
RPL control message which requires RH4 in non-storing mode.

So, to follow the rules for mutable and predictable fields (see RFC 
4302), we can resubstitute at the end:

Consider the following:

A -> B -> C -> D -> E

A -> B:

|Src|Dst|RH4            |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
| A | B | 3 | C | D | E |

B -> C:

|Src|Dst|RH4            |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
| A | C | 2 | B | D | E |

C -> D:

|Src|Dst|RH4            |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
| A | D | 1 | B | C | E |

D -> E:

|Src|Dst|RH4            |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
| A | E | 0 | B | C | D |

When the packet arrives at E, recreate the original RH4 header for MAC 
computation:

n = ((Hdr Ext Len * 8) - Pad) / (16 - Comp)
tmp = Dst
Dst = RH4.A[0]
RH4.Seq = n
for (k = 1; k < n; k++)
{
   RH4.A[k-1] = RH4.A[k]
}
RH4.A[k] = tmp

|Src|Dst|RH4            |
|   |   |Seq|L0 |L1 |L2 |
-------------------------
| A | B | 3 | C | D | E |

Is that acceptable?

Now, just because I refer to IPSec AH, it doesn't mean I am suggesting 
we use it. I am suggesting we can use the fundamental principles from 
IPSec for an equivalent operation.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
[phone]
[phone]
http://www.gridmerge.com <http://www.gridmerge.com/>


On 10/09/2010 4:22 PM, Alexandru Petrescu wrote:
> Le 10/09/2010 11:55, Robert Cragie a écrit :
>> David,
>>
>> I totally agree with what you say. Thank you for restating generally
>>  that IPSec has already been extensively considered - I use the term
>>  'paraphernalia' as a general term for the overheads.
>>
>> Alex - can we please drop the IPSec discussion and move on and
>> concentrate on the things which do need to sorted out?
>
> Ok... let me try to avoid dissent and do what you ask.
>
> Let's come back to RPL-11 text:
>> 3.  If the packet header specifies a source route by including a RH4
>> header as specified in [I-D.ietf-6man-rpl-routing-header]
>
> then draft-ietf-6man-rpl-routing-header-00 says:
>> else { swap the IPv6 Destination Address and Address[i]
>
> That means that there is a mutable but predictable field (IPv6
> Destination Addess) in RH of RPL.  But RPL Security doesn't understand
> mutable but predictable fields (only mutable as per recent discussion).
>  RPL Security covers "entire IPv6 packet", which changes enroute despite
> RPL Security's expectation it won't change.
>
> So the question is: does RPL Security secure the RH4 header?  I think it
> does not, because its MAC computation does not say how are the mutable
> but predictable fields covered.
>
> For example, a sender builds a packet with Dst address1, computes MAC,
> inserts MAC.  Then intermediary routers process that packet and replace
> that Dst address1 with address2 from the Routing Header.  Now the packet
> is received at address1.  The MAC can't be meaningfully computed on the
> receiver, because the "IPv6 entire packet" has changed, it is not the
> same as at emission.
>
> I think this example is correct.
>
> It can't be solved in the same way we solved the mutability of "Hop
> Limit" (we said to make HopLimit set to 0 for MAC calculation), because
> if we do so then we have a higher risk of attack than when left HopLimit
> unsecure.  If we set to 0 de Dst for MAC calculation then the risk of
> implication of forged IP dst addresses is higher than forged HopLimit.
> Forging an IP dst address is stronger security attack than forging
> HopLimit, intuitively speaking.
>
> Besides, whereas the receiver has really no idea about what could the
> original HopLimit be, it knows precisely what the original Dst address
> was (it's in the RH4, swapped).  Thus the securing solution should be
> different - it should be as smart as RH4 is.
>
> Knowing the previous discussion, it may be possible that people will
> request we refer to that Authentication Header RFC which tells how
> mutable, mutable but predictable fields are dealt with.  At that point
> we come back to IPsec, but I will abstain from saying so if you wish.
> There is also the fact that previous IPsec talk says RH0 whereas here we
> have RH4 and things may be different.
>
> That's too long for anyone to read, but you get the point.
>
> Alex
>
>
>
>
>  You are of course
>> entitled to your opinion but progress is only made in the IETF
>> through rough consensus. Consensus does not mean unanimous agreement;
>> if we can all at least consent to a solution then the process will
>> run a lot more smoothly and we will all benefit. Continual dissent
>> will only serve to hinder this progress.
>>
>> I think the consensus is clear:
>>
>> * We do not mention IPSec in RPL security * The mutable field
>> discussion is entirely independent from IPSec
>>
>> Robert
>>
>> Robert Cragie (Pacific Gas & Electric)
>>
>> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44
>> 1924 910888 [phone] http://www.gridmerge.com
>> <http://www.gridmerge.com/>
>>
>>
>> On 09/09/2010 9:33 PM, David Culler wrote:
>>> Dear Alex, Thank you for focusing on the question of routing
>>> security, rather than internet security in general.  Yes, IPSec has
>>> been utilized to secure routing protocols.  Now please take the
>>> next step and focus on routing for low power and lossy networks.
>>> Obviously, IPSec has to be the first thing considered.  And it was.
>>> Dating back to the earliest security framework discussions it was
>>> considered many times.   We returned to the IPSec issue extensively
>>> back in June on the mailing list.   I won't reiterate the
>>> discussion on the storage and time complexity, nor the message
>>> overhead implications that were in those prior postings.  But I
>>> will observe that no one suggested that they saw their way to a
>>> full IPSec implementation within the constraints articulated in the
>>> Routing Requirements documents.   The WG group has long since
>>> reached a rough consensus on this matter and moved on.  That is the
>>> nature of a group process and specifically the role of WG LC.  At
>>> some point, we commit to certain things and stop revisiting them
>>> from first principles.   That allows us to focus more sharply on
>>> the selected approach and refine it more completely.  For example,
>>> in security, we have specifics to resolve, such as which header
>>> fields need to be skipped.  It is not a matter of "but I imagine
>>> that there may be alternatives".  There might be.  But we don't
>>> just turn the same rocks over and over again.  We carve the rough
>>> stone, we chisel the details, we sand, we polish.
>>>
>>> So I assume that the point of your posting is that you want to be
>>> sure that the justification for the choices that the WG made are
>>> properly documented in the WG documents.  If you feel that they are
>>> not, perhaps you could point to the document and section that you
>>> feel should contain this material more substantially.
>>>
>>> D.
>>>
>>> For reference,http://www.ietf.org/tao.html  section 7.4
>>>
>>>
>>> On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote:
>>>
>>>> Le 09/09/2010 16:59, David Culler aécrit :
>>>>> The RPL charter calls for us to address routing security
>>>>> considerations.  Not security in general.  Not application
>>>>> security. Not link level.  Routing security.  It is focused for
>>>>> good reason.
>>>> Routing security like OSPF using IPsec? "Authentication has been
>>>> removed from the OSPF protocol and instead relies on IPv6's
>>>> Authentication Header and Encapsulating Security Payload (ESP)."
>>>> says rfc5340... why does RPL need to be different in this
>>>> respect?
>>>>
>>>> Alex
>>>>
>>>>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote:
>>>>>
>>>>>> Le 08/09/2010 18:15, Philip Levis aécrit :
>>>>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote:
>>>>>>>
>>>>>>>> Le 03/09/2010 13:48, Robert Cragie aécrit : [skipped
>>>>>>>> agreed opinions about IPsec]
>>>>>>>>>> Reusing the IPsec module ensures a secure system -
>>>>>>>>>> it's proven by earlier experience. We know it worked
>>>>>>>>>> ok so why avoid using it.
>>>>>>>>> <RCC>I don't think the specification of RPL security
>>>>>>>>> precludes the use of IPSec instead. Does the use of
>>>>>>>>> IPSec need to be specified in the RPL
>>>>>>>>> specification?</RCC>
>>>>>>>> YEs, the RPL specification must say something about
>>>>>>>> security in its Security Considerations section.  That
>>>>>>>> something has to mention something about IPsec.
>>>>>>> Why does it have to do so? In theory, RPL should be
>>>>>>> entirely independent of IPSec. There have already been
>>>>>>> numerous discussions about why simply relying on IPSec
>>>>>>> would be problematic. Unfortunately you seem to forget
>>>>>>> these points every few weeks and rehash the same
>>>>>>> discussion. At some point it becomes a waste of everyone's
>>>>>>> time.
>>>>>> Phil - if RPL says "security" then it must understand that
>>>>>> Internet security is usually IPsec.  This is truer with IPv6
>>>>>> (as opposed to IPv4) where IPsec is very much integrated in
>>>>>> the design (mutable fields, etc.)
>>>>>>
>>>>>> Have you checked the mutable field discussion?  Do you agree
>>>>>> that mutable fields must be taken into account?
>>>>>>
>>>>>> Please read that around 3 people agreed on a list of items
>>>>>> which are worth discussion of security and IPsec - mutable
>>>>>> fields is one such item.
>>>>>>
>>>>>> As such this discussion is not a waste of everyone's time.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>> Phil
>>>>>>
>>>>>> _______________________________________________ Roll mailing
>>>>>> list [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>> David [e-mail]  Chair Computer Science
>>>>> Associate Chair EECS
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>> David Culler [e-mail] Chair Computer Science
>>> Associate Chair EECS
>>>
>>>
>>>
>>> _______________________________________________ Roll mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/roll
>>>
>>
>>
>> _______________________________________________ Roll mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/roll
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>

--- End Message ---

--- Begin Message ---

Le 10/09/2010 18:48, Robert Cragie a écrit :
>   Hi Alex,
>
> Thank you for focusing on a pertinent issue. You are right to highlight
> what we do with a RH4 header as I believe secured DAO ACK is the (only)
> RPL control message which requires RH4 in non-storing mode.

Sounds reassuring to know RH4 is only for DAO ACK and only for
non-storing mode.

And in storing mode? Is RH4 present in other than DAO ACK? Just to make
sure I understand you.

> So, to follow the rules for mutable and predictable fields (see RFC
> 4302), we can resubstitute at the end:
>
> Consider the following:
>
> A -> B -> C -> D -> E
>
> A -> B:
>
> |Src|Dst|RH4 |
> | | |Seq|A0 |A1 |A2 |
> -------------------------
> | A | B | 3 | C | D | E |
>
> B -> C:
>
> |Src|Dst|RH4 |
> | | |Seq|A0 |A1 |A2 |
> -------------------------
> | A | C | 2 | B | D | E |
>
> C -> D:
>
> |Src|Dst|RH4 |
> | | |Seq|A0 |A1 |A2 |
> -------------------------
> | A | D | 1 | B | C | E |
>
> D -> E:
>
> |Src|Dst|RH4 |
> | | |Seq|A0 |A1 |A2 |
> -------------------------
> | A | E | 0 | B | C | D |
>
> When the packet arrives at E, recreate the original RH4 header for MAC
> computation:
>
> n = ((Hdr Ext Len * 8) - Pad) / (16 - Comp)
> tmp = Dst
> Dst = RH4.A[0]
> RH4.Seq = n
> for (k = 1; k < n; k++)
> {
> RH4.A[k-1] = RH4.A[k]
> }
> RH4.A[k] = tmp
>
> |Src|Dst|RH4 |
> | | |Seq|L0 |L1 |L2 |
> -------------------------
> | A | B | 3 | C | D | E |
>
> Is that acceptable?

Thanks for the method - it reads reasonable.  It is a good way (one way? 
  are there others? are there little bugs in that code?) to specify MAC 
over RH4 coherently - reconstruct the RH at reception.  This solution is 
different than solving the mutability of the Hop Limit field.

Can we see further - RH4 draft also says IPv6-in-IPv6 tunnelling must be 
used sometime, together with RH4.  This raises the obvious question 
about: is the header of the encapsulating packet also protected by the 
MAC of RPL?  Or not?

RPL spec currently says the "entire IPv6 packet" is covered by its MAC. 
  But does that cover the IPv6 base header of the encapsulating header? 
  Or not?  And in which order?

> Now, just because I refer to IPSec AH, it doesn't mean I am suggesting
> we use it. I am suggesting we can use the fundamental principles from
> IPSec for an equivalent operation.

I understand.  I am just afraid sometimes we try to rewrite much parts 
of it.

For example, I wonder how to you plan to refer to that RFC document? 
Just wondering.

Alex

>
> Robert
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> [phone]
> [phone]
> http://www.gridmerge.com <http://www.gridmerge.com/>
>
>
> On 10/09/2010 4:22 PM, Alexandru Petrescu wrote:
>> Le 10/09/2010 11:55, Robert Cragie a écrit :
>>> David,
>>>
>>> I totally agree with what you say. Thank you for restating generally
>>> that IPSec has already been extensively considered - I use the term
>>> 'paraphernalia' as a general term for the overheads.
>>>
>>> Alex - can we please drop the IPSec discussion and move on and
>>> concentrate on the things which do need to sorted out?
>>
>> Ok... let me try to avoid dissent and do what you ask.
>>
>> Let's come back to RPL-11 text:
>>> 3. If the packet header specifies a source route by including a RH4
>>> header as specified in [I-D.ietf-6man-rpl-routing-header]
>>
>> then draft-ietf-6man-rpl-routing-header-00 says:
>>> else { swap the IPv6 Destination Address and Address[i]
>>
>> That means that there is a mutable but predictable field (IPv6
>> Destination Addess) in RH of RPL. But RPL Security doesn't understand
>> mutable but predictable fields (only mutable as per recent discussion).
>> RPL Security covers "entire IPv6 packet", which changes enroute despite
>> RPL Security's expectation it won't change.
>>
>> So the question is: does RPL Security secure the RH4 header? I think it
>> does not, because its MAC computation does not say how are the mutable
>> but predictable fields covered.
>>
>> For example, a sender builds a packet with Dst address1, computes MAC,
>> inserts MAC. Then intermediary routers process that packet and replace
>> that Dst address1 with address2 from the Routing Header. Now the packet
>> is received at address1. The MAC can't be meaningfully computed on the
>> receiver, because the "IPv6 entire packet" has changed, it is not the
>> same as at emission.
>>
>> I think this example is correct.
>>
>> It can't be solved in the same way we solved the mutability of "Hop
>> Limit" (we said to make HopLimit set to 0 for MAC calculation), because
>> if we do so then we have a higher risk of attack than when left HopLimit
>> unsecure. If we set to 0 de Dst for MAC calculation then the risk of
>> implication of forged IP dst addresses is higher than forged HopLimit.
>> Forging an IP dst address is stronger security attack than forging
>> HopLimit, intuitively speaking.
>>
>> Besides, whereas the receiver has really no idea about what could the
>> original HopLimit be, it knows precisely what the original Dst address
>> was (it's in the RH4, swapped). Thus the securing solution should be
>> different - it should be as smart as RH4 is.
>>
>> Knowing the previous discussion, it may be possible that people will
>> request we refer to that Authentication Header RFC which tells how
>> mutable, mutable but predictable fields are dealt with. At that point
>> we come back to IPsec, but I will abstain from saying so if you wish.
>> There is also the fact that previous IPsec talk says RH0 whereas here we
>> have RH4 and things may be different.
>>
>> That's too long for anyone to read, but you get the point.
>>
>> Alex
>>
>>
>>
>>
>> You are of course
>>> entitled to your opinion but progress is only made in the IETF
>>> through rough consensus. Consensus does not mean unanimous agreement;
>>> if we can all at least consent to a solution then the process will
>>> run a lot more smoothly and we will all benefit. Continual dissent
>>> will only serve to hinder this progress.
>>>
>>> I think the consensus is clear:
>>>
>>> * We do not mention IPSec in RPL security * The mutable field
>>> discussion is entirely independent from IPSec
>>>
>>> Robert
>>>
>>> Robert Cragie (Pacific Gas & Electric)
>>>
>>> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44
>>> 1924 910888 [phone] http://www.gridmerge.com
>>> <http://www.gridmerge.com/>
>>>
>>>
>>> On 09/09/2010 9:33 PM, David Culler wrote:
>>>> Dear Alex, Thank you for focusing on the question of routing
>>>> security, rather than internet security in general. Yes, IPSec has
>>>> been utilized to secure routing protocols. Now please take the
>>>> next step and focus on routing for low power and lossy networks.
>>>> Obviously, IPSec has to be the first thing considered. And it was.
>>>> Dating back to the earliest security framework discussions it was
>>>> considered many times. We returned to the IPSec issue extensively
>>>> back in June on the mailing list. I won't reiterate the
>>>> discussion on the storage and time complexity, nor the message
>>>> overhead implications that were in those prior postings. But I
>>>> will observe that no one suggested that they saw their way to a
>>>> full IPSec implementation within the constraints articulated in the
>>>> Routing Requirements documents. The WG group has long since
>>>> reached a rough consensus on this matter and moved on. That is the
>>>> nature of a group process and specifically the role of WG LC. At
>>>> some point, we commit to certain things and stop revisiting them
>>>> from first principles. That allows us to focus more sharply on
>>>> the selected approach and refine it more completely. For example,
>>>> in security, we have specifics to resolve, such as which header
>>>> fields need to be skipped. It is not a matter of "but I imagine
>>>> that there may be alternatives". There might be. But we don't
>>>> just turn the same rocks over and over again. We carve the rough
>>>> stone, we chisel the details, we sand, we polish.
>>>>
>>>> So I assume that the point of your posting is that you want to be
>>>> sure that the justification for the choices that the WG made are
>>>> properly documented in the WG documents. If you feel that they are
>>>> not, perhaps you could point to the document and section that you
>>>> feel should contain this material more substantially.
>>>>
>>>> D.
>>>>
>>>> For reference,http://www.ietf.org/tao.html section 7.4
>>>>
>>>>
>>>> On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote:
>>>>
>>>>> Le 09/09/2010 16:59, David Culler aécrit :
>>>>>> The RPL charter calls for us to address routing security
>>>>>> considerations. Not security in general. Not application
>>>>>> security. Not link level. Routing security. It is focused for
>>>>>> good reason.
>>>>> Routing security like OSPF using IPsec? "Authentication has been
>>>>> removed from the OSPF protocol and instead relies on IPv6's
>>>>> Authentication Header and Encapsulating Security Payload (ESP)."
>>>>> says rfc5340... why does RPL need to be different in this
>>>>> respect?
>>>>>
>>>>> Alex
>>>>>
>>>>>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote:
>>>>>>
>>>>>>> Le 08/09/2010 18:15, Philip Levis aécrit :
>>>>>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote:
>>>>>>>>
>>>>>>>>> Le 03/09/2010 13:48, Robert Cragie aécrit : [skipped
>>>>>>>>> agreed opinions about IPsec]
>>>>>>>>>>> Reusing the IPsec module ensures a secure system -
>>>>>>>>>>> it's proven by earlier experience. We know it worked
>>>>>>>>>>> ok so why avoid using it.
>>>>>>>>>> <RCC>I don't think the specification of RPL security
>>>>>>>>>> precludes the use of IPSec instead. Does the use of
>>>>>>>>>> IPSec need to be specified in the RPL
>>>>>>>>>> specification?</RCC>
>>>>>>>>> YEs, the RPL specification must say something about
>>>>>>>>> security in its Security Considerations section. That
>>>>>>>>> something has to mention something about IPsec.
>>>>>>>> Why does it have to do so? In theory, RPL should be
>>>>>>>> entirely independent of IPSec. There have already been
>>>>>>>> numerous discussions about why simply relying on IPSec
>>>>>>>> would be problematic. Unfortunately you seem to forget
>>>>>>>> these points every few weeks and rehash the same
>>>>>>>> discussion. At some point it becomes a waste of everyone's
>>>>>>>> time.
>>>>>>> Phil - if RPL says "security" then it must understand that
>>>>>>> Internet security is usually IPsec. This is truer with IPv6
>>>>>>> (as opposed to IPv4) where IPsec is very much integrated in
>>>>>>> the design (mutable fields, etc.)
>>>>>>>
>>>>>>> Have you checked the mutable field discussion? Do you agree
>>>>>>> that mutable fields must be taken into account?
>>>>>>>
>>>>>>> Please read that around 3 people agreed on a list of items
>>>>>>> which are worth discussion of security and IPsec - mutable
>>>>>>> fields is one such item.
>>>>>>>
>>>>>>> As such this discussion is not a waste of everyone's time.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>> Phil
>>>>>>>
>>>>>>> _______________________________________________ Roll mailing
>>>>>>> list [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>>> David [e-mail] Chair Computer Science
>>>>>> Associate Chair EECS
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> David Culler [e-mail] Chair Computer Science
>>>> Associate Chair EECS
>>>>
>>>>
>>>>
>>>> _______________________________________________ Roll mailing list
>>>> [e-mail] https://www.ietf.org/mailman/listinfo/roll
>>>>
>>>
>>>
>>> _______________________________________________ Roll mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/roll
>>
>>
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
>>


_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll

--- End Message ---