BGP IPsec Tunnel Encapsulation Attribute
RFC 5566

That is in fact the problem .. the standard IPsec mechanisms are via a PKI. We need a solution that doesn't require PKI deployment.

-DWard

On Mar 24, 2009, at 2:45 PM, Lou Berger wrote:

> Via standard ipsec mechanisms...
> -----Original Message-----
> From:  David Ward
>
> Date: Tue, 24 Mar 2009 12:27:15
> To: Lou Berger
> Cc: David Ward; ; Pasi Eronen; Mark Townsley; Alain Durand; Russ White; Ross Callon; Jari Arkko; Ralph Droms
> Subject: Re: [Fwd: Re: DISCUSS: draft-ietf-softwire-encaps-ipsec]
>
>
> I'll let Pasi explain in greater detail but, right now we have this
> situation:
>
> Peers X and Y
>
> - X requests an IPsec tunnel to Y
>
> - Y sends back some info so that X can verify
>
> - Everything goes or fails
>
> How did Y verify X's request initially?
>
> -DWard
>
> On Mar 24, 2009, at 12:17 PM, Lou Berger wrote:
>
>>
>> Dave,
>>    So the proposal is to replace the current " IPsec Tunnel
>> Authenticator" mechanism that can be used to validate the BGP next
>> hop with a new "fingerprint" mechanism.  Is this correct?
>>
>> Sure we can do this (assuming someone - Pasi? -  will write the
>> text) but I really don't understand what value is being added.  I'm
>> no security expert, so someone may have to explain what I'm missing.
>>
>> In the current scheme, we/softwires is providing *incremental*
>> information to all an softwires tunnel initiator to validate the the
>> remote endpoint is the softwires BGP node that advertised the next
>> hop and associated forwarding information.  In short, that the next
>> hop hasn't spoofed "softwires" information.
>>
>> As I understand it, in the above case existing standard IPsec
>> mechanisms provide the authentication mechanisms to ensure that "no
>> peer can randomly bring up a tunnel."  This is most certainly a
>> benefit, i.e., "... the benefits for L3VPN to avoid "other" peers
>> from joining a VPN as well."  So when we look at the two mechanisms
>> in combination (a) ipsec ensures that the tunnel is only
>> established / the VPN is only joined by authorized parties and (b)
>> softwires ensures that no authorized party masquerades as a
>> different authorized party / BGP next hop.
>>
>> I understand that utility of the above, but the operators/users I
>> talked to about this think that (a) is sufficient and won't use (b).
>>
>> Simply don't understand what value adding (c) "a softwires mechanism
>> for a softwires endpoint to validate an incoming tunnel against the
>> BGP membership" provides.  The folks I know who care about this
>> document will certainly never deploy this as the don't even what (b).
>>
>> I really think we're yet again defining a security mechanisms for
>> its own sake that will never be used.  I welcome hearing how I'm
>> mistaken. That said, if making this change allows the document to
>> progress, by all means, let's do it!
>>
>> Lou
>>
>>
>> On 3/24/2009 7:50 AM, David Ward wrote:
>>> All -
>>>
>>> Pasi and I chatted this morning and if we are to reuse the technology
>>> for L3VPN it would be best to have some requirements as Eric says:
>>>
>>> "Therefore the only possible security requirements that softwires
>>> can have
>>> are requirements having to do with the integrity of the encapsulation
>>> header, and with the authentication of the tunnel endpoints."
>>>
>>> On the auth of the endpoints, Pasi thinks that if we pass the
>>> fingerprints in a new BGP SAFI we are good to go. No PKI is necessary
>>> and public key crypto is available. This seems akin to other endpoint
>>> discovery mechanisms (e.g. L1VPN) and seems rather trivial to encode.
>>> The SAFI contains a list of fingerprints of possible endpoints and
>>> thus,
>>> no peer can randomly bring up a tunnel. Clearly you can see the
>>> benefits
>>> for L3VPN to avoid "other" peers from joining a VPN as well.
>>>
>>> Thoughts? Can we use this notion of passing a fingerprint list?
>>>
>>>
>>>
>>> -DWard
>>>
>>>
>>>
>>> On Mar 16, 2009, at 2:34 PM, Eric Rosen wrote:
>>>
>>>>
>>>>> for the "how does R2 authenticate R1" part, I'm waiting for a reply
>>>>> to my 2009-02-23 email.
>>>>
>>>> Let me review the security requirements, provide some historical
>>>> context,
>>>> and explain how we arrived at a scheme in which R2 doesn't
>>>> authenticate R1.
>>>>
>>>> The purpose of softwires is to take IPv4 traffic that is already
>>>> traveling
>>>> on the Internet, and to tunnel it across parts of the Internet
>>>> that only
>>>> support IPv6. Or to take IPv6 traffic that is already traveling on
>>>> the
>>>> Internet, and to tunnel it across parts of the Internet that only
>>>> support
>>>> IPv4.
>>>>
>>>> If the traffic itself has any confidentiality, integrity, or
>>>> authentication
>>>> requirements, then it had those requirements before it entered the
>>>> tunnel
>>>> and it will continue to have those requirements after it leaves the
>>>> tunnel.
>>>>
>>>> Therefore the only possible security requirements that softwires
>>>> can have
>>>> are requirements having to do with the integrity of the
>>>> encapsulation
>>>> header, and with the authentication of the tunnel endpoints.
>>>>
>>>> Any kind of Security Association, even one between unauthenticated
>>>> endpoints, can ensure integrity of the encapsulation header. So
>>>> the only
>>>> difficult problem is the authentication of the tunnel endpoints.
>>>>
>>>> This leads to some pragmatic difficulties.
>>>>
>>>> In some prior documents on tunneling (e.g., RFC 4023), when the
>>>> Security AD
>>>> made me put in something about IPsec, I made manual keying a MUST
>>>> IMPLEMENT,
>>>> and automated keying a mere OPTION. That way, the required security
>>>> mechanism is one that could at least be deployed, and there is no
>>>> requirement for an ISP to deploy a PKI. After all, no ISP is going
>>>> to
>>>> deploy an entire automated keying infrastructure just to
>>>> authenticate
>>>> tunnel
>>>> endpoints, so it hardly makes sense to require support for that.
>>>> (It's
>>>> also
>>>> true that no vendor will provide IPsec support, even with manual
>>>> keying,
>>>> merely because some RFC requires it, but requiring a PKI goes even
>>>> more into
>>>> the realm of science fiction.)
>>>>
>>>> Unfortunately, some of the past Security ADs took note of the fact
>>>> that it
>>>> doesn't make much sense, and is certainly not scalable, to use
>>>> manual
>>>> keying
>>>> in an environment where the tunnel endpoints are auto-discovered
>>>> through
>>>> BGP. I agree with this. So if one isn't going to use manual keying
>>>> and
>>>> one
>>>> isn't going to deploy a PKI infrastructure, the obvious inference
>>>> is that
>>>> IPsec is useless in an environment where we have automated
>>>> procedures,
>>>> based
>>>> on routing, for setting up router-to-router tunnels.
>>>>
>>>> When I presented this conclusion to the WG, Mark Townsley flew
>>>> into a
>>>> panic
>>>> and got Sam Hartman involved. Sam took this as a challenge, and
>>>> thought
>>>> that maybe we could come up with something that is better than
>>>> nothing. He
>>>> suggested that if a BGP update is being used to assign a particular
>>>> address
>>>> prefix to a secure tunnel, then the BGP update could carry the
>>>> hash of a
>>>> self-signed certificate belonging to the originator of the update.
>>>> This
>>>> developed into the scheme that is specified in the softwires drafts.
>>>>
>>>> First, here is a one paragraph of the entire softwires framework:
>>>>
>>>> Suppose that R1, R2, R3, and R4 are all border routers of some
>>>> Autonomous System. Suppose that R2 knows how to reach a
>>>> particular address A by sending any packet with A in its IP
>>>> destination address field to some other AS. Suppose that R1, R3,
>>>> and R4, when they get packets destined for A, need to tunnel those
>>>> packets to R2, so that R2 can send them on to the next AS. Then
>>>> R2 originates a BGP update specifying the address A (or some
>>>> "prefix" which is an initial sequence of the bits in A), and
>>>> specifying the sort of tunnel which any other border router of the
>>>> same AS should use in order to send the packets to R2. Let's call
>>>> this update "U".
>>>>
>>>> What sort of authentication does it make sense to have in this
>>>> scheme?
>>>>
>>>> In IP routing, one doesn't ever care where a packet came from, only
>>>> where it
>>>> is going. If R1, R3, and R4 learned, from BGP update U, that they
>>>> need to
>>>> tunnel certain traffic to R2, it makes sense to assure R1, R3, and
>>>> R4
>>>> that
>>>> the tunnel they are using really does terminate at the router (R2)
>>>> that
>>>> originated BGP update U. At least, that assures R1, R3, and R4
>>>> that they
>>>> are sending the data to the right place. The procedures in the draft
>>>> cover
>>>> this.
>>>>
>>>> When traffic emerges from a tunnel at R2, R2 doesn't really care
>>>> where
>>>> the
>>>> traffic came from; the most it cares about is that the head end of
>>>> the
>>>> tunnel is one of the routers that received the BGP Update U.
>>>>
>>>> However, since a BGP update does not necessarily pass unchanged as
>>>> it
>>>> goes
>>>> from one BGP speaker to another, it is difficult to see how to use
>>>> the
>>>> BGP-based softwires mechanism as part of a mutual authentication
>>>> scheme.
>>>>
>>>> That said, if you think the scheme is of no value unless the
>>>> tunnel tail
>>>> (R2) can authenticate the tunnel heads (e.g., R1), we could devise a
>>>> way for
>>>> R1 to pass its own public key hash in a BGP update. R2 could
>>>> originate an
>>>> update containing its own IP address and attach the hash to that.
>>>>
>>>> The problem with this is that when the plethora of security experts
>>>> starts
>>>> to review this, they will find additional issues and we'll end up
>>>> delaying
>>>> another year. This is a lot of delay for something that really
>>>> doesn't
>>>> make
>>>> much difference and that nobody really wants anyway.
>>>>
>>>> On another topic, the issue of why we specified the particular
>>>> hash we
>>>> did,
>>>> this is based on a recommendation from Tero Kivenen in December,
>>>> 2007. I
>>>> originally wrote just that the hash should be a non-reversible
>>>> hash of
>>>> the
>>>> of a certificate, and asked if there were a standard method for
>>>> producing
>>>> it. The reply:
>>>>
>>>> There is multiple ways to generate the hash. RFC4306 uses 2
>>>> method, FOR70 the Hash and URL encodings it uses SHA-1 hash of the
>>>> full certificate (this allows detecting whether you have exactly
>>>> correct certificate with same validity periods etc as other end).
>>>> For the certificate request payloads it uses the SHA-1 hash of the
>>>> public keys of the CA (this hash stays same even if the
>>>> certificate is re-enrolled with different validity periods but
>>>> still has same public key).
>>>>
>>>> I think you want to use the second one, as you do not really care
>>>> if the certificate is same you care if the public key is same. It
>>>> also stays same regardless if the host later changes self-signed
>>>> certificate to certificate which is signed by organization wide
>>>> key etc.
>>>>
>>>> You commented:
>>>>
>>>> If the IKE exchange will always use certificates (possibly
>>>> self-signed), I'd suggest using normal SHA-1 certificate
>>>> fingerprints (what e.g. web browsers and other management
>>>> systems currently display -- hash over entire certificate)
>>>> instead of the RFC 4306 approach (hash over SubjectPublicKeyInfo
>>>> structure only).
>>>>
>>>> I don't have enough security expertise to make an informed choice
>>>> between
>>>> these two procedures.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>
>

[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel types.

The newest version of the SAFI document actually defines IP in IP, too.

The document says:

  Let R1 and R2 be two BGP speakers that may send data packets through
  R3, such that the data packets from R1 and from R2 may be received by
  R3 over the same interface.  Then if R3 has sent an update containing
  an Encapsulation SAFI, and if this update specifies an IPsec tunnel
  type, and if this update is received by R2, and an Encapsulation-SAFI
  with an IPsec tunnel type, SHOULD also be received by R1. 

Where is the SHOULD referring to? Is this a statement that if one
router receives a message it is also expected to be received by
another one? But BGP works in a p2p manner, so I don't see how this
is guaranteed. Or is this a statement that one of the routers
need to do something special, such as send Encapsulation AVPs?
If so, maybe the "SHOULD be received" needs to be rewritten
somehow.

But maybe I'm missing something here.

The document says:

  IPsec does not necessarily
  need to be required for control packets that are directly addressed
  to R3.

If BGP is used to negotiate that IPsec is needed on a particular
tunnel interface, it seems that it is impossible for that instance
of IPsec protection to protect BGP. Chicken and egg problem. Of course,
you could configure IPsec separately to protect BGP. My experience
is that if you do not tell the reader how the IPsec policies are
setup, the chances are that its not possible to set them up :-)

[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel types.

The newest version of the SAFI document actually defines IP in IP, too.

The document says:

  Let R1 and R2 be two BGP speakers that may send data packets through
  R3, such that the data packets from R1 and from R2 may be received by
  R3 over the same interface.  Then if R3 has sent an update containing
  an Encapsulation SAFI, and if this update specifies an IPsec tunnel
  type, and if this update is received by R2, and an Encapsulation-SAFI
  with an IPsec tunnel type, SHOULD also be received by R1. 

Where is the SHOULD referring to? Is this a statement that if one
router receives a message it is also expected to be received by
another one? But BGP works in a p2p manner, so I don't see how this
is guaranteed. Or is this a statement that one of the routers
need to do something special, such as send Encapsulation AVPs?
If so, maybe the "SHOULD be received" needs to be rewritten
somehow.

But maybe I'm missing something here.

The document says:

  IPsec does not necessarily
  need to be required for control packets that are directly addressed
  to R3.

If BGP is used to negotiate that IPsec is needed on a particular
tunnel interface, it seems that it is impossible for that instance
of IPsec protection to protect BGP. Chicken and egg problem. Of,
you could configure IPsec separately to protect BGP. My experience
is that if you do not tell the reader how the IPsec policies are
setup, the chances are that its not possible to set them up :-)

[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel types.

The newest version of the SAFI document actually defines IP in IP, too.

The document says:

  Let R1 and R2 be two BGP speakers that may send data packets through
  R3, such that the data packets from R1 and from R2 may be received by
  R3 over the same interface.  Then if R3 has sent an update containing
  an Encapsulation SAFI, and if this update specifies an IPsec tunnel
  type, and if this update is received by R2, and an Encapsulation-SAFI
  with an IPsec tunnel type, SHOULD also be received by R1. 

Where is the SHOULD referring to? Is this a statement that if one
router receives a message it is also expected to be received by
another one? But BGP works in a p2p manner, so I don't see how this
is guaranteed. Or is this a statement that one of the routers
need to do something special, such as send Encapsulation AVPs?
If so, maybe the "SHOULD be received" needs to be rewritten
somehow.

But maybe I'm missing something here.

The document says:

  IPsec does not necessarily
  need to be required for control packets that are directly addressed
  to R3.

If BGP is used to negotiate that IPsec is needed on a particular
tunnel interface, it seems that it is impossible for that instance
of IPsec protection to protect BGP. Chicken and egg problem. Of,
you could configure IPsec separately to protect BGP.

[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel types.

The newest version of the SAFI document actually defines IP in IP, too.

[Ballot discuss]
The abstract says:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel types.

The newest version of the SAFI document actually defines IP in IP, too.

This document says:

  This document builds on [ENCAPS-SAFI] and defines
  support for IPsec tunnels.  Support is defined for IP Authentication
  Header in Tunnel-mode (AH), [RFC4302], and for IP Encapsulating
  Security Payload in Tunnel-mode (ESP), [RFC4303].  Support for IP-in-
  IP, [RFC2003], and MPLS-in-IP, [RFC4023] protected by IPsec Transport
  Mode is also defined.

But the -safi document says:

  This document defines the following types:

    - L2TPv3 over IP [RFC3931]: Tunnel Type = 1

    - GRE [RFC2784]: Tunnel Type = 2

    - IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7

Which document defines IP in IP? There are two competing claims...

[Ballot discuss]
Minor but annoying bug:

  Currently support for GRE and L2TPv3
  tunnel types are defined.  This document defines support for IPsec
  tunnel types.

The newest version of the SAFI document actually defines IP in IP, too.

[Ballot discuss]
I have reviewed draft-ietf-softwire-encaps-ipsec-01. Overall, the
document looks good, but I have the following concerns that I'd like
to discuss before recommending approval of the document:

- The document describes how the tunnel initiator (R1 in Section 3)
authenticates R2 (using the hash from the sub-TLV), but says nothing
about how R2 authenticates R1.

- The tunnel type values (3..6) identify some aspects of the IPsec SA
that will be used to protect the traffic, but not how the IPsec SA is
actually created.  Probably IKEv2 is meant, but we have (at least)
three other IPsec key management protocols as RFCs (IKEv1, KINK, and
Photuris). If it's not always IKEv2, the protocol to be used probably
should be given in some sub-TLV.

- The draft needs some text describing the SPD and PAD entries needed
for IKEv2 negotiation to succeed. I think this should be relatively
straightforward (once authenticating R1 is solved somehow).

Smaller comments:

- If the IKE exchange will always use certificates (possibly
self-signed), I'd suggest using normal SHA-1 certificate fingerprints
(what e.g. web browsers and other management systems currently display
-- hash over entire certificate) instead of the RFC 4306 approach
(hash over SubjectPublicKeyInfo structure only).

On the other hand, IKEv2 also has a "Raw RSA Key" type (although no
corresponding "Raw DSA Key" or "Raw ECDSA Key" types), which could be
used without generating self-signed certificates. But perhaps the
ability to use other algorithms than RSA makes certificates attractive
here.

- Values 5 (IP-in-IP with IPsec transport mode) and (MPLS-in-IP with
IPsec transport mode) don't identify which IPsec protocol (ESP or AH)
is to be used.  This is probably OK, as AH vs. ESP can be negotiated
by IKE -- but then we don't need two separate values 3 and 4 either.

- The text probably should allow more than one IPsec Tunnel
Authenticator sub-TLV in one attribute -- otherwise, it will be
difficult to ever change the key or certificate (or introduce new
Authenticator Types) without disrupting traffic. In this case, if
the certificate (or key) presented in IKE matches one of the sub-TLVs,
that would be considered successful.

- It seems RFC 4306 (and other key management protocols, if they're
supported) should be a normative reference.

[Ballot comment]
It would be helpful to name both the registry "BGP" and the sub-registry
"Tunnel Encapsulation Attribute Tunnel Types" or "Tunnel Encapsulation Attribute Sub-TLVs" to help readers find the relevant IANA registries.

[Ballot discuss]
Julien Laganier's secdir review (16 December, 2008) has not recieved a response.
I have appended the body of the review to this discuss for expediency.  I support
his suggestion to add text about the tunnel types in the security considerations.  I
also found the highlighted text in section 3 confusing.

--- excerpt from secdir review -----

In section 2. "IPsec Tunnel Encapsulation Types"
------------------------------------------------

"
  Per [ENCAPS-SAFI], tunnel type is indicated in the Tunnel
  Encapsulation attribute. This document defines the following tunnel
  type values:

    - AH in Tunnel-mode: Tunnel Type = 3 [RFC4302]

    - ESP in Tunnel-mode: Tunnel Type = 4 [RFC4303]

    - IP-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 5
      [RFC4023]
"

I made the same comment for the softwire framework draft but I'm
repeating it here for completeness: The use of IPsec transport mode to
protect tunnels is diminished significantly compared to the protection
afforded by IPsec tunnel mode and thus it would be good to point that
out in the Security Considerations section of this document. For
example RFC 4301 includes the following paragraph:

"
                                                    [...] The access
  control functions that are an important part of IPsec are
  significantly limited in this context, as they cannot be applied to
  the end-to-end headers of the packets that traverse a transport mode
  SA used in this fashion.  Thus, this way of using transport mode
  should be evaluated carefully before being employed in a specific
  context.
"

In section 3 "Use of IPsec"
---------------------------

"
  If a R1 is a BGP speaker that receives an Encapsulation SAFI update
  from another BGP speaker, R2, then if R1 has any data packets for
  which R2 is the BGP next hop, R1 MUST initiate an IPsec SA of the
  specified "tunnel type", and all such data packets MUST be sent
  through that SA.

  Let R1 and R2 be two BGP speakers that may send data packets through
  R3, such that the data packets from R1 and from R2 may be received by
  R3 over the same interface.  Then if R3 has sent an update containing
  an Encapsulation SAFI, and if this update specifies an IPsec tunnel
  type, and if this update is received by R2, and an Encapsulation-SAFI
  with an IPsec tunnel type, SHOULD also be received by R1. [..]
"

Maybe this is just me but I have read the last sentence above 5 or 6
times and I have trouble to parse it. It seems to be some comas should
disappear. Would this rewording be appropriate:

"If R3 has sent an update containing an Encapsulation SAFI that
specifies an IPsec tunnel type to R2, then an update containing an
Encapsulation SAFI that specifies an IPsec tunnel SHOULD also be
received by R1" ?

[Ballot discuss]
Julien Laganier's secdir review (16 December, 2008) has not recieved a response.
I have appended the body of the review to this discuss for expediency.  I support
his suggestion to add text about the tunnel types in the security considerations.  I
also found the highlighted text in section 3 confusing.

In section 2. "IPsec Tunnel Encapsulation Types"
------------------------------------------------

"
  Per [ENCAPS-SAFI], tunnel type is indicated in the Tunnel
  Encapsulation attribute. This document defines the following tunnel
  type values:

    - AH in Tunnel-mode: Tunnel Type = 3 [RFC4302]

    - ESP in Tunnel-mode: Tunnel Type = 4 [RFC4303]

    - IP-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 5
      [RFC4023]
"

I made the same comment for the softwire framework draft but I'm
repeating it here for completeness: The use of IPsec transport mode to
protect tunnels is diminished significantly compared to the protection
afforded by IPsec tunnel mode and thus it would be good to point that
out in the Security Considerations section of this document. For
example RFC 4301 includes the following paragraph:

"
                                                    [...] The access
  control functions that are an important part of IPsec are
  significantly limited in this context, as they cannot be applied to
  the end-to-end headers of the packets that traverse a transport mode
  SA used in this fashion.  Thus, this way of using transport mode
  should be evaluated carefully before being employed in a specific
  context.
"

In section 3 "Use of IPsec"
---------------------------

"
  If a R1 is a BGP speaker that receives an Encapsulation SAFI update
  from another BGP speaker, R2, then if R1 has any data packets for
  which R2 is the BGP next hop, R1 MUST initiate an IPsec SA of the
  specified "tunnel type", and all such data packets MUST be sent
  through that SA.

  Let R1 and R2 be two BGP speakers that may send data packets through
  R3, such that the data packets from R1 and from R2 may be received by
  R3 over the same interface.  Then if R3 has sent an update containing
  an Encapsulation SAFI, and if this update specifies an IPsec tunnel
  type, and if this update is received by R2, and an Encapsulation-SAFI
  with an IPsec tunnel type, SHOULD also be received by R1. [..]
"

Maybe this is just me but I have read the last sentence above 5 or 6
times and I have trouble to parse it. It seems to be some comas should
disappear. Would this rewording be appropriate:

"If R3 has sent an update containing an Encapsulation SAFI that
specifies an IPsec tunnel type to R2, then an update containing an
Encapsulation SAFI that specifies an IPsec tunnel SHOULD also be
received by R1" ?

[Ballot comment]
Section 2., paragraph 4:
>      - IP-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 5
>        [RFC4023]

  I think this reference should be to RFC2003 (or at least not to
  RFC4023, because that doesn't talk about IP-in-IP at all.)

IANA Last Call questions/comments:

- The SubTLV registry created by draft-ietf-softwire-encaps-safi-03.txt
does not have a "Tunnel Type" column, but the assignment in this
document seems to imply it does. Either this document is incorrect
in its requested assignment, the other document needs to be corrected
to add the column, or this document needs to request a modificiation
to the registry. Which do you prefer?

- In Section 4 you refer to the Authenticator Type in the SubTLV
and define authenticator type 1. Do you want to create a registry
of Authenticator Types?


Action 1:

Upon approval of this document, the IANA will make the following assignments
in the "Border Gateway Protocol (BGP) Parameters" registry located at
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml
sub-registry "Tunnel TLVs"

Type Tunnel Name Reference
---- --------------- ---------
3 AH [RFC-softwire-encaps-ipsec-01]
4 ESP [RFC-softwire-encaps-ipsec-01]
5 IP-in-IP tunnel with IPsec Transport Mode [RFC-softwire-encaps-ipsec-01]
6 MPLS-in-IP with IPsec Transport Mode [RFC-softwire-encaps-ipsec-01]


Action 2:

Upon approval of this document, the IANA will make the following assignments
in the "Border Gateway Protocol (BGP) Parameters" registry located at
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml
sub-registry "Tunnel Sub-TLVs"

SubType Sub-TLV name Reference
------- ------------- ---------
3 IPsec Tunnel Authenticator [RFC-softwire-encaps-ipsec-01]


We understand the above to be the only IANA Actions for this document.

draft-ietf-softwire-encaps-ipsec-01.txt

PROTO questionnaire for:
prepared by: Dave Ward (dward@cisco.com)

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Dave Ward

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document
that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong WG consensus behind this document and no one that has
expressed concerns about its progression.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).
No.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative
references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area
Director in
the Last Call downref procedure specified in RFC 3967.

The references are split into normative and informative.


Protocol write-up for:
by Dave Ward, dward@cisco.com

Technical Summary

The BGP Encapsulation Subsequence Address Family Identifiers (SAFI)
provides a method for the dynamic exchange of encapsulation
information, and the indication of encapsulation protocol types
to be
used for different next hops. Currently support for GRE and L2TPv3
tunnel types are defined. This document defines support for IPsec
tunnel types.


Working Group Summary

The SOFTWIRE WG supports the development and advancement of this
document.


Protocol Quality

This document was thoroughly reviewed by WG chairs and WG members,
including those with expertise in IPv4 to IPv6 transitions and
interworking.

Dave Ward is the WG chair shepherd. Mark Townsley is the
responsible Area
director.